From ftp-wg-owner@hethmon.com Fri Jul 12 15:33:42 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11057 for ; Fri, 12 Jul 2002 15:33:39 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020712144116-11361-11 ; Fri, 12 Jul 2002 14:41:16 -0500 Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020712144114-14628-11 ; Fri, 12 Jul 2002 14:41:14 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15a.boca15-verio.com (RS ver 1.0.63s) with SMTP id 087759 for ; Fri, 12 Jul 2002 15:31:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020712142745.01e8cf08@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Fri, 12 Jul 2002 14:41:15 -0500 X-OldDate: Fri, 12 Jul 2002 14:34:29 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM I'm receiving reports from some of my users that some FTP clients (and presumably FTP servers also?) attempt to use the MDTM command not just to display a file's time, but to _modify_ it. The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction] filename". Since file names can have spaces, and may start with digits, there's a possibility of overlap, wherein it is not possible to say whether the command received is to set the time on one file, or display the time for another. Granted, this confusion would require that a file "yyyymmddhhmmss xyz" exists in the same folder as one called "xyz", but I think that's not sufficiently unlikely for me to feel comfortable with implementing this extension to the FTP protocol. What are your feelings on this? Am I being too anal-retentive? Is there a need for an FTP command to set the modification time on a file (presumably so as to allow files to be uploaded with their original modification dates, but perhaps for other reasons)? [One or two of my potential users seem to think so, at least] Is it worth proposing a more standardised, and unambiguous, command sequence, to forestall this possibly causing problems in future? While I can't see any means to use this ambiguity as an attack, I do find that many sources of error come from different handlings of ambiguously stated 'standards'. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. From ftp-wg-owner@hethmon.com Sat Jul 13 22:00:49 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11138 for ; Sat, 13 Jul 2002 22:00:48 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020713210905-59797-10 ; Sat, 13 Jul 2002 21:09:05 -0500 Received: from web21104.mail.yahoo.com (web21104.mail.yahoo.com [216.136.227.106]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020713210903-36051-9 ; Sat, 13 Jul 2002 21:09:03 -0500 Message-ID: <20020714015956.59244.qmail@web21104.mail.yahoo.com> Received: from [152.163.188.70] by web21104.mail.yahoo.com via HTTP; Sat, 13 Jul 2002 18:59:56 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Jul 2002 21:09:04 -0500 X-OldDate: Sat, 13 Jul 2002 18:59:56 -0700 (PDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Pat LaVarre To: ftp-wg@hethmon.com Subject: Ftp-WG: Potentially unsound use of MDTM > Is there a need for an FTP command > to set the modification time on a file > (presumably so as to allow files to be uploaded > with their original modification dates, Certainly, in substituting an Ftp connection for a real filesystem, I for one felt the lack of a way to copy modification date/time accurately more strongly than I felt the lack of a standard way to parse folder vs. file and other info from LIST text. Pat LaVarre -----Original Message----- From: Alun Jones [mailto:alun@texis.com] Sent: Fri 7/12/2002 1:41 PM To: FTPEXT Working Group Cc: Subject: Ftp-WG: Potentially unsound use of MDTM I'm receiving reports from some of my users that some FTP clients (and presumably FTP servers also?) attempt to use the MDTM command not just to display a file's time, but to _modify_ it. The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction] filename". Since file names can have spaces, and may start with digits, there's a possibility of overlap, wherein it is not possible to say whether the command received is to set the time on one file, or display the time for another. Granted, this confusion would require that a file "yyyymmddhhmmss xyz" exists in the same folder as one called "xyz", but I think that's not sufficiently unlikely for me to feel comfortable with implementing this extension to the FTP protocol. What are your feelings on this? Am I being too anal-retentive? Is there a need for an FTP command to set the modification time on a file (presumably so as to allow files to be uploaded with their original modification dates, but perhaps for other reasons)? [One or two of my potential users seem to think so, at least] Is it worth proposing a more standardised, and unambiguous, command sequence, to forestall this possibly causing problems in future? While I can't see any means to use this ambiguity as an attack, I do find that many sources of error come from different handlings of ambiguously stated 'standards'. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. [[[ Yahoo spam may follow, sorry. ]]] __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From ftp-wg-owner@hethmon.com Sun Jul 14 12:26:53 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10711 for ; Sun, 14 Jul 2002 12:26:52 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020714113512-35085-10 ; Sun, 14 Jul 2002 11:35:12 -0500 Received: from delta.cs.mu.OZ.AU (133.93.71.210 [133.93.71.210]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020714113510-49484-9 ; Sun, 14 Jul 2002 11:35:10 -0500 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6EFrEX06969 for ; Mon, 15 Jul 2002 00:53:14 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <4.3.2.7.2.20020712142745.01e8cf08@208.55.91.110> References: <4.3.2.7.2.20020712142745.01e8cf08@208.55.91.110> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <6967.1026661994@munnari.OZ.AU> Date: Sun, 14 Jul 2002 11:35:11 -0500 X-OldDate: Mon, 15 Jul 2002 00:53:14 +0900 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM This "feature" of some clients was known back when the MDTM test in the mlst draft was being written - that's the point of one of the examples showing a space in a file name with the part before the space looking very much like a time ... So, no, you certainly should not be implementing that broken behaviour. On the other hand, creating a new command to do this would certainly be possible - no-one so far has been sufficiently motivated to do the work. kre From ftp-wg-owner@hethmon.com Mon Jul 15 07:49:19 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26061 for ; Mon, 15 Jul 2002 07:49:16 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715065737-37880-10 ; Mon, 15 Jul 2002 06:57:37 -0500 Received: from bts.lu (bts.lu [161.58.236.92]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715065733-16076-9 ; Mon, 15 Jul 2002 06:57:33 -0500 Received: from mergenthaler.trevezel.com (vodsl-182.vo.lu [80.90.32.182]) by bts.lu (8.11.6) id g6FBmOA45315; Mon, 15 Jul 2002 13:48:24 +0200 (CEST) Received: from bembo by trevezel.com with SMTP (MDaemon.v3.5.7.R) for ; Mon, 15 Jul 2002 13:51:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020712142745.01e8cf08@208.55.91.110> Importance: Normal X-Return-Path: dsomers@trevezel.com X-MDaemon-Deliver-To: ftp-wg@hethmon.com Date: Mon, 15 Jul 2002 06:57:35 -0500 X-OldDate: Mon, 15 Jul 2002 13:51:28 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "David Somers" To: "FTPEXT Working Group" Subject: Ftp-WG: Potentially unsound use of MDTM Content-Transfer-Encoding: 7bit Hi Alun, Disclaimer: I'm new to the FTPEXT list, so firstly hello to all, and secondly apologies if what I'm saying had been thrashed out before and I'm regurgitating and/or talking horse manure. > I'm receiving reports from some of my users that some FTP clients (and > presumably FTP servers also?) attempt to use the MDTM command not just to > display a file's time, but to _modify_ it. > > The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction] > filename". When doing some ad-hoc research, I came across this too... RhinoSoft's Serv-U appears to implement MDTM in this manner...RhinoSoft's FTP Voyager client appears to use MDTM in this manner when it either detects that the server is Serv-U (from the 220 mark), or from MDTM being in the FEAT response. > Since file names can have spaces, and may start with digits, there's a > possibility of overlap, wherein it is not possible to say whether the > command received is to set the time on one file, or display the time for > another. Granted, this confusion would require that a file > "yyyymmddhhmmss > xyz" exists in the same folder as one called "xyz", but I think > that's not > sufficiently unlikely for me to feel comfortable with implementing this > extension to the FTP protocol. I'm developing my own FTP server, and the logic I thought up to cope with this situation was: When you get MDTM, if the rest of the line corresponds *exactly* to a filename (spaces and all!), assume MDTM and return the modification time for the filename. Otherwise, check that the first part of the line represents a valid timestamp, and if so, process as MDTM . (Yes, this is a bad hack. I don't like it either!) > What are your feelings on this? Am I being too anal-retentive? Nah. Its an abuse of the MDTM command, and really should have been done as an X-prefixed command. > Is there a > need for an FTP command to set the modification time on a file > (presumably > so as to allow files to be uploaded with their original > modification dates, > but perhaps for other reasons)? I think that there is more than just the file modification time to consider. For example, when mirroring files between servers, the creation time also needs to be duplicated (if the underlying file system supports creation times). I think there are two ways this can be done. 1. Changing the non-standardized "MdTm" time-val SP pathname CRLF to something like "MFMT" time-val SP pathname CRLF where MFMT means Modify File Modification Time and also supporting a new command "MFCT" time-val SP pathname CRLF where MFCT means Modify File Creation Time 2. By extending the STOR command so that these additional parameters can be specified. This will be useful for situations where a client can send a file to a server, but can not see or modify the file (and its attributes) afterwards... and it also means you can transfer a file and set its attributes using one command instead of several (as in #1 above). So, how about something like: stox = "STOX" [ stox-facts ] SP filename CRLF stox-facts = 1*( stox-fact ";" ) stox-fact = stox-factname "=" time-val / stox-localfact / stox-osfact stox-factname = "CreateTime" / "ModifyTime" stox-localfact= "X." token stox-osfact = "." token where STOX means STORE EXTENDED This acts like "STOR", but additionally and optionally allows attributes (create time, modification time and os/locally-defined ones) to be specified. Notes ===== 1. filename is UTF-8 encoded. 2. time-val is in UTC. 3. If the creation time is not specified, it should be set to the current date/time 4. If the modification time is not specified, it should be set to the creation date/time. 5. Instead of doing a subsequent SITE CHMOD, this could used instead to twiddle the appropriate bits. Examples ======== Example 1: Store the file fred.txt. This behaves identically to having issued "STOR fred.txt". C> STOX fred.txt S> 150 Opening ASCII data channel for fred.txt Example 2: Store the file fred.txt and set its creation time to Jan 1, 1970 23:59, and its modification time to Sep 8, 2001 11:12. C> STOX CreateTime=197010102359;ModifyTime=200109081112; fred.txt S> 150 Opening ASCII data channel for fred.txt FEAT response for STOX ====================== If this command is supported, then there must be a FEAT response: stox-feat = SP "STOX" [SP stox-factlist] CRLF factlist = 1*( factname ";" ) Example C> feat S> 211- S> ... S> STOX ModifyTime;Perm;X.WinSIS S> ... S> 211 End > [One or two of my potential > users seem to > think so, at least] Is it worth proposing a more standardised, and > unambiguous, command sequence, to forestall this possibly causing > problems > in future? While I can't see any means to use this ambiguity as > an attack, > I do find that many sources of error come from different handlings of > ambiguously stated 'standards'. This is why standards must be unambiguous. And finally, and completely unrelated to the above, does anybody know of any clients that support the MLSx commands? Cheers, David Somers Trevezel Systems GmbH (www.trevezel.com) From ftp-wg-owner@hethmon.com Mon Jul 15 08:33:26 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00939 for ; Mon, 15 Jul 2002 08:33:25 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715074151-16098-11 ; Mon, 15 Jul 2002 07:41:51 -0500 Received: from delta.cs.mu.OZ.AU (133.93.71.210 [133.93.71.210]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715074148-54555-10 ; Mon, 15 Jul 2002 07:41:49 -0500 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6FCVpO12753 for ; Mon, 15 Jul 2002 21:31:52 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <12751.1026736311@munnari.OZ.AU> Date: Mon, 15 Jul 2002 07:41:49 -0500 X-OldDate: Mon, 15 Jul 2002 21:31:51 +0900 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM Date: Mon, 15 Jul 2002 06:57:35 -0500 From: "David Somers" Message-ID: | And finally, and completely unrelated to the above, does anybody know of any | clients that support the MLSx commands? I don't know if you'd call it support or not, but I have an (unreleasable, the code is too disguisting) client that can use the things. But it is very much a command line client - it only works in combination with a human, so while it can parse MLSD and display the output in a "prettier" form than it comes down the wire, that's the end of its intelligence. I can't imagine it would be all that hard (the parsing is trivial) to make one of the clients that actually uses the values of listings (for GUI interfaces, mirroring, building HTML out of ftp listings, etc) couldn't be made to work at least as well with what comes from MLSD as what comes from LIST. kre From ftp-wg-owner@hethmon.com Mon Jul 15 09:29:29 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03817 for ; Mon, 15 Jul 2002 09:29:28 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715083753-57290-10 ; Mon, 15 Jul 2002 08:37:53 -0500 Received: from stat.com (stat.com [207.211.1.10]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715083750-51187-9 ; Mon, 15 Jul 2002 08:37:51 -0500 Message-Id: <20020715083750-51187-9@mail.hethmon.com> Received: from yahoo.com [204.176.164.59] by stat.com (SMTPD32-7.07) id AE01366F01C2; Mon, 15 Jul 2002 06:28:33 -0700 X-RBL-Warning: SPAMCOP: Blocked - see http://spamcop.net/bl.shtml?204.176.164.59 X-RBL-Warning: NOABUSE: Not supporting abuse@domain X-RBL-Warning: NOPOSTMASTER: Not supporting postmaster@domain X-RBL-Warning: BADHEADERS: This E-mail was sent from a broken mail client [84200008]. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 204.176.164.59 with no reverse DNS entry. X-RBL-Warning: WEIGHT10: Weight of 29 reaches or exceeds the limit of 10. Date: Mon, 15 Jul 2002 08:37:52 -0500 X-OldDate: Mon, 15 Jul 2002 06:28:44 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group Subject: Ftp-WG: From: "Amber" Subject: Amber - 18 - Virgin - wanna play? Content-Type: text/html; charset="iso-8859-1"

 

 

VERY GRAPHIC MATERIAL - MATURE AUDIENCE ONLY!

You MUST be at least 18 years old to enter!



 

 

This email was sent to you because your email address is part of a targeted opt-in list.You have received this
email by either requesting more information on one of our sites or someone may have used your email address.
If you received this email in error, please accept our apologies.
If you do not wish to receive further offers, please click below and enter your email to remove your email from future offers.

Click Here to Remove http://www.aria-giovanni-photos.com/unsub.php?cid=13

Anti-SPAM Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail cannot be considered spam
as long as we include contact information and a remove link for removal from this mailing list. If this e-mail is unsolicited, please
accept our apologies. Per the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000, further transmissions
to you by the sender may be stopped at NO COST to you!

Message-Id: <200207150628181.SM00398@yahoo.com> From ftp-wg-owner@hethmon.com Tue Jul 16 00:49:11 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28766 for ; Tue, 16 Jul 2002 00:49:11 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715235719-63235-10 ; Mon, 15 Jul 2002 23:57:19 -0500 Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020715235716-41106-9 ; Mon, 15 Jul 2002 23:57:17 -0500 Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6G4lSe26018 for ; Tue, 16 Jul 2002 10:17:29 +0530 (IST) Received: from wipro.tcpn.com ([172.31.41.11]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZBRYY00.UY8 for ; Tue, 16 Jul 2002 10:17:22 +0530 Received: from Athresh (tand205.wipro.tcpn.com [172.31.41.205]) by wipro.tcpn.com (8.9.3/8.9.3) with SMTP id KAA02249 for ; Tue, 16 Jul 2002 10:18:06 +0530 (IST) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cddeaaab-cf79-4756-ba08-0d5767752fb8" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: High In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Date: Mon, 15 Jul 2002 23:57:18 -0500 X-OldDate: Sun, 17 Jul 1988 10:12:28 +0530 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Athresh Kumar .B.S" To: "FTPEXT Working Group" Subject: Ftp-WG: Potentially unsound use of MDTM This is a multi-part message in MIME format. ------=_NextPartTM-000-cddeaaab-cf79-4756-ba08-0d5767752fb8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, can we make FTP session to continue when the lower layers goes for a while and comes up again?. I guess this functionality should be given in the session layer. Please provide me more information on this. Regards AThresh -----Original Message----- From: ftp-wg-owner [mailto:ftp-wg-owner@hethmon.com]On Behalf Of David Somers Sent: Monday, July 15, 2002 5:28 PM To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM Hi Alun, Disclaimer: I'm new to the FTPEXT list, so firstly hello to all, and secondly apologies if what I'm saying had been thrashed out before and I'm regurgitating and/or talking horse manure. > I'm receiving reports from some of my users that some FTP clients (and > presumably FTP servers also?) attempt to use the MDTM command not just to > display a file's time, but to _modify_ it. > > The format used is the sadly ambiguous "MDTM yyyymmddhhmmss[.fraction] > filename". When doing some ad-hoc research, I came across this too... RhinoSoft's Serv-U appears to implement MDTM in this manner...RhinoSoft's FTP Voyager client appears to use MDTM in this manner when it either detects that the server is Serv-U (from the 220 mark), or from MDTM being in the FEAT response. > Since file names can have spaces, and may start with digits, there's a > possibility of overlap, wherein it is not possible to say whether the > command received is to set the time on one file, or display the time for > another. Granted, this confusion would require that a file > "yyyymmddhhmmss > xyz" exists in the same folder as one called "xyz", but I think > that's not > sufficiently unlikely for me to feel comfortable with implementing this > extension to the FTP protocol. I'm developing my own FTP server, and the logic I thought up to cope with this situation was: When you get MDTM, if the rest of the line corresponds *exactly* to a filename (spaces and all!), assume MDTM and return the modification time for the filename. Otherwise, check that the first part of the line represents a valid timestamp, and if so, process as MDTM . (Yes, this is a bad hack. I don't like it either!) > What are your feelings on this? Am I being too anal-retentive? Nah. Its an abuse of the MDTM command, and really should have been done as an X-prefixed command. > Is there a > need for an FTP command to set the modification time on a file > (presumably > so as to allow files to be uploaded with their original > modification dates, > but perhaps for other reasons)? I think that there is more than just the file modification time to consider. For example, when mirroring files between servers, the creation time also needs to be duplicated (if the underlying file system supports creation times). I think there are two ways this can be done. 1. Changing the non-standardized "MdTm" time-val SP pathname CRLF to something like "MFMT" time-val SP pathname CRLF where MFMT means Modify File Modification Time and also supporting a new command "MFCT" time-val SP pathname CRLF where MFCT means Modify File Creation Time 2. By extending the STOR command so that these additional parameters can be specified. This will be useful for situations where a client can send a file to a server, but can not see or modify the file (and its attributes) afterwards... and it also means you can transfer a file and set its attributes using one command instead of several (as in #1 above). So, how about something like: stox = "STOX" [ stox-facts ] SP filename CRLF stox-facts = 1*( stox-fact ";" ) stox-fact = stox-factname "=" time-val / stox-localfact / stox-osfact stox-factname = "CreateTime" / "ModifyTime" stox-localfact= "X." token stox-osfact = "." token where STOX means STORE EXTENDED This acts like "STOR", but additionally and optionally allows attributes (create time, modification time and os/locally-defined ones) to be specified. Notes ===== 1. filename is UTF-8 encoded. 2. time-val is in UTC. 3. If the creation time is not specified, it should be set to the current date/time 4. If the modification time is not specified, it should be set to the creation date/time. 5. Instead of doing a subsequent SITE CHMOD, this could used instead to twiddle the appropriate bits. Examples ======== Example 1: Store the file fred.txt. This behaves identically to having issued "STOR fred.txt". C> STOX fred.txt S> 150 Opening ASCII data channel for fred.txt Example 2: Store the file fred.txt and set its creation time to Jan 1, 1970 23:59, and its modification time to Sep 8, 2001 11:12. C> STOX CreateTime=197010102359;ModifyTime=200109081112; fred.txt S> 150 Opening ASCII data channel for fred.txt FEAT response for STOX ====================== If this command is supported, then there must be a FEAT response: stox-feat = SP "STOX" [SP stox-factlist] CRLF factlist = 1*( factname ";" ) Example C> feat S> 211- S> ... S> STOX ModifyTime;Perm;X.WinSIS S> ... S> 211 End > [One or two of my potential > users seem to > think so, at least] Is it worth proposing a more standardised, and > unambiguous, command sequence, to forestall this possibly causing > problems > in future? While I can't see any means to use this ambiguity as > an attack, > I do find that many sources of error come from different handlings of > ambiguously stated 'standards'. This is why standards must be unambiguous. And finally, and completely unrelated to the above, does anybody know of any clients that support the MLSx commands? Cheers, David Somers Trevezel Systems GmbH (www.trevezel.com) ------=_NextPartTM-000-cddeaaab-cf79-4756-ba08-0d5767752fb8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-cddeaaab-cf79-4756-ba08-0d5767752fb8-- From ftp-wg-owner@hethmon.com Tue Jul 16 06:56:01 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16950 for ; Tue, 16 Jul 2002 06:56:01 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020716060416-25871-10 ; Tue, 16 Jul 2002 06:04:16 -0500 Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020716060414-55935-9 ; Tue, 16 Jul 2002 06:04:14 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15a.boca15-verio.com (RS ver 1.0.63s) with SMTP id 027187 for ; Tue, 16 Jul 2002 06:54:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20020716055409.023f9098@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Tue, 16 Jul 2002 06:04:15 -0500 X-OldDate: Tue, 16 Jul 2002 05:57:11 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Re: Session continuance on loss of link layer At 11:57 PM 7/15/2002, you wrote: >can we make FTP session to continue when the lower layers goes for a while >and comes up again?. I guess this functionality should be given in the >session layer. Please provide me more information on this. It already does this. TCP/IP connections don't break when the layer 2 link is broken - your application, client or server, might decide to time out if there's been no activity for a while (usually around five minutes or so), but TCP/IP won't disconnect you. Unless, that is, you're on Windows, where the Microsoft TCP/IP stack has chosen to act on "Media Sense", and will terminate all TCP/IP connections on a NIC when the cable is detected to be missing. On all other operating systems (and non-default Windows systems), if you kick a cable loose, and re-plug it, your session will continue. Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. From ftp-wg-owner@hethmon.com Wed Jul 17 03:56:43 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09108 for ; Wed, 17 Jul 2002 03:56:42 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717030445-31859-12 ; Wed, 17 Jul 2002 03:04:45 -0500 Message-Id: <20020717030445-31859-12@mail.hethmon.com> Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717030051 ; Wed, 17 Jul 2002 03:04:39 -0500 Date: Wed, 17 Jul 2002 03:04:43 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group Subject: Ftp-WG: From ftp-wg-owner@hethmon.com Wed Jul 17 04:57:48 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10383 for ; Wed, 17 Jul 2002 04:57:48 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717040614-12084-12 ; Wed, 17 Jul 2002 04:06:14 -0500 Received: from delta.cs.mu.OZ.AU (133.93.71.210 [133.93.71.210]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717040605-57000-11 ; Wed, 17 Jul 2002 04:06:09 -0500 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6H8u7O03436; Wed, 17 Jul 2002 17:56:07 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <2276674.1026924241@localhost> References: <2276674.1026924241@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <3434.1026896167@munnari.OZ.AU> Date: Wed, 17 Jul 2002 04:06:13 -0500 X-OldDate: Wed, 17 Jul 2002 17:56:07 +0900 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Ftp-WG: Re: draft-ietf-ftpext-mlst (fwd) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10383 Date: Wed, 17 Jul 2002 16:44:01 +0900 From: Patrik Fältström Message-ID: <2276674.1026924241@localhost> | Finally I manage to get all information from IESG members _and_ time to | summaarize them. OK, thanks, and I will just ignore the old repeated comments as requested in your later message. Please forward this to whatever other parts of the IESG are relevant. | (A) | | Section 3 talks about comparing the server's file modification time to the | client's. But 2.3 says that the times aren't synchronized. | | I asked what the issue was and got the following dialogue: | | >> The key sentence is in 2.3 before the one talking about time not being | >> synchronized: | >> | >> A server-FTP process should always use the same | >> time reference, so the times it returns will be consistent. | > | > Right. But it's easy to read "file modification time" as "local file | > modification time". I think the document should suggest asking for the | > modification time before a transfer, so that that can be compared with | > the modification time retrieved before a restart. OK, that seems simple enough, if no-one objects, I can do that (text that will be included will appear soon). | >> | >>> Servers should ensure that the unique identifier fact is not security | >>> sensitive, e.g., it should not be the NFS handle for the file. | >> | >> Is this something you want to the Security Considerations Section? | >> | > It probably should be there. Yes, that's reasonable too, will add text about that, again assuming no WG objection (take that caveat as a given in all below). | (B) | | Should this doc say that it updates STD 9, see sec 8? I have previously been told that I-D's aren't supposed to claim to update RFCs (and particularly standards). When this is published then yes, it will say exactly that - though whether it counts as an "Updates" or a "See Also" seems to depend upon what the rfc editor had for breakfast that day... See rfc2389, which has "See Also" for what I would have considered (and earlier considered) an "Updates". In any case, something about this will appear in the RFC. If the IESG want I can add it to the I-D as well. | (J) | | 7 says that all 256 octet values are permitted. Must telnet NVT characters | be escaped here? Or, should it be said that all 256 octet values are | allowed after NVT processing? Clarify. NVT processing is always done on the control connection in FTP. That's not news is it? So, all 256 after NVT processing, obviously. Section 2.2 already indicates that NVT applies, and that IAC needs to be escaped. Does it really need to be repeated in section 7? | (K) | | Servers should ensure that the unique identifier fact is not security | sensitive, e.g., it should not be the NFS handle for the file. | | This can be handled by explicit sentence in Security Consideration Section. This is a repeat of the 2nd half of (A) above. Will fix. kre From ftp-wg-owner@hethmon.com Wed Jul 17 06:16:58 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11471 for ; Wed, 17 Jul 2002 06:16:57 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717052522-3356-10 ; Wed, 17 Jul 2002 05:25:22 -0500 Received: from delta.cs.mu.OZ.AU (133.93.71.210 [133.93.71.210]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717052512-52426-9 ; Wed, 17 Jul 2002 05:25:17 -0500 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6HAFFO03844; Wed, 17 Jul 2002 19:15:16 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <3842.1026900915@munnari.OZ.AU> Date: Wed, 17 Jul 2002 05:25:21 -0500 X-OldDate: Wed, 17 Jul 2002 19:15:15 +0900 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: ftp-wg@hethmon.com Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11471 For the two changes requested that seem entirely reasonable to make, these are the two paragraphs I propose inserting into the draft. First, on times, and MDTM and restarts, in section 3 (MDTM), between what are currently the 2nd & 3rd paragraphs, I currently have added... Because the User and server FTPs' clocks are not necessarily synchronised, User FTPs intending to use this method should usually obtain the modification time of the file from the server before the initial RETRieval, and compare that with the modification time before a RESTart. If they differ, the files may have changed, and RESTart would be inadvisable. Where this is not possible, the User FTP should make sure to allow for possible clock skew when comparing times. And then, in section 11 (Security considerations) again between the old 2nd & 3rd paragraphs of draft-15, I have ... Server FTP should take care not to reveal sensitive information about files to unauthorised parties. In particular, some underlying filesystems provide a file identifier which, if known, can allow many of the filesystem protection mechanisms to be by-passed. That identifier would not be a suitable choice to use as the basis of the value of the unique fact. Before my draft draft becomes a real draft, are there any objections to either of those being inserted, or any suggestions for improved wording? Does anyone really believe that we need to say something about NVT processing in section 7? If there no objections, I'll send this draft to the I-D directories just before the IETF ends on Friday (if I manage to fit it in), otherwise on Monday (it won't get processed till the secretariat staff return from Japan anyway, I assume). kre From ftp-wg-owner@hethmon.com Wed Jul 17 07:57:34 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13696 for ; Wed, 17 Jul 2002 07:57:33 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717070559-61020-11 ; Wed, 17 Jul 2002 07:05:59 -0500 Received: from warp.hethmon.com (warp.hethmon.com [208.171.56.198]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717070553-32875-10 ; Wed, 17 Jul 2002 07:05:54 -0500 Message-Id: <20020717070553-32875-10@mail.hethmon.com> X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 17 Jul 2002 07:05:58 -0500 X-OldDate: Wed, 17 Jul 2002 07:56:57 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: kre@munnari.OZ.AU, phethmon@hethmon.com Subject: Ftp-WG: Re: draft-ietf-ftpext-mlst (fwd) Content-Transfer-Encoding: 7bit Finally I manage to get all information from IESG members _and_ time to summaarize them. Here they are (many I think are minor and can be done just because I think a new version is needed anyways): (A) Section 3 talks about comparing the server's file modification time to the client's. But 2.3 says that the times aren't synchronized. I asked what the issue was and got the following dialogue: >> The key sentence is in 2.3 before the one talking about time not being >> synchronized: >> >> A server-FTP process should always use the same >> time reference, so the times it returns will be consistent. > > Right. But it's easy to read "file modification time" as "local file > modification time". I think the document should suggest asking for the > modification time before a transfer, so that that can be compared with > the modification time retrieved before a restart. >> >>> Servers should ensure that the unique identifier fact is not security >>> sensitive, e.g., it should not be the NFS handle for the file. >> >> Is this something you want to the Security Considerations Section? >> > It probably should be there. (B) Should this doc say that it updates STD 9, see sec 8? (C) Section 3.4 starts: If we assume the existence of three files, A B and C, and a directory D, and no other files at all but later it assumes the existence of files named "file6" and "19990929043300 File6". (D) Section 7.1: For these purposes, the contents of a directory are whatever file names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Earlier text refers to both "file names" and "directory names", implying that they are seperate things, so this text seems to preclude including directory names in MLSx responses. Should this say "file or directory names"? (E) In the last paragraph of 7.2: Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. Should this refer to section 7.9, since this is a forward reference to the fact that the set is requestable? (F) Section 7.5.1: ... file -- a file entry ... type-val = "File" / "cdir" / "pdir" / "dir" / os-type Fact values are case-sensitive, right, so the ABNF should probably use "file". (G) Relevant to section 7.5.1.2 and 7.5.1.4: All the examples in section 7.7 show listings where, if present, "type=cdir" and "type=pdir" are at the beginning, despite the warnings that they may be anywhere. Even if it means modifying an example from what was actually returned by an implementation, I think it'd be worth having an example that has these entries elsewhere, since examples are commonly heavily used during implementation. (H) Section 7.7.9: This server seems to use uppercase when fully-qualifying the type=cdir entry on MLSD responses, and lowercase when fully-qualifying responses to MSLT. This is a little confusing, so although the explanation does mention that it is a case-independent NVFS, perhaps it could explicitly say "and that's why it uses different case for the fully-qualified path in different responses". (I) The last example in section 7.8.1: S> MLST Type*;Size*;Modify*;Perm;Unique*; ... All of the facts supported by this server are enabled by default. In the example response, Perm is not enabled by default. (J) 7 says that all 256 octet values are permitted. Must telnet NVT characters be escaped here? Or, should it be said that all 256 octet values are allowed after NVT processing? Clarify. (K) Servers should ensure that the unique identifier fact is not security sensitive, e.g., it should not be the NFS handle for the file. This can be handled by explicit sentence in Security Consideration Section. ===================END FORWARDED MESSAGE=================== Paul Hethmon phethmon@hethmon.com http://www.hethmon.com From ftp-wg-owner@hethmon.com Wed Jul 17 15:59:32 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28620 for ; Wed, 17 Jul 2002 15:59:30 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717150237-58944-10 ; Wed, 17 Jul 2002 15:02:37 -0500 Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717150235-33812-9 ; Wed, 17 Jul 2002 15:02:35 -0500 Message-ID: <20020717195325.67786.qmail@web21102.mail.yahoo.com> Received: from [152.163.188.196] by web21102.mail.yahoo.com via HTTP; Wed, 17 Jul 2002 12:53:25 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 2002 15:02:35 -0500 X-OldDate: Wed, 17 Jul 2002 12:53:25 -0700 (PDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Pat LaVarre To: ftp-wg@hethmon.com Subject: Ftp-WG: FEAT UTF-8 in review http://www.ietf.org/rfc/rfc2640.txt > X-Listname: ftp-wg@hethmon.com > ... NVT processing, obviously. http://www.ietf.org/html.charters/ftpext-charter.html http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt > May 2002 Hey, wow, I just now (17 July) stumbled into this FEAT UTF-8 draft, distinct from FEAT UTF8, courtesy the links quoted. Great stuff, thank you. > To restore inter-operation with existing implementations, > the FTP should provide a means for the user > to express its willingness to accept UTF-8 encoded pathnames, > and servers should not transmit UTF-8 encoded pathnames > without prior authorization from the user. Yes! But am I understanding correctly? According to this FEAT UTF-8 draft ... > The assertion in [RFC2640] that CR NUL > is not a Telnet end-of-line sequence is incorrect. ... > RFC1123 ... accept either CR LF or CR NUL > as representing Telnet end-of-line when received Clients & servers should also liberally accept LF as Telnet end-of-line, yes? > When transmitting UTF-8 encoded characters, > the shortest form should be used. http://www.unicode.org says Must use shortest form, to avoid the hole of a s*curity filter rejecting only shortest-form and failing to reject a longer, not so plainly equivalent, form, such as the UTF-8 outside of *( %x20-7E / %x80-EF ) that isn't shortest form for any char of the x0000..FFFF range. > The ABNF for pathnames presented in [RFC2640] is incorrect. > ... the correct syntax is > PATHNAME = *( %x20-7E ) > PATHNAME = *( %x20-7E / %x80-FF ) > both cases render moot all discussion > about the use of the characters CR, LF, and NUL, in pathnames. Eh? As a server, in a folder, I have a local filename that includes a local Eol. How should that filename appear in my NLST data, supposing the client asked for FEAT UTF-8 NLST? Shortest-form UTF-8 would commonly be x0A or x0D or x 0D 0A, depending on locale, sent as x0A or x 0D 00 or x 0D 00 0A. When should & must contradict, must wins, so I must conclude that I must not use shortest form UTF-8 to represent EOL in a path name? I should use the next shortest form i.e. x C0 8A and x C0 8D and x C0 8D C0 8A? If that conclusion is correct, should we state it? If the shortest form UTF-8 encoding at the client or at the server contains %x00-1F, then those bytes should be transmitted as the next shortest form i.e. x C0 80 .. x C0 9F? > allow internationalized pathnames > support internationalization of response text Distinct requirements, the first alone more commonly useful, aye, thank you. > OPTS UTF-8 [ NLST ] Why is NLST an option? Why not require it in the syntax. Why not say every path name is UTF-8 or not? And what about LIST and MLST and MLSD and so on? Pat LaVarre __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From ftp-wg-owner@hethmon.com Wed Jul 17 23:03:55 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09088 for ; Wed, 17 Jul 2002 23:03:54 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717221217-58552-10 ; Wed, 17 Jul 2002 22:12:18 -0500 Received: from warp.hethmon.com (warp.hethmon.com [208.171.56.198]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717221214-32856-9 ; Wed, 17 Jul 2002 22:12:16 -0500 Message-Id: <20020717221214-32856-9@mail.hethmon.com> X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 17 Jul 2002 22:12:16 -0500 X-OldDate: Wed, 17 Jul 2002 23:03:21 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Marc Huber To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Content-Transfer-Encoding: 7bit On Wed, Jul 17, 2002 at 05:25:21AM -0500, Robert Elz wrote: > Does anyone really believe that we need to say something about NVT > processing in section 7? For MLST, within a file name is transmitted as . However, that only covers the control connection. For the data connection, no such escape mechanism exists, and transmitting a file name containing the sequence as-is in response to MLSD is guaranteed to cause trouble. Marc ===================END FORWARDED MESSAGE=================== Paul Hethmon phethmon@hethmon.com http://www.hethmon.com From ftp-wg-owner@hethmon.com Wed Jul 17 23:04:25 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09105 for ; Wed, 17 Jul 2002 23:04:24 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717221253-60981-14 ; Wed, 17 Jul 2002 22:12:53 -0500 Received: from warp.hethmon.com (warp.hethmon.com [208.171.56.198]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717221251-32865-13 ; Wed, 17 Jul 2002 22:12:51 -0500 Message-Id: <20020717221251-32865-13@mail.hethmon.com> X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 17 Jul 2002 22:12:52 -0500 X-OldDate: Wed, 17 Jul 2002 23:03:57 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: kre@munnari.OZ.AU, phethmon@hethmon.com Subject: Ftp-WG: Re: draft-ietf-ftpext-mlst (fwd) Content-Transfer-Encoding: 7bit Finally I manage to get all information from IESG members _and_ time to summaarize them. Here they are (many I think are minor and can be done just because I think a new version is needed anyways): (A) Section 3 talks about comparing the server's file modification time to the client's. But 2.3 says that the times aren't synchronized. I asked what the issue was and got the following dialogue: >> The key sentence is in 2.3 before the one talking about time not being >> synchronized: >> >> A server-FTP process should always use the same >> time reference, so the times it returns will be consistent. > > Right. But it's easy to read "file modification time" as "local file > modification time". I think the document should suggest asking for the > modification time before a transfer, so that that can be compared with > the modification time retrieved before a restart. >> >>> Servers should ensure that the unique identifier fact is not security >>> sensitive, e.g., it should not be the NFS handle for the file. >> >> Is this something you want to the Security Considerations Section? >> > It probably should be there. (B) Should this doc say that it updates STD 9, see sec 8? (C) Section 3.4 starts: If we assume the existence of three files, A B and C, and a directory D, and no other files at all but later it assumes the existence of files named "file6" and "19990929043300 File6". (D) Section 7.1: For these purposes, the contents of a directory are whatever file names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Earlier text refers to both "file names" and "directory names", implying that they are seperate things, so this text seems to preclude including directory names in MLSx responses. Should this say "file or directory names"? (E) In the last paragraph of 7.2: Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. Should this refer to section 7.9, since this is a forward reference to the fact that the set is requestable? (F) Section 7.5.1: ... file -- a file entry ... type-val = "File" / "cdir" / "pdir" / "dir" / os-type Fact values are case-sensitive, right, so the ABNF should probably use "file". (G) Relevant to section 7.5.1.2 and 7.5.1.4: All the examples in section 7.7 show listings where, if present, "type=cdir" and "type=pdir" are at the beginning, despite the warnings that they may be anywhere. Even if it means modifying an example from what was actually returned by an implementation, I think it'd be worth having an example that has these entries elsewhere, since examples are commonly heavily used during implementation. (H) Section 7.7.9: This server seems to use uppercase when fully-qualifying the type=cdir entry on MLSD responses, and lowercase when fully-qualifying responses to MSLT. This is a little confusing, so although the explanation does mention that it is a case-independent NVFS, perhaps it could explicitly say "and that's why it uses different case for the fully-qualified path in different responses". (I) The last example in section 7.8.1: S> MLST Type*;Size*;Modify*;Perm;Unique*; ... All of the facts supported by this server are enabled by default. In the example response, Perm is not enabled by default. (J) 7 says that all 256 octet values are permitted. Must telnet NVT characters be escaped here? Or, should it be said that all 256 octet values are allowed after NVT processing? Clarify. (K) Servers should ensure that the unique identifier fact is not security sensitive, e.g., it should not be the NFS handle for the file. This can be handled by explicit sentence in Security Consideration Section. ===================END FORWARDED MESSAGE=================== Paul Hethmon phethmon@hethmon.com http://www.hethmon.com From ftp-wg-owner@hethmon.com Wed Jul 17 23:45:38 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09922 for ; Wed, 17 Jul 2002 23:45:37 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717225404-11735-13 ; Wed, 17 Jul 2002 22:54:04 -0500 Received: from delta.cs.mu.OZ.AU (133.93.71.210 [133.93.71.210]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020717225402-50239-10 ; Wed, 17 Jul 2002 22:54:02 -0500 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6I3i6802401 for ; Thu, 18 Jul 2002 12:44:07 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <20020717221214-32856-9@mail.hethmon.com> References: <20020717221214-32856-9@mail.hethmon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <2399.1026963846@munnari.OZ.AU> Date: Wed, 17 Jul 2002 22:54:03 -0500 X-OldDate: Thu, 18 Jul 2002 12:44:06 +0900 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Date: Wed, 17 Jul 2002 22:12:16 -0500 From: Marc Huber Message-ID: <20020717221214-32856-9@mail.hethmon.com> | For the data connection, no such escape | mechanism exists, and transmitting a file name containing | the sequence as-is in response to MLSD is | guaranteed to cause trouble. This is a different issue entirely, but it is a good point. Is this a problem that we need to solve? If not, then we should probably at least make mention of it somewhere. kre From ftp-wg-owner@hethmon.com Thu Jul 18 03:05:44 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24207 for ; Thu, 18 Jul 2002 03:05:44 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718021406-63005-10 ; Thu, 18 Jul 2002 02:14:06 -0500 Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718021403-38207-9 ; Thu, 18 Jul 2002 02:14:03 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id DAA27898; Thu, 18 Jul 2002 03:04:54 -0400 (EDT) In-Reply-To: Your message of Wed, 17 Jul 2002 15:02:35 -0500 Message-ID: Date: Thu, 18 Jul 2002 02:14:05 -0500 X-OldDate: Thu, 18 Jul 2002 3:04:53 EDT Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jeffrey Altman To: FTPEXT Working Group Subject: Ftp-WG: FEAT UTF-8 in review > > The assertion in [RFC2640] that CR NUL > > is not a Telnet end-of-line sequence is incorrect. > ... > > RFC1123 ... accept either CR LF or CR NUL > > as representing Telnet end-of-line when received > > Clients & servers should also liberally accept LF as > Telnet end-of-line, yes? No. This is not a telnet end of line Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ftp-wg-owner@hethmon.com Thu Jul 18 12:59:08 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08211 for ; Thu, 18 Jul 2002 12:59:07 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718120726-9284-11 ; Thu, 18 Jul 2002 12:07:27 -0500 Received: from crydee.sai.msu.ru (crydee.sai.msu.ru [195.208.220.203]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718120723-46532-10 ; Thu, 18 Jul 2002 12:07:23 -0500 Received: from localhost (asv1@localhost) by crydee.sai.msu.ru (8.11.6/8.11.6) with ESMTP id g6IH7KH64234 for ; Thu, 18 Jul 2002 21:07:20 +0400 (MSD) (envelope-from asv1@crydee.sai.msu.ru) In-Reply-To: <6967.1026661994@munnari.OZ.AU> Message-ID: <20020718210223.X64010-100000@crydee.sai.msu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 18 Jul 2002 12:07:25 -0500 X-OldDate: Thu, 18 Jul 2002 21:07:20 +0400 (MSD) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Sergey Ayukov To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM On Sun, 14 Jul 2002, Robert Elz wrote: > This "feature" of some clients was known back when the MDTM test > in the mlst draft was being written - that's the point of one of > the examples showing a space in a file name with the part before > the space looking very much like a time ... > > So, no, you certainly should not be implementing that broken > behaviour. > > On the other hand, creating a new command to do this would certainly > be possible - no-one so far has been sufficiently motivated to > do the work. ncftp/ncftpd allow to modify file dates on server via 'SITE UTIME' command, and I have followed this approach in NFTP. Syntax looks like 'SITE UTIME filename YYYYMMDDhhmmss YYYYMMDDhhmmss YYYYMMDDhhmmss UTC' where three times correspond to Unix-like 'access, modification, status change' times. -- Dr. Sergey Ayukov | NFTP: Spell differently. Work faster. http://www.ayukov.com | mailto:asv@ayukov.com | runs on: BeOS * OS/2 * Unix * Windows From ftp-wg-owner@hethmon.com Thu Jul 18 13:03:14 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08272 for ; Thu, 18 Jul 2002 13:03:13 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718121141-12236-15 ; Thu, 18 Jul 2002 12:11:41 -0500 Received: from crydee.sai.msu.ru (crydee.sai.msu.ru [195.208.220.203]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718121139-49479-14 ; Thu, 18 Jul 2002 12:11:40 -0500 Received: from localhost (asv1@localhost) by crydee.sai.msu.ru (8.11.6/8.11.6) with ESMTP id g6IHBcK64294 for ; Thu, 18 Jul 2002 21:11:38 +0400 (MSD) (envelope-from asv1@crydee.sai.msu.ru) In-Reply-To: Message-ID: <20020718210805.X64010-100000@crydee.sai.msu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 18 Jul 2002 12:11:40 -0500 X-OldDate: Thu, 18 Jul 2002 21:11:38 +0400 (MSD) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Sergey Ayukov To: FTPEXT Working Group Subject: Ftp-WG: Potentially unsound use of MDTM On Mon, 15 Jul 2002, David Somers wrote: > And finally, and completely unrelated to the above, does anybody know of any > clients that support the MLSx commands? Later versions of NFTP (since December 1999) support MLST to some extent but it is not enabled by default, you have to set 'try-FTP-extensions=yes' in options file. Contact me if you need more information. -- Dr. Sergey Ayukov | NFTP: Spell differently. Work faster. http://www.ayukov.com | mailto:asv@ayukov.com | runs on: BeOS * OS/2 * Unix * Windows From ftp-wg-owner@hethmon.com Thu Jul 18 15:27:26 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11190 for ; Thu, 18 Jul 2002 15:27:25 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718143543-16645-10 ; Thu, 18 Jul 2002 14:35:43 -0500 Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718143520-55557-9 ; Thu, 18 Jul 2002 14:35:40 -0500 Message-Id: <20020718143520-55557-9@mail.hethmon.com> Received: (qmail 75869 messnum 930841 invoked from network[159.134.150.185/p150-185.as1.cav.cavan.eircom.net]); 18 Jul 2002 17:44:07 -0000 Received: from p150-185.as1.cav.cavan.eircom.net (HELO uauu.net) (159.134.150.185) by mail01.svc.cra.dublin.eircom.net (qp 75869) with SMTP; 18 Jul 2002 17:44:07 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_001D_53B46E59.C27024C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Date: Thu, 18 Jul 2002 14:35:41 -0500 X-OldDate: Thu, 18 Jul 02 17:43:01 GMT Daylight Time Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "" To: "sts" Subject: Ftp-WG: Spam Alert Issue ------=_NextPart_000_001D_53B46E59.C27024C0 Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl Ig0KeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCINCnht bG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0 YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 d2luZG93cy0xMjUyIj4NCjxtZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVu dD4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0K PG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPGxp bmsgcmVsPUZpbGUtTGlzdA0KaHJlZj0iLi9UaGUlMjBObyUyMDElMjBCdXNpbmVzc21haWxs aXN0JTIwaW4lMjB0aGUlMjBXb3JsZF9maWxlcy9maWxlbGlzdC54bWwiPg0KPHRpdGxlPlRo ZSBObyAxIEJ1c2luZXNzbWFpbGxpc3QgaW4gdGhlIFdvcmxkPC90aXRsZT4NCjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOkRvY3VtZW50UHJvcGVydGllcz4NCiAgPG86QXV0aG9y PlBhdHJpY2sgTWMgQ2FubjwvbzpBdXRob3I+DQogIDxvOlRlbXBsYXRlPk5vcm1hbDwvbzpU ZW1wbGF0ZT4NCiAgPG86TGFzdEF1dGhvcj5QYXRyaWNrIE1jIENhbm48L286TGFzdEF1dGhv cj4NCiAgPG86UmV2aXNpb24+MjwvbzpSZXZpc2lvbj4NCiAgPG86VG90YWxUaW1lPjIxPC9v OlRvdGFsVGltZT4NCiAgPG86Q3JlYXRlZD4yMDAyLTA3LTE4VDE2OjEyOjAwWjwvbzpDcmVh dGVkPg0KICA8bzpMYXN0U2F2ZWQ+MjAwMi0wNy0xOFQxNjoxMjowMFo8L286TGFzdFNhdmVk Pg0KICA8bzpQYWdlcz4xPC9vOlBhZ2VzPg0KICA8bzpXb3Jkcz4xNTQ8L286V29yZHM+DQog IDxvOkNoYXJhY3RlcnM+ODc5PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+MjFzdG5l dHdvcms8L286Q29tcGFueT4NCiAgPG86TGluZXM+NzwvbzpMaW5lcz4NCiAgPG86UGFyYWdy YXBocz4xPC9vOlBhcmFncmFwaHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjEwNzk8 L286Q2hhcmFjdGVyc1dpdGhTcGFjZXM+DQogIDxvOlZlcnNpb24+OS4yNzIwPC9vOlZlcnNp b24+DQogPC9vOkRvY3VtZW50UHJvcGVydGllcz4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0 eWxlPg0KPCEtLQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KaDENCgl7bXNvLXN0eWxlLW5leHQ6Tm9ybWFsOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246Y2VudGVyOw0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1vdXRsaW5l LWxldmVsOjE7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgljb2xvcjpibHVlOw0KCW1zby1mb250LWtlcm5pbmc6MHB0O30NCnAuTXNv VGl0bGUsIGxpLk1zb1RpdGxlLCBkaXYuTXNvVGl0bGUNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJbXNvLXBhZ2luYXRp b246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToyMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpyZWQ7fQ0KcC5N c29Cb2R5VGV4dCwgbGkuTXNvQm9keVRleHQsIGRpdi5Nc29Cb2R5VGV4dA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglj b2xvcjojMzM2NkZGO30NCnAuTXNvQm9keVRleHQyLCBsaS5Nc29Cb2R5VGV4dDIsIGRpdi5N c29Cb2R5VGV4dDINCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ dGV4dC1hbGlnbjpjZW50ZXI7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZv bnQtc2l6ZToxOC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7DQoJZm9u dC1zdHlsZTppdGFsaWM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2lu Z2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpz aW5nbGU7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsNCgltc28taGVhZGVyLW1hcmdpbjoz NS40cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzUuNHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6 MDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8 L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tR0IgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHls ZT0ndGFiLWludGVydmFsOjM2LjBwdCc+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxw IGNsYXNzPU1zb1RpdGxlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PCFbaWYgIXN1cHBv cnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29UaXRsZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjwhW2lmICFz dXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvVGl0bGU+PGI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5U aGUgTm8gMSBCdXNpbmVzc21haWxsaXN0IGluIHRoZQ0KV29ybGQ8bzpwPjwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29UaXRsZT48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvVGl0bGU+PGI+PGk+PHU+U3BhbSBpcyBh IFNlcmlvdXMgT2ZmZW5jZTxvOnA+PC9vOnA+PC91PjwvaT48L2I+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MjAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6cmVkJz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50 ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48aT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxOC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayc+V2FudCB0 byBleHBvc2UNCnlvdXIgPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxpPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjE4LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrJz5Ib21lIEJhc2VkDQpCdXNpbmVzcyB0byAxMDAwknMgcGVyIGRheS48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTguMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2snPjwhW2lm ICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1h bGlnbjpjZW50ZXInPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjE4LjBwdDttc28tYmlkaS1m b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrJz48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj6gPC9zcGFuPio8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqANCjwv c3Bhbj5TcGFtIEZyZWU8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqAgPC9zcGFu Pio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1j ZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJs dWUnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPGgxPlNwZWNpYWwgb2ZmZXIgZm9yIHRoZSBtb250aCBvZiBK dWx5IDAyPC9oMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQpzdHlsZT0nY29sb3I6Ymx1ZSc+PCFbaWYgIXN1 cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDI+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+NiBN b250aCBNZW1iZXJzaGlwICsgRnJlZSBBbnRpIJYNClZpcnVzIFNvZnR3YXJlIG9ubHkgJDI0 Ljk1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4NCnN0eWxlPSdjb2xvcjpi bHVlJz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5 bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsdWUnPlRoaXMg b2ZmZXIgZW5kcyBKdWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQpz dHlsZT0nY29sb3I6Ymx1ZSc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtl bmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxp Z249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4NCnN0eWxlPSdjb2xv cjpibHVlJz5WaXNpdCBvdXIgc2l0ZSBub3cgc2VlIHdoYXQgd2UgY2FuIG9mZmVyIHlvdS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50 ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsdWUn PjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjIwLjBwdDttc28t YmlkaS1mb250LXNpemU6MTIuMHB0O2NvbG9yOnJlZCc+PGENCmhyZWY9Imh0dHA6Ly93d3cu YnVzaW5lc3NtYWlsbGlzdC5jb20vIj48c3BhbiBzdHlsZT0nY29sb3I6cmVkJz5odHRwOi8v d3d3LmJ1c2luZXNzbWFpbGxpc3QuY29tLzwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsdWUnPjwhW2lmICFzdXBwb3J0 RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KbGV0dGVyLXNwYWNpbmc6LS4yNXB0Jz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5 Jz5UaGlzIGUtbWFpbCBpcyBzZW50IHRvIHlvdSBpbg0KY29tcGxpYW5jZSB3aXRoIHN0cmlj dCBhbnRpLWFidXNlIGFuZCBubyBzcGFtIHJlZ3VsYXRpb25zLCBhbmQgaGFzIGEgcmVtb3Zl DQptZWNoYW5pc20gYnVpbHQgaW4gZm9yIHJlbW92aW5nIHlvdXJzZWxmIGZyb20gb3VyIG1h aWxpbmcgZGF0YSBiYXNlLiBZb3VyDQplLW1haWwgd2FzIG9idGFpbmVkIGFzIGEgcmVzdWx0 IG9mIHBvc3RpbmcgdG8gbGlua3MsIGNsYXNzaWZpZWQgYWR2ZXJ0cywgb3B0LWluDQptYWls aW5nIGxpc3RzIG9yIHlvdSBoYXZlIGUtbWFpbGVkIHVzIGluIHRoZSBwYXN0LlRvIHJlbW92 ZSB5b3VyIGUtbWFpbCBzaW1wbHkNCnJlcGx5IHdpdGggPGEgaHJlZj0ibWFpbHRvOnN5c3Rl bXhAdXR2aW50ZXJuZXQuY29tP3N1YmplY3Q9cmVtb3ZlIj5yZW1vdmU8L2E+DQppbiB0aGUg c3ViamVjdCBsaW5lLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPqCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKANCjwvc3Bhbj4qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKio8L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50 ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsdWUn PjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQpzdHlsZT0nY29sb3I6cmVkJz48IVtpZiAhc3Vw cG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCiAgICA= ------=_NextPart_000_001D_53B46E59.C27024C0-- From ftp-wg-owner@hethmon.com Thu Jul 18 19:30:06 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15313 for ; Thu, 18 Jul 2002 19:30:06 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718183831-48567-10 ; Thu, 18 Jul 2002 18:38:31 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718183829-57073-9 ; Thu, 18 Jul 2002 18:38:29 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6INTJd02323 for ; Thu, 18 Jul 2002 19:29:19 -0400 Message-ID: <003501c22eb2$f0c69e00$0b0d85cd@vr.net> References: <20020717195325.67786.qmail@web21102.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Thu, 18 Jul 2002 18:38:30 -0500 X-OldDate: Thu, 18 Jul 2002 19:29:13 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: FEAT UTF-8 in review Content-Transfer-Encoding: 7bit > Clients & servers should also liberally accept LF as > Telnet end-of-line, yes? The only eol talked about for telnet are CRLF and CRNUL, the telnet allows others as local options. The problem is you don't know what is eol, except that it's not going to be one of the 96 graphical ASCII characters. > > When transmitting UTF-8 encoded characters, > > the shortest form should be used. > > http://www.unicode.org says Must use shortest form, to > avoid the hole of a s*curity filter rejecting only > shortest-form and failing to reject a longer, not so > plainly equivalent, form, such as the UTF-8 outside of > *( %x20-7E / %x80-EF ) that isn't shortest form for > any char of the x0000..FFFF range. From the point if view of the FTP, 'should' is good enough. Let's allow that there may be good and valuable reasons for some applications to ignore the requirement. > > The ABNF for pathnames presented in [RFC2640] is > incorrect. > > ... the correct syntax is > > PATHNAME = *( %x20-7E ) > > PATHNAME = *( %x20-7E / %x80-FF ) > > both cases render moot all discussion > > about the use of the characters CR, LF, and NUL, in > pathnames. > > Eh? > As a server, in a folder, I have a local filename that > includes a local Eol. > > How should that filename appear in my NLST data, > supposing the client asked for FEAT UTF-8 NLST? It cannot appear on ANY FTP command or response. Sorry. > If that conclusion is correct, should we state it? If > the shortest form UTF-8 encoding at the client or at > the server contains %x00-1F, then those bytes should > be transmitted as the next shortest form i.e. x C0 80 > .. x C0 9F? I avoided the issue in this draft as being too contentious. I'm happy if people just realize that you cannot send ( %x00-1F / %x7F ) on ANY FTP command or reply and expect correct interoperation. > > OPTS UTF-8 [ NLST ] > > Why is NLST an option? Why not require it in the > syntax. Why not say every path name is UTF-8 or not? > And what about LIST and MLST and MLSD and so on? I only specified NLST because I don't see LIST as being useful for automata, and MLSx already seems to handle the issue. From ftp-wg-owner@hethmon.com Thu Jul 18 19:33:29 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15472 for ; Thu, 18 Jul 2002 19:33:28 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718184154-19430-16 ; Thu, 18 Jul 2002 18:41:55 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020718184152-58000-15 ; Thu, 18 Jul 2002 18:41:53 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6INWdd02541 for ; Thu, 18 Jul 2002 19:32:39 -0400 Message-ID: <003e01c22eb3$67bf2900$0b0d85cd@vr.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Thu, 18 Jul 2002 18:41:53 -0500 X-OldDate: Thu, 18 Jul 2002 19:32:32 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: FEAT UTF-8 in review Content-Transfer-Encoding: 7bit > > Clients & servers should also liberally accept LF as > > Telnet end-of-line, yes? > > No. This is not a telnet end of line Actually, it could be, but to be one required both ends to have been locally configured to accept it as such; which the TELNET protocol allows. Basically, TELNET end-of-line is whatever you want it to be, so long as it does not conflict with the 96 displayable ASCII characters ( %x20-7E ). From ftp-wg-owner@hethmon.com Fri Jul 19 09:58:22 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08403 for ; Fri, 19 Jul 2002 09:58:21 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020719090642-47600-10 ; Fri, 19 Jul 2002 09:06:42 -0500 Received: from web21110.mail.yahoo.com (web21110.mail.yahoo.com [216.136.227.112]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020719090637-34794-10 ; Fri, 19 Jul 2002 09:06:37 -0500 Message-ID: <20020719135727.23041.qmail@web21110.mail.yahoo.com> Received: from [205.188.208.103] by web21110.mail.yahoo.com via HTTP; Fri, 19 Jul 2002 06:57:27 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 2002 09:06:41 -0500 X-OldDate: Fri, 19 Jul 2002 06:57:27 -0700 (PDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Pat LaVarre To: ftp-wg@hethmon.com Subject: Ftp-WG: FEAT UTF-8 in review > > > LF as Telnet end-of-line ... > From: Gregory A Lundberg > ... Actually, it could be, 1) Then it is permissible for the default local configuration to accept LF as a TELNET end-of-line. 2) And given this is permissible, then it is also appropriately liberal, because enough actual Ftp clients/servers are by default configured to accept LF as EOL that working to discover which are rude enough to send LF as EOL is not a useful way to spend time. 3) Or have I misunderstood? Thanks again in advance, Pat LaVarre -----Original Message----- From: Gregory A Lundberg [mailto:lundberg@vr.net] Sent: Thu 7/18/2002 5:41 PM To: FTPEXT Working Group Cc: Subject: Ftp-WG: FEAT UTF-8 in review > > Clients & servers should also liberally accept LF as > > Telnet end-of-line, yes? > > No. This is not a telnet end of line Actually, it could be, but to be one required both ends to have been locally configured to accept it as such; which the TELNET protocol allows. Basically, TELNET end-of-line is whatever you want it to be, so long as it does not conflict with the 96 displayable ASCII characters ( %x20-7E ). [[[ Please ignore any Yahoo spam which follows. ]]] __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From ftp-wg-owner@hethmon.com Fri Jul 19 22:05:56 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22300 for ; Fri, 19 Jul 2002 22:05:56 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020719211425-18201-10 ; Fri, 19 Jul 2002 21:14:25 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020719211422-56855-9 ; Fri, 19 Jul 2002 21:14:23 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6K25Cd03302 for ; Fri, 19 Jul 2002 22:05:12 -0400 Message-ID: <001101c22f91$e1dfd020$0b0d85cd@vr.net> References: <20020719135727.23041.qmail@web21110.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Fri, 19 Jul 2002 21:14:24 -0500 X-OldDate: Fri, 19 Jul 2002 22:05:06 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: FEAT UTF-8 in review Content-Transfer-Encoding: 7bit > Then it is permissible for the default local > configuration to accept LF as a TELNET end-of-line. Permissible, yes. But the required minimum does not include LF to mean end-of-line. > And given this is permissible, then it is also > appropriately liberal, because enough actual Ftp > clients/servers are by default configured to accept LF > as EOL that working to discover which are rude enough > to send LF as EOL is not a useful way to spend time. As I read it, a server could be configured that way, but I would expect few, if any users to expect that to be the case. I would say it would be an 'agreed upon' option, where agreement could be out-of-band, such as an administrative requirement. From ftp-wg-owner@hethmon.com Sun Jul 21 03:03:06 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02389 for ; Sun, 21 Jul 2002 03:03:05 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721021135-64098-10 ; Sun, 21 Jul 2002 02:11:35 -0500 Received: from hyc (202.101.160.238 [202.101.160.238]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721021132-33220-9 ; Sun, 21 Jul 2002 02:11:33 -0500 Message-Id: <20020721021132-33220-9@mail.hethmon.com> MIME-Version: 1.0 (produced by Synapse) x-mailer: Synapse - Delphi & Kylix TCP/IP library by Lukas Gebauer Content-type: text/html; charset=UTF-8 Content-Transfer-Encoding: Quoted-printable Content-Disposition: inline Content-Description: HTML text Date: Sun, 21 Jul 2002 02:11:33 -0500 X-OldDate: Sun, 21 Jul 2002 14:41:23 +0800 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Member.Servicer To: ftp-wg@hethmon.com Subject: Ftp-WG: Live 20 years longer with HGH Content-Transfer-Encoding: Quoted-printable =3Chtml=3E=3Cbody onload=3D=22window=2Eopen=28'http=3A=2F=2F202=2E101=2E163=2E34=3A81= =2Fultimatehgh=5F run=2F'=29=22 bgColor=3D=22#CCCCCC=22 topmargin=3D1 onMouseOver=3D=22window=2Estatus=3D''=3B return true=22 oncontextmenu=3D=22return false=22 ondragstart=3D=22return false=22 onselectstart=3D=22return false=22=3E =3Cdiv align=3D=22center=22=3EHello=2C =5B!To!=5D=3CBR=3E=3CBR=3E=3C=2Fdiv= =3E=3Cdiv align=3D=22center=22=3E=3C=2Fdiv=3E=3Cp align=3D=22center=22=3E=3Cb=3E= =3Cfont face=3D=22Arial=22 size=3D=224=22=3EHuman Growth Hormone Therapy=3C=2Ffont=3E=3C=2Fb=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cb=3E=3Cfont face=3D=22Arial=22 size=3D=224= =22=3ELose weight while building lean muscle mass=3Cbr=3Eand reversing the ravages of aging all at once=2E=3C=2Ffont=3E=3Cfont face=3D=22Arial=22= size=3D=223=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont face=3D=22Arial=22 size=3D=223=22=3E =3Cbr= =3ERemarkable discoveries about Human Growth Hormones =28=3Cb=3EHGH=3C=2Fb=3E=29 =3Cbr=3Eare changing the way we think about aging and weight loss=2E=3C=2Ffont=3E=3C=2Fp=3E =3Ccenter=3E=3Ctable width=3D=22481=22=3E=3Ctr=3E=3Ctd height=3D=222=22 width=3D=22247=22=3E=3Cp align=3D=22left=22=3E=3Cb=3E=3Cfont face=3D= =22Arial=2C Helvetica=2C sans-serif=22 size=3D=223=22=3ELose Weight=3Cbr=3EBuild Muscle Tone=3Cbr=3EReverse Aging=3Cbr=3E Increased Libido=3Cbr=3EDuration Of Penile Erection=3Cbr=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Fp=3E=3C=2Ftd=3E=3Ctd height= =3D=222=22 width=3D=22222=22=3E=3Cp align=3D=22left=22=3E=3Cb=3E=3Cfont face=3D= =22Arial=2C Helvetica=2C sans-serif=22 size=3D=223=22=3EHealthier Bones=3Cbr=3E Improved Memory=3Cbr=3EImproved skin=3Cbr=3ENew Hair Growth=3Cbr=3EWrinkle Disappearance =3C=2Ffont=3E=3C=2Fb=3E=3C=2Fp=3E=3C=2Ftd=3E=3C=2Ftable=3E=3C=2Fcenter=3E =3Cp align=3D=22center=22=3E=3Ca href=3D=22http=3A=2F=2F202=2E101=2E163=2E34=3A81=2Fultimatehgh=5Frun=2F=22= =3E=3Cfont face=3D=22Arial=22 size=3D=224=22=3E=3Cb=3EVisit Our Web Site and Learn The Facts =3A Click Here=3C=2Fb=3E=3C=2Ffont=3E=3C=2Fa=3E=3Cbr=3E =3Cbr=3E =3Ca href=3D=22http=3A=2F=2F64=2E123=2E160=2E91=3A81=2Fultimatehgh=5Frun= =2F=22=3E=3Cfont size=3D=224=22=3E=3Cb=3EOR Here=3C=2Fb=3E=3C=2Ffont=3E=3C=2Fa=3E=3C=2Fp=3E =3Cdiv align=3D=22center=22=3E=3Cbr=3E You are receiving this email as a subscr=3C!----=3Eiber=3Cbr=3E to the Opt=3C!----=3E-In Ameri=3C!----=3Eca Mailin=3C!----=3Eg Lis=3C!----=3Et=2E =3Cbr=3E To remo=3C!----=3Eve your=3C!----=3Eself from all related mailli=3C!--me--=3Ests=2C=3Cbr=3Ejust =3Ca href=3D=22http=3A=2F=2F64=2E123=2E160=2E91=3A81=2Fultimatehgh=5Frun= =2Fremove=2Ephp=3Fu serid=3D=5B!To!=5D=22=3EClick Here=3C=2Fa=3E=3C=2Fdiv=3E=3C=2Fbody=3E=3C= =2Fhtml=3E From ftp-wg-owner@hethmon.com Sun Jul 21 04:25:02 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03099 for ; Sun, 21 Jul 2002 04:25:01 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721033322-25120-10 ; Sun, 21 Jul 2002 03:33:22 -0500 Received: from sklave3.rackland.de (sklave3.rackland.de [62.146.214.70]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721033319-60266-9 ; Sun, 21 Jul 2002 03:33:20 -0500 Received: from atuin (uucp@localhost) by sklave3.rackland.de (8.12.3/8.12.3/Debian -7) with BSMTP id g6L8O7wl005181 for ftp-wg@hethmon.com; Sun, 21 Jul 2002 10:24:07 +0200 Received: by home.pro-bono-publico.de (Postfix, from userid 1000) id 24A123592A; Sun, 21 Jul 2002 10:22:05 +0200 (CEST) Message-ID: <20020721082205.GA2003@pro-bono-publico.de> References: <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2399.1026963846@munnari.OZ.AU> User-Agent: Mutt/1.4i Date: Sun, 21 Jul 2002 03:33:21 -0500 X-OldDate: Sun, 21 Jul 2002 10:22:05 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Marc Huber To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) On Wed, Jul 17, 2002 at 10:54:03PM -0500, Robert Elz wrote: >| For the data connection, no such escape >| mechanism exists, and transmitting a file name containing >| the sequence as-is in response to MLSD is >| guaranteed to cause trouble. > > This is a different issue entirely, but it is a good point. > Is this a problem that we need to solve? If not, then we > should probably at least make mention of it somewhere. It should be addressed, but I'm not sure about the best solution. Non-shortest UTF-8 is supposed to be illegal, so it might be advisable to adopt parts of the NVT processing for the MLSD data connection: transmit after unless that starts the regular EOL sequence. Marc From ftp-wg-owner@hethmon.com Sun Jul 21 17:09:28 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10572 for ; Sun, 21 Jul 2002 17:09:27 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721161756-26950-10 ; Sun, 21 Jul 2002 16:17:56 -0500 Received: from smtp1.us4.outblaze.com (205-158-62-78.outblaze.com [205.158.62.78]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721161753-56253-9 ; Sun, 21 Jul 2002 16:17:54 -0500 Received: (qmail 14688 invoked from network); 21 Jul 2002 21:08:42 -0000 Received: from unknown (HELO Laptop) (brawler:priest.com?mail.com@206.25.51.1) by 205-158-62-78.outblaze.com with SMTP; 21 Jul 2002 21:08:42 -0000 Message-ID: <000e01c230fa$e4fb8000$013319ce@Laptop> References: <003e01c22eb3$67bf2900$0b0d85cd@vr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Date: Sun, 21 Jul 2002 16:17:54 -0500 X-OldDate: Sun, 21 Jul 2002 14:09:23 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "brawler" To: "FTPEXT Working Group" Subject: Ftp-WG: unsubcribe Content-Transfer-Encoding: 7bit unsubscribe ----- Original Message ----- From: "Gregory A Lundberg" To: "FTPEXT Working Group" Sent: Thursday, July 18, 2002 4:41 PM Subject: Ftp-WG: FEAT UTF-8 in review > > > Clients & servers should also liberally accept LF as > > > Telnet end-of-line, yes? > > > > No. This is not a telnet end of line > > Actually, it could be, but to be one required both ends to have been locally > configured to accept it as such; which the TELNET protocol allows. > Basically, TELNET end-of-line is whatever you want it to be, so long as it > does not conflict with the 96 displayable ASCII characters ( %x20-7E ). > > From ftp-wg-owner@hethmon.com Sun Jul 21 21:14:39 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13090 for ; Sun, 21 Jul 2002 21:14:38 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721202303-24557-10 ; Sun, 21 Jul 2002 20:23:03 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020721202301-63215-9 ; Sun, 21 Jul 2002 20:23:02 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6M1Dod04578 for ; Sun, 21 Jul 2002 21:13:50 -0400 Message-ID: <000601c2311d$0967b7c0$0b0d85cd@vr.net> References: <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> <20020721082205.GA2003@pro-bono-publico.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sun, 21 Jul 2002 20:23:02 -0500 X-OldDate: Sun, 21 Jul 2002 21:13:44 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Marc Huber" To: "FTPEXT Working Group" Sent: Sunday, July 21, 2002 4:33 AM Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) > On Wed, Jul 17, 2002 at 10:54:03PM -0500, Robert Elz wrote: > >| For the data connection, no such escape > >| mechanism exists, and transmitting a file name containing > >| the sequence as-is in response to MLSD is > >| guaranteed to cause trouble. > > > > This is a different issue entirely, but it is a good point. > > Is this a problem that we need to solve? If not, then we > > should probably at least make mention of it somewhere. > > It should be addressed, but I'm not sure about the best > solution. Non-shortest UTF-8 is supposed to be illegal, so > it might be advisable to adopt parts of the NVT processing > for the MLSD data connection: transmit after > unless that starts the regular EOL sequence. The parts of NVT processing you're refering to indicate that is the Telnet End-of-Line. From ftp-wg-owner@hethmon.com Mon Jul 22 01:03:39 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16818 for ; Mon, 22 Jul 2002 01:03:39 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722001209-64658-11 ; Mon, 22 Jul 2002 00:12:09 -0500 Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722001207-42858-10 ; Mon, 22 Jul 2002 00:12:07 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id BAA23006; Mon, 22 Jul 2002 01:02:56 -0400 (EDT) In-Reply-To: Your message of Sun, 21 Jul 2002 20:23:02 -0500 Message-ID: Date: Mon, 22 Jul 2002 00:12:08 -0500 X-OldDate: Mon, 22 Jul 2002 1:02:55 EDT Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jeffrey Altman To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) > > It should be addressed, but I'm not sure about the best > > solution. Non-shortest UTF-8 is supposed to be illegal, so > > it might be advisable to adopt parts of the NVT processing > > for the MLSD data connection: transmit after > > unless that starts the regular EOL sequence. > > The parts of NVT processing you're refering to indicate that is > the Telnet End-of-Line. End of Line is . is simply by itself. The reason for the is to allow for well defined state machines that do not have to wait an arbitrary time period for the next character to arrive. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ftp-wg-owner@hethmon.com Mon Jul 22 05:55:59 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29686 for ; Mon, 22 Jul 2002 05:55:58 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722050422-32453-10 ; Mon, 22 Jul 2002 05:04:22 -0500 Received: from ratree.psu.ac.th (202.28.97.3 [202.28.97.3]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722050419-5315-9 ; Mon, 22 Jul 2002 05:04:21 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6M9skY10691 for ; Mon, 22 Jul 2002 16:54:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6M9sXj07239 for ; Mon, 22 Jul 2002 16:54:41 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <20020721082205.GA2003@pro-bono-publico.de> References: <20020721082205.GA2003@pro-bono-publico.de> <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <7237.1027331673@munnari.OZ.AU> Date: Mon, 22 Jul 2002 05:04:21 -0500 X-OldDate: Mon, 22 Jul 2002 16:54:33 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Date: Sun, 21 Jul 2002 03:33:21 -0500 From: Marc Huber Message-ID: <20020721082205.GA2003@pro-bono-publico.de> | It should be addressed, but I'm not sure about the best solution. Nor I am. | Non-shortest UTF-8 is supposed to be illegal, Yes, though I'm not sure of the relevance here. | so it might be advisable to adopt parts of the NVT processing | for the MLSD data connection: transmit after | unless that starts the regular EOL sequence. That's certainly an option, but it would be a big change to make at this stage of the protocol's design. It would also mean a big change to implementations, which, at least as far as I know, don't currently support anything like this, and while implementations supporting new stuff isn't exactly a major problem (all of MLSx is new after all...) this one would be kind of a dramatic change. An option would be to simply say that names that contain the EOL sequence can't be handled by the protocol at all. There is already no way to send them in NLST or LIST, and while it would be nice for MLSx to be able to cope (and because the control connection is used, MLST can) it isn't as if we'd be giving up all that much by simply saying that those filenames can't be transmitted via MLSD. Opinions? kre ps: it would be nice to get a resolution on this one real soon now, we're in a window where there's actually a possibility of getting this doc finished and out the door within a measurable time frame - I'd hate it to fall back into the "Oh, that one" state that it has been in for the past year or so. From ftp-wg-owner@hethmon.com Mon Jul 22 07:19:57 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01003 for ; Mon, 22 Jul 2002 07:19:56 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722062829-20962-10 ; Mon, 22 Jul 2002 06:28:29 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722062826-10758-9 ; Mon, 22 Jul 2002 06:28:26 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6MBJEd20496 for ; Mon, 22 Jul 2002 07:19:15 -0400 Message-ID: <000401c23171$9cbea340$0b0d85cd@vr.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Mon, 22 Jul 2002 06:28:28 -0500 X-OldDate: Mon, 22 Jul 2002 07:19:09 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Content-Transfer-Encoding: 7bit > End of Line is . *ONE* of the forms of end-of-line is . > is simply by itself. Correct. > The reason for the is to allow for well defined > state machines that do not have to wait an arbitrary > time period for the next character to arrive. Marginally correct. The fact remains, however, that is specifically stated to be *ONE* of the forms of end-of-line in the Telnet specifications. From ftp-wg-owner@hethmon.com Mon Jul 22 07:25:40 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01096 for ; Mon, 22 Jul 2002 07:25:39 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722063413-26928-12 ; Mon, 22 Jul 2002 06:34:13 -0500 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722063409-65529-11 ; Mon, 22 Jul 2002 06:34:11 -0500 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g6MBOnd20917 for ; Mon, 22 Jul 2002 07:24:49 -0400 Message-ID: <000901c23172$640558e0$0b0d85cd@vr.net> References: <20020721082205.GA2003@pro-bono-publico.de> <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> <7237.1027331673@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Mon, 22 Jul 2002 06:34:12 -0500 X-OldDate: Mon, 22 Jul 2002 07:24:43 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Content-Transfer-Encoding: 7bit > An option would be to simply say that names that contain the EOL sequence > can't be handled by the protocol at all. To be correct, the FTP cannot handle any name containing ( %x00-1F / %x7F-FF ). The use of UTF-8 encoding for non-ASCII characters is MARGINALLY workable; the chances of failure are low enough that there seems little reason to worry about it as an implementor, but from a protocol level the current specifications are insufficient to ensure it will work without error. From ftp-wg-owner@hethmon.com Mon Jul 22 08:45:21 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02687 for ; Mon, 22 Jul 2002 08:45:20 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722075345-62925-13 ; Mon, 22 Jul 2002 07:53:45 -0500 Received: from ratree.psu.ac.th (202.28.97.3 [202.28.97.3]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722075342-10100-14 ; Mon, 22 Jul 2002 07:53:43 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6MChOY15565 for ; Mon, 22 Jul 2002 19:43:24 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6MChIj08143 for ; Mon, 22 Jul 2002 19:43:21 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <000901c23172$640558e0$0b0d85cd@vr.net> References: <000901c23172$640558e0$0b0d85cd@vr.net> <20020721082205.GA2003@pro-bono-publico.de> <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> <7237.1027331673@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <8141.1027341798@munnari.OZ.AU> Date: Mon, 22 Jul 2002 07:53:44 -0500 X-OldDate: Mon, 22 Jul 2002 19:43:18 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) Date: Mon, 22 Jul 2002 06:34:12 -0500 From: "Gregory A Lundberg" Message-ID: <000901c23172$640558e0$0b0d85cd@vr.net> | To be correct, the FTP cannot handle any name containing ( %x00-1F / | %x7F-FF ). I can assure you that it can, I have done it. What's more, a whole legion of hackers, or warez types, or whatever, rely upon the ability to stick %x08 in file names via ftp... (well, "rely upon" maybe too strong, "like to use" might be better). | The use of UTF-8 encoding for non-ASCII characters is MARGINALLY workable; | the chances of failure are low enough that there seems little reason to | worry about it as an implementor, but from a protocol level the current | specifications are insufficient to ensure it will work without error. If there's something that needs to be fixed in the specs to make them clear (aside from that which is already clear - like for FTP the control channel, and ascii mode data connection, end of line is CR LF and nothing else at all, regardless of what might be legal sometimes in telnet), then please let us know. Especially in the very near term as they apply to MLSx. kre From ftp-wg-owner@hethmon.com Mon Jul 22 12:44:54 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14385 for ; Mon, 22 Jul 2002 12:44:53 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722115323-13611-10 ; Mon, 22 Jul 2002 11:53:23 -0500 Received: from sklave3.rackland.de (sklave3.rackland.de [62.146.214.70]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020722115321-4912-9 ; Mon, 22 Jul 2002 11:53:21 -0500 Received: from atuin (uucp@localhost) by sklave3.rackland.de (8.12.3/8.12.3/Debian -7) with BSMTP id g6MGi8xY018473 for ftp-wg@hethmon.com; Mon, 22 Jul 2002 18:44:08 +0200 Received: by home.pro-bono-publico.de (Postfix, from userid 1000) id 23BB9359CD; Mon, 22 Jul 2002 18:43:59 +0200 (CEST) Message-ID: <20020722164359.GA2218@pro-bono-publico.de> References: <20020721082205.GA2003@pro-bono-publico.de> <20020717221214-32856-9@mail.hethmon.com> <2399.1026963846@munnari.OZ.AU> <7237.1027331673@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7237.1027331673@munnari.OZ.AU> User-Agent: Mutt/1.4i Date: Mon, 22 Jul 2002 11:53:22 -0500 X-OldDate: Mon, 22 Jul 2002 18:43:59 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Marc Huber To: FTPEXT Working Group Subject: Ftp-WG: Proposed changes to MLST -15 (will be -16) On Mon, Jul 22, 2002 at 05:04:21AM -0500, Robert Elz wrote: > An option would be to simply say that names that contain the EOL sequence > can't be handled by the protocol at all. > > There is already no way to send them in NLST or LIST, and while it would > be nice for MLSx to be able to cope (and because the control connection is > used, MLST can) it isn't as if we'd be giving up all that much by > simply saying that those filenames can't be transmitted via MLSD. Agreed. If it turns out to be a problem, we could possibly come up with something similar to C: FEAT S: 221-Extensions supported: ... ENCODING ASCII*;BASE64;URL; ... S: 221 End. C: OPTS ENCODING URL S: 200 File names will now be URL encoded. Marc From ftp-wg-owner@hethmon.com Wed Jul 24 18:50:30 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04780 for ; Wed, 24 Jul 2002 18:50:30 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020724175900-18931-10 ; Wed, 24 Jul 2002 17:59:00 -0500 Received: from mergenthaler (vodsl-182.vo.lu [80.90.32.182]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020724175858-59223-9 ; Wed, 24 Jul 2002 17:58:58 -0500 Received: from bembo ([192.168.42.201]) by mergenthaler (VisNetic.MailServer.v5.0.1) with SMTP id MCTVEO for ; Thu, 25 Jul 2002 00:53:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Wed, 24 Jul 2002 17:58:59 -0500 X-OldDate: Thu, 25 Jul 2002 00:53:14 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "David Somers" To: Subject: Ftp-WG: I-D: MFxx command extensions Content-Transfer-Encoding: 7bit Hi, I put together an I-D detailing some possible commands that would complement the MLSx ones (in draft-ietf-ftpext-mlst). The abstract is: This document defines extensions to the FTP specification STD9, RFC959, "FILE TRANSFER PROTOCOL (FTP)". These extensions provide the ability for a FTP Client to modify the last modification time, the creation time, or multiple facts (last modification time, creation time, operating system permissions, etc.) of a file in the server-FTP process NVFS. These extensions are implemented by three new optional commands: "MFMT" (Modify File Modification Time), "MFCT" (Modify File Creation Time), and "MFF" (Modify File Facts). Available from: http://www.ietf.org/internet-drafts/draft-somers-ftp-mfxx-00.txt All comments appreciated. Regards, David Somers From ftp-wg-owner@hethmon.com Fri Jul 26 15:24:51 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05201 for ; Fri, 26 Jul 2002 15:24:50 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020726143327-20910-10 ; Fri, 26 Jul 2002 14:33:27 -0500 Received: from sklave3.rackland.de (sklave3.rackland.de [62.146.214.70]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020726143325-56239-9 ; Fri, 26 Jul 2002 14:33:25 -0500 Received: from atuin (uucp@localhost) by sklave3.rackland.de (8.12.3/8.12.3/Debian -7) with BSMTP id g6QJO942001192 for ftp-wg@hethmon.com; Fri, 26 Jul 2002 21:24:09 +0200 Received: by home.pro-bono-publico.de (Postfix, from userid 1000) id B63AA35F79; Fri, 26 Jul 2002 21:21:40 +0200 (CEST) Message-ID: <20020726192140.GA21327@pro-bono-publico.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Date: Fri, 26 Jul 2002 14:33:26 -0500 X-OldDate: Fri, 26 Jul 2002 21:21:40 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Marc Huber To: FTPEXT Working Group Subject: Ftp-WG: Re: I-D: MFxx command extensions The draft looks fine, IMHO. Just two minor issues: - For consistency with draft-ietf-ftpext-mlst, the facts "ModifyTime" and "CreateTime" should be renamed to "Modify" and "Create". - The UNIX.perm value used in the examples should start with a leading "0" to indicate that the value is an octal number. Marc From ftp-wg-owner@hethmon.com Mon Jul 29 18:13:55 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16661 for ; Mon, 29 Jul 2002 18:13:54 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020729172224-60229-10 ; Mon, 29 Jul 2002 17:22:24 -0500 Received: from web21110.mail.yahoo.com (web21110.mail.yahoo.com [216.136.227.112]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020729172221-35072-9 ; Mon, 29 Jul 2002 17:22:22 -0500 Message-ID: <20020729221307.69871.qmail@web21110.mail.yahoo.com> Received: from [147.178.2.110] by web21110.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 15:13:06 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 2002 17:22:22 -0500 X-OldDate: Mon, 29 Jul 2002 15:13:06 -0700 (PDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Pat LaVarre To: ftp-wg@hethmon.com Subject: Ftp-WG: mlst-16 will correctly say *( %x20-7E )? Despite time & study, I'm not sure I'm correctly understanding the English posted here 17-22 July ... so I'll post these guesses, and hope for correction? > From: Gregory A Lundberg [lundberg@vr.net] > you cannot send ( %x00-1F / %x7F ) on ANY FTP > command or reply and expect correct interoperation. Yes. > http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt > ... > The ABNF for pathnames presented in [RFC2640] is > incorrect. When UTF-8 encoding is not present, > the correct syntax is PATHNAME = *( %x20-7E )... Yes, except where we say "when UTF-8 encoding is not present" we mean to say "unless some other syntax has been negotiated", whether that be by OPTS UTF-8 NLST of the draft FEAT UTF-8 or the OPTS ENCODING URL of Marc Huber or whatever. > From: Robert Elz [kre@munnari.OZ.AU] > I'd hate it to fall back into the "Oh, that one" > state that it has been in for the past year or so. Our intent is to close out the MLST effort __without__ taking the time to teach MLST to handle the path names over which NLST LIST etc. choke. > http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt > pathname = utf-8-name / raw Accordingly we can hope to see this error corrected before the final draft. Here when we say utf-8-name's we mean only those which do not contain ( %x00-1F / %x7F ). Or maybe we mean only those which do not contain ( %x00-1F / %x7F / %x80-FF), formerly known as locally printable Ascii names. > > From: Pat LaVarre [p.lavarre@ieee.org] > > As a server, in a folder, I have a local > > filename that includes a local Eol. > > > > How should that filename appear in my NLST data, > > supposing the client asked for FEAT UTF-8 NLST? ... > From: Gregory A Lundberg [lundberg@vr.net] ... > It cannot appear on ANY FTP command or response. > Sorry. Aye, not yet, ouch. Pat LaVarre __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From ftp-wg-owner@hethmon.com Tue Jul 30 02:42:59 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06513 for ; Tue, 30 Jul 2002 02:42:58 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730015138-28061-10 ; Tue, 30 Jul 2002 01:51:38 -0500 Received: from ratree.psu.ac.th (202.28.97.2 [202.28.97.2]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730015133-1347-9 ; Tue, 30 Jul 2002 01:51:37 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6U6ftv13865 for ; Tue, 30 Jul 2002 13:41:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6U6fMc26391 for ; Tue, 30 Jul 2002 13:41:33 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 In-Reply-To: <20020729221307.69871.qmail@web21110.mail.yahoo.com> References: <20020729221307.69871.qmail@web21110.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <26389.1028011282@munnari.OZ.AU> Date: Tue, 30 Jul 2002 01:51:37 -0500 X-OldDate: Tue, 30 Jul 2002 13:41:22 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: mlst-16 will correctly say *( %x20-7E )? Date: Mon, 29 Jul 2002 17:22:22 -0500 From: Pat LaVarre Message-ID: <20020729221307.69871.qmail@web21110.mail.yahoo.com> | Our intent is to close out the MLST effort __without__ | taking the time to teach MLST to handle the path names | over which NLST LIST etc. choke. Something like that ... extending the scope of path names isn't really what this draft was intended to be about - there was another draft (now an RFC) whose purpose was that, this draft just intended to make use of that one. | http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt | > pathname = utf-8-name / raw | | Accordingly we can hope to see this error corrected | before the final draft. I doubt it, it isn't an error. There is one particular set of characters that we can't transfer in a path name (CRLF) but that's it. All the rest are OK. The "utf-8-name / raw" is intended to convey the interpretation that (almost) any sequence of bytes is legal (that's "raw") while suggesting that if those bytes happen to be utf-8 that is much better. | Here when we say utf-8-name's we mean only those which | do not contain ( %x00-1F / %x7F ). Or maybe we mean | only those which do not contain ( %x00-1F / %x7F / | %x80-FF), formerly known as locally printable Ascii | names. No, we don't mean anything of the kind. Note: what is being specified here is what the protocol can transfer. That is only just peripherally related to the set of names that any particular client and server will allow. The protocol allows the name \0\0\0 (and treats it differently from \0\0 and \0\0\0\0) and all of that works just fine. It also allows xxxCRxxx and xxxLFxxx and xxxCRxLFxxx as well. And lots more. Whether any of those make sense to any particular implementation is up to the implementation. About all that is required is that the names the server presents in its directory listings (and for us, particularly, in MLSx) can be sent received back again in those commands that take a file name arg. I'm currently working out just where and how to say that CRLF isn't handled (suggestions welcome) - as soon as that is done, a new version of the draft will be submitted for WG review, and then hopefully it will finally get sent for IETF last call (or perhaps approved, if the IETF last call was already held - it has been so long that I forget, certainly there have been no changes of substance in years...) kre From ftp-wg-owner@hethmon.com Tue Jul 30 14:46:34 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04275 for ; Tue, 30 Jul 2002 14:46:33 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730135512-60172-10 ; Tue, 30 Jul 2002 13:55:12 -0500 Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730135507-22806-9 ; Tue, 30 Jul 2002 13:55:07 -0500 Message-ID: <20020730184551.6448.qmail@web21103.mail.yahoo.com> Received: from [147.178.2.110] by web21103.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 11:45:51 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 2002 13:55:10 -0500 X-OldDate: Tue, 30 Jul 2002 11:45:51 -0700 (PDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Pat LaVarre To: ftp-wg@hethmon.com Subject: Ftp-WG: mlst-16 will correctly say *( %x20-7E )? Robert E: I'm not trying to be difficult, but I must be completely missing something ... > From: Robert Elz [mailto:kre@munnari.OZ.AU] > ... I'm currently working out just where and how > to say that CRLF isn't handled (suggestions welcome) How about we disavow and override the rfc2640 ABNF for PATHNAME, as in the utf-8 draft? > ... names ... > Whether any of those make sense > to any particular implementation > is up to the implementation. Eh? I'm not sure I understand this. It's not ok for a client or server to offer the other a name it can't handle, is it? How can the client or server decide what the other can handle, except by assuming that PATHNAME = *( %x20-7E ) until told otherwise? > There is one particular set of characters > that we can't transfer in a path name (CRLF) but > that's it. All the rest are OK. So we agree rfc2640 is incorrect here? Our next question then is how incorrect. Me, I thought, in practice, NUL in a path name was as problematic as CR or LF. And SP used to be bad. But if we say "All the rest are OK", then I must conclude: > From: Gregory A Lundberg [lundberg@vr.net] > you cannot send ( %x00-1F / %x7F ) > on ANY FTP command or reply and expect correct > interoperation. Robert E disputes this? Gregory L stands by it? > http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt > ... > The ABNF for pathnames presented in [RFC2640] > is incorrect ... the correct syntax is > PATHNAME = *( %x20-7E )... Robert E also disputes this? > Note: what is being specified here is > what the protocol can transfer. > ... The protocol allows the name \0\0\0 > (and treats it differently from \0\0 and \0\0\0\0) Yes. > and all of that works just fine. Not in real life. > That is only just peripherally related > to the set of names > that any particular client and server will allow. I think I see we're discussing three sets of names. 1) In theory, the protocol can transfer a large set of names. 2) The set of names actual implementations can transfer is considerably smaller, and awkward to measure automagically, because of how creatively implementations fail when assaulted with unusual names. 3) After we agree what name was transferred, then we can ask if the file system of the client or server can give that name to a folder or a file, and if the file system can distinguish that name from another. I think I hear Robert E saying the Ftp Rfc's should define only (1) and Gregory L saying the Ftp Rfc's should define a (1) similar to (2). How irretrievably confused am I? Curiously yours, Pat LaVarre __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From ftp-wg-owner@hethmon.com Tue Jul 30 17:36:22 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10008 for ; Tue, 30 Jul 2002 17:36:21 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730164504-18510-10 ; Tue, 30 Jul 2002 16:45:04 -0500 Received: from stat.com (stat.com [207.211.1.10]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020730164502-51371-9 ; Tue, 30 Jul 2002 16:45:02 -0500 Message-Id: <20020730164502-51371-9@mail.hethmon.com> Received: from iname.com [211.183.77.59] by stat.com (SMTPD32-7.07) id A6AC4736028C; Tue, 30 Jul 2002 14:35:40 -0700 X-RBL-Warning: SPAMCOP: Blocked - see http://spamcop.net/bl.shtml?211.183.77.59 X-RBL-Warning: MONKEYPROXIES: IP address [211.183.77.59] BLOCKED: See http://www.monkeys.com/anti-spam/filtering/proxies.html X-RBL-Warning: BADHEADERS: This E-mail was sent from a broken mail client [84200009]. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 211.183.77.59 with no reverse DNS entry. X-RBL-Warning: WEIGHT10: Weight of 28 reaches or exceeds the limit of 10. Date: Tue, 30 Jul 2002 16:45:03 -0500 X-OldDate: Tue, 30 Jul 2002 14:35:48 -0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group Subject: Ftp-WG: From: "Brady" Subject: Sometimes, not always, I like the idea of a chick... with a horse... Content-Type: text/html; charset="iso-8859-1"

VERY GRAPHIC MATERIAL - MATURE AUDIENCE ONLY!

You MUST be at least 18 years old to enter!



This email was sent to you because your email address is part of a targeted opt-in list.You have received this
email by either requesting more information on one of our sites or someone may have used your email address.
If you received this email in error, please accept our apologies.
If you do not wish to receive further offers, please click below and enter your email to remove your email from future offers.

Click Here to Remove

Anti-SPAM Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail cannot be considered spam
as long as we include contact information and a remove link for removal from this mailing list. If this e-mail is unsolicited, please
accept our apologies. Per the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000, further transmissions
to you by the sender may be stopped at NO COST to you!

Message-Id: <200207301435955.SM00398@iname.com >