From ftp-wg-owner@hethmon.com Thu Apr 4 07:02:41 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 HAA10804 for ; Thu, 4 Apr 2002 07:02:40 -0500 (EST) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020404070913-59991-9 ; Thu, 04 Apr 2002 07:09:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020404070908-40950-8 ; Thu, 04 Apr 2002 07:09:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10389; Thu, 4 Apr 2002 07:00:45 -0500 (EST) Message-Id: <200204041200.HAA10389@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Thu, 4 Apr 2002 07:09:11 -0500 X-OldDate: Thu, 04 Apr 2002 07:00:44 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: Ftp-WG: I-D ACTION:draft-ietf-ftpext-mlst-15.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions to FTP Working Group of the IETF. Title : Extensions to FTP Author(s) : R. Elz, P. Hethmon Filename : draft-ietf-ftpext-mlst-15.txt Pages : 59 Date : 02-Apr-02 This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ftpext-mlst-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ftpext-mlst-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020402125229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ftpext-mlst-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ftpext-mlst-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020402125229.I-D@ietf.org> --OtherAccess-- --NextPart-- From ftp-wg-owner@hethmon.com Mon Apr 8 22:27:12 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 WAA14678 for ; Mon, 8 Apr 2002 22:27:11 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020408213343-49908-9 ; Mon, 08 Apr 2002 21:33:43 -0500 Received: from warp.hethmon.com (warp.hethmon.com [208.171.56.198]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020408213339-32186-8 ; Mon, 08 Apr 2002 21:33:39 -0500 Message-Id: <20020408213339-32186-8@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: Mon, 8 Apr 2002 21:33:41 -0500 X-OldDate: Mon, 08 Apr 2002 22:25:59 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Paul Hethmon" To: "ftp-wg@hethmon.com" Subject: Ftp-WG: Fwd: to mlst-15 from mlst-14 Content-Transfer-Encoding: 7bit ==================BEGIN FORWARDED MESSAGE================== >Return-Path: Steward@hethmon.com >Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com > (Hethmon Smtpd Perseus) id 20020408180705-12780-8 ; Mon, 08 Apr 2002 18:07:05 -0500 >Message-Id: <20020408180705-12780-8@mail.hethmon.com> >Date: Mon, 8 Apr 2002 18:07:05 -0500 >Sender: Steward-owner >From: Steward >Reply-To: ftp-wg@hethmon.com >Subject: Approval Request for ftp-wg >To: phethmon@hethmon.com > ----- Steward Marker Line -- Do Not Modify ------- Original-From: "Pat LaVarre" Original-To: Original-Subject: to mlst-15 from mlst-14 ----- Steward Marker Line -- Do Not Modify ------- Remember in January we here reviewed how we got to mlst-14 from mlst-13? = Here now ... > - ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-14.txt.Z > - [50360 bytes] > -Expiration Date: July 2002 > - January = 2002 ... > + ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-15.txt.Z > + [52106 bytes] > +Expiration Date: October 2002 > + April = 2002 The substantive diff's I see to April mlst-15 from January mlst-14 are = as follows ... > 2.1. Basic Tokens ... > + SCHAR =3D RCHAR / "=3D" ; ... > ALPHA, in particular, is case sensitive. > That implies that a "token" is a case sensitive > value. > - That implication is correct. > + That implication is correct, except where explicitly stated > + to the contrary in this document, or in some other specification > + which defines the values this document specifies be used in a > + particular context. > 2.2. Pathnames ... > Implementations are advised against converting a UTF-8 pathname > - to a local encoding, and > - then attempting to invert the encoding later. > + to a local charset that > + isn't capable of representing the full Unicode character = repertoire, > + and then attempting to invert the charset translation later. > 7.1. Format of MLSx Requests ... > If no argument is given then MLSD must return a listing of the > contents of the current working directory, and MLST must return a > listing giving information about the current working directory > itself. > For these purposes, the contents of a directory are whatever > - file names (not pathnames) > + file or directory 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. > 7.2. Format of MLSx Response ... > - value =3D *RCHAR > + value =3D *SCHAR ... > 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. > + See section 7.9 (page 51). > 7.5.1. The type Fact > + The value of the type fact (the "type-val") is a case independent > + string. > Acknowledgments > + Bill Fenner (and the rest of the IESG) The less substantive diff's includes fuller and more perfectly = consistent examples: > 7.7.9. Example from another server ... > Finally notice that the NVFS supported > by this server, in contract to the earlier ones, implements its > pathnames in a case independent manner. > + The server seems to return > + files using the case in which they were requested, when the name = was > + sent by the client, and otherwise uses an algorithm known only to > + itself to select the case of the names it returns. > +7.7.11. A server with a difference > + > +C> ... S> ... D> ... > + > + The server shown here returns its directory listings in seemingly > + random order, and even seems to modify the order of the directory = as > + its contents change -- perhaps the underlying directory structure = is > + based upon hashing of some kind. Note that the "pdir" and "cdir" > + entries are interspersed with other entries in the directory. = Note > + also that this server does not show a "pdir" entry when listing = the > + contents of the root directory of the virtual filestore, it does > + however include multiple "cdir" and "pdir" entries when it fees > + inclined. The server also uses obnoxiously "cute" messages. > 3.4. MDTM Examples ... > - If we assume the existence of three files, A B and C, > - and a directory D, and no other files at all, > - then the MDTM command may behave as indicated. > + If we assume the existence of three files, A B and C, > + a directory D, two files with names that end with the string > + "ile6", and no other files at all, > + then the MDTM command may behave as indicated. ... > - C was modified 21 days and several hours later. > + C was modified 20 days and several hours later. > 7.5.1.5. System defined types > - os-type =3D "OS." os-name "=3D" os-type > - os-type =3D token > + os-type =3D "OS." os-name "=3D" os-kind > + os-kind =3D token > OS specific types are registered by the IANA > - using the procedures specified in section 10. The "os-type" = provides > - the system dependent information as to the type of the file = listed. > - The os-name and os-type strings in an os-type are case = independent. > + using the procedures specified in section 10. The "os-kind" = provides > + the system dependent information as to the type of the file = listed. > + The os-name and os-kind strings in an os-type are case = independent. > 7.8.1. Examples > - All of the facts supported by > - this server are enabled by default. > + All but one of the facts > + supported by this server are enabled by default. The "to me not clearly substantive" diff's include: > - directory has a file name relative to the directory that contains = it, > + directory has a name relative to the directory that contains it, > - storage structure, > + storage structure. =20 > - The VCHAR (from [5]), TCHAR, and RCHAR types > + The VCHAR (from [5]), RCHAR, SCHAR, and TCHAR types > - is returned over the control connection,) > + is returned over the control connection) Also I see we're again swapping "modelled" with "modeled" and "labelled" = with "labeled". As in January, before comparing the texts, ... gleefully I stripped page numbers, headers, trailers and I compressed runs of blank lines to = single blank lines. And this time I also ended by ignoring all whitespace in = the comparison. x4402 Pat LaVarre p.lavarre@ieee.org http://members.aol.com/plscsi/ ===================END FORWARDED MESSAGE=================== Paul Hethmon phethmon@hethmon.com http://www.hethmon.com From ftp-wg-owner@hethmon.com Wed Apr 24 15:23:20 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 PAA04265 for ; Wed, 24 Apr 2002 15:23:16 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424142949-18363-9 ; Wed, 24 Apr 2002 14:29:49 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424142944-56082-5 ; Wed, 24 Apr 2002 14:29:46 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3OJK7D18628 for ; Wed, 24 Apr 2002 15:20:07 -0400 Message-ID: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> References: <20020408213339-32186-8@mail.hethmon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C1EBA3.80C9F400" 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: Wed, 24 Apr 2002 14:29:47 -0500 X-OldDate: Wed, 24 Apr 2002 15:20:01 -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: Re: comments on the MLST draft This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1EBA3.80C9F400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Preface: To be honest, the MLST draft as it stands is as good (read: bad) as any other FTP RFC. I've been spending a lot of time recently thinking about the entire FTP, and what I've attached is a mixure of my notes to myself on implementing the FTP applied to the MLST draft, and some specific issues which I happened across when reading/thinking about other issues. That said, turn on "he's being a crumudeon" mode and peruse the attached ... ------=_NextPart_000_000C_01C1EBA3.80C9F400 Content-Type: text/plain; name="mlst.txt" Content-Disposition: attachment; filename="mlst.txt" Content-Transfer-Encoding: quoted-printable Comments on the MLST Draft:=0A= =0A= 1. Introduction=0A= =0A= Second paragraph SHOULD read:=0A= =0A= These commands allow a client to obtain directory listings in a=0A= machine-friendly, predictable format; and MAY allow a client to=0A= restart an interrupted transfer in transfer modes not previously=0A= supported in any documented manner."=0A= =0A= 2.2 Pathnames=0A= =0A= In the third paragraph, discussing encoding of pathnames, it may be=0A= informative to explicitly state that the CR character MUST NOT=0A= appear in pathnames but that, when using UTF-8, a CR MAY be sub-=0A= optimally encoded using a two (or more) byte UTF-8 representation=0A= instead of the normal one-byte encoding. Sub-optimal encoding=0A= SHOULD NOT be used except to represent the CR character as a data=0A= character rather than a line-termination character.=0A= =0A= The fourth paragraph should read:=0A= =0A= Implementations should also be aware that the control connection=0A= uses a subset of the Telnet NVT conventions. The Telnet IAC=0A= character, if part of a pathname sent over the control connection,=0A= MUST be correctly escaped as defined by the Telnet protocol prior=0A= to transmission and after conversion from to the transport=0A= representation from the host's internal representation.=0A= =0A= 2.2.1 Pathname syntax.=0A= =0A= Last sentence should read:=0A= =0A= The server-FTP implementation SHOULD NOT restrict the syntax of=0A= valid file and directory names unless failure to do so would=0A= violate the contraints placed upon file and directory names by the=0A= host system.=0A= =0A= 2.3 Times=0A= =0A= It may be informative to explicitly state that the reason for the UTC=0A= requirement is to make it possible for a user to compare time stamps=0A= across servers. The user SHOULD be aware that servers MAY not have=0A= synchronized clocks and some may use GMT or one of the other time=0A= standards. Thus, appropriate use of the time stamps produced by=0A= different hosts would be relative order, not absolute marks, with=0A= differences of less than a few hours being considered equality. It=0A= might also be a good idea to explicitly caution against reliance upon=0A= time stamps; not only are clocks often not synchonized, they are=0A= often set by hand (if set at all) and may be wildly incorrect.=0A= =0A= 3.1 (MDTM) Syntax=0A= =0A= This command is OPTIONAL.=0A= =0A= Server-FTP implementors are cautioned to carefully consider the=0A= implications of supporting MDTM command. The existance of certain=0A= files MAY be used by attackers to "fingerprint" host systems. In=0A= particular, where the existance of certain non-retrievable files is=0A= to be hidden from the user, the MDTM command SHOULD be implemented=0A= in such a manner that its reply does not inadvertently disclose the=0A= existance of a file. Thus, the choice of response for non-=0A= retrievable files SHOULD be governed by the server-FTP's response=0A= elicited if the RETR were attempted using the same pathname argument.=0A= =0A= 3.3 FEAT response for MDTM=0A= =0A= The user-FTP SHOULD NOT rely upon support of the FEAT command, or=0A= the response to the FEAT command, to indicate support of the MDTM=0A= command. While the inclusion of MDTM in the FEAT response is=0A= positive indication of support for the command, its absence MUST NOT=0A= be taken as indicating lack of support.=0A= =0A= User-FTP implementations desiring to use the MDTM command SHOULD=0A= issue the command and SHOULD interpret a 500 or 502 reply as=0A= indicating lack of support for the command.=0A= =0A= 3.4 MDTM Examples=0A= =0A= User-FTP implementors are cautioned that some existing server-FTP=0A= implementations MAY misinterpret the pathname "19990929043300 File6"=0A= as a command to change the modification time of "File6".=0A= =0A= For maximum inter-operation, the user-FTP SHOULD use other means to=0A= determine the existance of the pathname prior to attempting the MDTM=0A= command.=0A= =0A= 4. File SIZE=0A= =0A= This command is OPTIONAL.=0A= =0A= Server-FTP implementors are cautioned to carefully consider the=0A= implications of supporting the SIZE command. The requirement is=0A= that the value returned be precise, when coupled with the current=0A= data transfer options, can consume significant resource. To arrive=0A= at a precise value for the SIZE response, the server-FTP=0A= implementation MAY need to process the entire file as if it were=0A= being transmitted, but without the delays involved with transmission.=0A= An attacker could use the SIZE command to reduce or exhaust=0A= resources, potentially reducing the host's ability to deliver file=0A= transfer or other services offered by the host.=0A= =0A= 4.2 (SIZE) Error responses=0A= =0A= When the current parameters would require conversion or modification=0A= of the file during the data transfer process, the SIZE command=0A= SHOULD return a 550 reply. Thus, a positive completion reply to the=0A= SIZE command indicates both the precise size of the file, and that=0A= the data transfer process for the file involves no conversion or=0A= modification operations on the server-FTP.=0A= =0A= 4.3 FEAT response for SIZE=0A= =0A= The user-FTP SHOULD NOT rely upon support of the FEAT command, or=0A= the response to the FEAT command, to indicate support of the SIZE=0A= command. While the inclusion of SIZE in the FEAT response is=0A= positive indication of support for the command, its absence MUST NOT=0A= be taken as indicating lack of support.=0A= =0A= User-FTP implementations desiring to use the SIZE command SHOULD=0A= issue the command and SHOULD interpret a 500 or 502 reply as=0A= indicating lack of support for the command.=0A= =0A= 4.4 Size examples=0A= =0A= In the example give, the correct response to the second (TYPE A)=0A= example should read:=0A= S> 550 Size can not be determined.=0A= =0A= 5.1 Restarting in STREAM mode.=0A= =0A= First paragraph, last sentence should read:=0A= =0A= However, there MAY not really be a need to have explicit restart=0A= markers in this case, since restart markers MAY by implied by the=0A= octet offset into the data stream.=0A= =0A= Second paragraph, second sentence should read:=0A= =0A= Thus, given the same transfer options, an octet offset SHOULD=0A= always represent the same position within a given file.=0A= =0A= Implementors are cautioned to remember that, at the time the REST=0A= command is interpreted, the specific file and direction of transfer=0A= are unknown.=0A= =0A= Server-FTP implementors are cautioned to consider the implications of=0A= supporting the REST command for stream mode transfers. When=0A= positioning to the desired octet offset, significant resources can=0A= be consumed when the current transfer options would require the=0A= server-FTP to perform conversion or modification on the data stream.=0A= An attacker could the REST command to cause resource depletion on=0A= the host, potentially reducing the host's ability to deliver file=0A= transfer, or other, services.=0A= =0A= The server-FTP MUST ensure that the REST command does not, itself,=0A= imlicity extend the size of the file, or allow access to areas of=0A= the file system allocated to, but not actually used by, the file.=0A= When the octet offset given with the REST command would indicate a=0A= position outside the current range of possible values (i.e., less=0A= than zero or greater than the file's size), the server-FTP MUST=0A= reply 550. On some hosts, specifying a file position past the end=0A= of file implicitly extends the file (possibly filling the new area=0A= with uninitialized data). This could be used by an attacker to=0A= exhaust file system resources. In addition, should the file=0A= subsequently be retrieved, the uninitialized areas of the file could=0A= contain potentially sensitive information which would otherwise not=0A= be available via file transfer.=0A= =0A= For TYPE I, the acceptable range of values for the octet offset is=0A= (0 <=3D REST <=3D SIZE); where SIZE is the size of the file. If the=0A= restart marker is positioned at (or, if allowed, past) SIZE, a=0A= subsequent RETR transfer SHOULD transfer no data, immediately=0A= indicating end-of-file. If the restart marker is allowed to be=0A= positioned past SIZE, a subsequent STOR transfer SHOULD fail; if the=0A= restart marker is positioned at SIZE, a subsequent STOR transfer=0A= SHOULD append to the file (as if REST had not been issued and the=0A= APPE command had been used instead).=0A= =0A= 5.2 Error Recovery and Restart=0A= =0A= Second paragraph should read:=0A= =0A= When using TYPE IMAGE, the SIZE command returns the number of=0A= octets that would actually be transmitted if the file were=0A= transferred. When using TYPE ASCII, or other options involving=0A= conversion or modification of the file, the SIZE command MAY fail=0A= to return this information.=0A= =0A= 5.3 (REST) Syntax=0A= =0A= Support for restart in stream mode is RECOMMENDED.=0A= =0A= Explicitly state the offset zero is the first octet of the file.=0A= =0A= The existing [RFC959] requirement for REST is that the next command=0A= be a transfer command. Many existing server-FTP implementations=0A= ignore this, and many existing user-FTP implementations depend upon=0A= it being ignored. The following additional specification are needed:=0A= =0A= The restart marker MUST be reset to zero following any data=0A= transfer (successful or otherwise). The ABOR and REIN commands=0A= MUST discard any restart marker, resetting it to zero.=0A= =0A= The SIZE command MUST ignore the restart marker and leave it=0A= unchanged.=0A= =0A= The REST command MAY occur at any time; it SHOULD, however, be=0A= followed by a RETR or STOR command. The server-FTP MAY require=0A= that the following a REST command with a non-zero argument to be=0A= RETR or STOR by issuing a 350 reply; in which case, if the user-=0A= FTP does not intend to issue a RETR or STOR, it MUST issue either=0A= an ABOR command, or a REST 0 command, before proceeding with the=0A= session.=0A= =0A= The server-FTP SHOULD interpret the REST command with a zero=0A= argument as a resetting the restart marker, and SHOULD NOT issue a=0A= 350 reply in this case.=0A= =0A= If the restart marker has been set to a non-zero value, the=0A= following commands SHOULD return negative completion replies:=0A= LIST, MLST, NLST and STOU.=0A= =0A= The APPE MAY ignore the restart marker. This command implicitly=0A= sets the restart marker to the end-of-file position prior to the=0A= transfer. When the APPI command does not ignore the restart=0A= marked, it SHOULD return a negative completion reply when the=0A= restart marker is non-zero and is not to the SIZE offset.=0A= =0A= Following a STOR (or APPE or STOU), the file SHOULD be truncated=0A= at the point the data transfer stream just completed indicated=0A= end-of-file. For example, the effect of a STOR REST STOR=0A= sequence SHOULD be the same as if the entire file had transferred=0A= with a single STOR command.=0A= =0A= User-FTP implementors are cautioned ensure the user is well aware=0A= that, although stream mode restart is supported, the results actually=0A= obtained MAY differ from those which would occur if restart were not=0A= used. While the MDTM, SIZE and MLSx commands MAY be used to indicate=0A= when restarting a stream transfer will produce differing results,=0A= they can not be reliably used to indicate the sequences would produce=0A= identical results. For this reason, the user-FTP implementation=0A= SHOULD NOT automatically attempt a restart following an interrupted=0A= transfer, but MAY offer it as a option to the well-informed user.=0A= =0A= The server-FTP implementor is cautioned to carefully consider the=0A= implications of allowing restart, especially in stream mode. Many=0A= "download accelerators" exploit some TCP features and attempt to=0A= explicitly break up transfers by use of multiple sessions, the REST=0A= command, and other features of the FTP. Such applications MAY=0A= consume excessive host and network resources which MAY adversely=0A= effect file transfer and other services offered by the host.=0A= =0A= 5.4 FEAT response for REST=0A= =0A= The user-FTP SHOULD rely upon support of the FEAT command, and=0A= the response to the FEAT command, to indicate the REST command is=0A= supported for stream transfers.=0A= =0A= While the inclusion of REST STREAM in the FEAT response is positive=0A= indication of support for the feature, the user-FTP MAY (might) not=0A= interpret its absense as indicating lack of support. The server-FTP=0A= MAY support existing user-FTP implementations attempting to use REST=0A= during stream transfers.=0A= =0A= A commonly used scheme in an attempt to determine support of REST for=0A= stream mode transfers is, while in stream mode, to issue the REST=0A= command with a small value. Many existing server-FTP implementations=0A= will properly respond, some however will not.=0A= =0A= 6.1 TVFS File Names=0A= =0A= Sub-optimal UTF-8 encoding of the "/" character SHOULD be taken to=0A= mean a file name character, and SHOULD NOT be interpreted as a path=0A= name component separator.=0A= =0A= 7.2 Format of MLSx Response=0A= =0A= The assumption that the user-FTP desires a new data connection for=0A= the MLSD command is inconsistent with the philosophy of the FTP.=0A= The sixth paragraph should read:=0A= =0A= The data transfer for the MLSD response MUST be as if the "TYPE L=0A= 8" and "STRU F" commands had been given without regard to whether=0A= the type and structure were actually specified as such by the=0A= user-FTP, and without altering those settings for subsequent=0A= transfers. While the content of the data sent can be considered=0A= as a series of lines, implementations should note that there is=0A= no maximum line length specified. Implementations SHOULD be=0A= prepared to deal with arbitrarily long lines. Implementations,=0A= however, SHOULD NOT simply truncate long lines; rather they=0A= SHOULD parse for and select those facts they require from the=0A= lines, and handle length limitations on a fact-by-fact basis.=0A= =0A= 7.5 Standard Facts=0A= =0A= The model used for the LIST, NLST, SIZE, MDTM and MLSx commands is=0A= that of a static file archive the user desires to interact with, but=0A= where changes (if they occur at all) are infrequent. As dynamics of=0A= the underlying file system increase, the accuracy and usefullness of=0A= these commands decreases.=0A= =0A= External processes can change the fact-set for a given name at any=0A= time. The implementation SHOULD be aware that a given fact-set for=0A= a given name represents a snapshot taken at the time of generation of=0A= the MLSx response. The implementation SHOULD NOT presume the fact-=0A= set implies the true state of the facts at the time of any=0A= subsequent command; in particular, the implementation SHOULD NOT=0A= presume a subsequent MLSx command would return the same fact-set for=0A= the name. Furthermore, the implementation MUST NOT assume the fact-=0A= set remains unchanged from one FTP session to another, even when=0A= those sessions may be proceeding in parallel or may appear to be=0A= communicating with the same host.=0A= =0A= 7.5.2 The unique Fact=0A= =0A= The implementation SHOULD be aware that the intention of the unique=0A= fact is to allow a means of correlating different names for the same=0A= underlying representation. The implementation SHOULD NOT presume=0A= the unique fact will remain unchanged from one response to a MLSx=0A= command to another; furthermore, the implementation MUST NOT presume=0A= the unique fact remains unchanged from one FTP session to another,=0A= even when those sessions may be proceeding in parallel or may appear=0A= to be communicating with the same host.=0A= =0A= The implemenation SHOULD be aware that the unique fact cannot be=0A= reliably used to correlate two given names. It MAY indicate the=0A= some relationship (or lack thereof) between the underlying=0A= representation for two names. External processes MAY, however,=0A= change the underlying representation between the generation of the=0A= fact-set for one name and that for another (even within the same MLSx=0A= response), rendering incorrect any relationship inferred from the=0A= unique facts for the two names.=0A= =0A= 11. Security Considerations=0A= =0A= The first paragraph should be corrected to read:=0A= =0A= This memo does not directly concern security. While the=0A= mechanisms presented here MAY impact security concerns for hosts=0A= and networks, they are not believed to present new security=0A= concerns not already present in deployed FTP implementations.=0A= =0A= The second paragraph should be corrected to read:=0A= =0A= Implementing the SIZE command, the REST command, and some of the=0A= facts of the NLSx commands MAY impose consume considerable host=0A= or network resources which MAY lead to denial-of-service attacks.=0A= Servers have implemented these many of these features for years=0A= and, while no wide-spread incidents have been reported, there=0A= have been several sporatic reports of denial-of-service problems=0A= which can be attributed to these features (most having to do with=0A= the abuse of the REST command, although there have been reports=0A= of problems with the SIZE command which would indicate similar=0A= problems will occur with similar features the MLDx commands). The=0A= problems reported generally relate to the unspecified behavior of=0A= these features; several of the problems have been addressed by=0A= the specifications presented here and the remainder MAY be=0A= addressed through careful implementation and configuration=0A= choices.=0A= =0A= Add the following sentence to the end of the third paragraph:=0A= =0A= The specific selection of features and options available prior to=0A= authentication, however, MAY expose information which MAY be used=0A= to "fingerprint" a given implementation or the underlying host=0A= which MAY be of use to a potential attacker.=0A= =0A= ------=_NextPart_000_000C_01C1EBA3.80C9F400-- From ftp-wg-owner@hethmon.com Wed Apr 24 17:02:24 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 RAA07630 for ; Wed, 24 Apr 2002 17:02:23 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424160904-58640-9 ; Wed, 24 Apr 2002 16:09:04 0000 Received: from web21104.mail.yahoo.com (web21104.mail.yahoo.com [216.136.227.106]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424160902-34194-5 ; Wed, 24 Apr 2002 16:09:02 0000 Message-ID: <20020424210032.27055.qmail@web21104.mail.yahoo.com> Received: from [147.178.1.2] by web21104.mail.yahoo.com via HTTP; Wed, 24 Apr 2002 14:00:32 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Apr 2002 16:09:03 -0500 X-OldDate: Wed, 24 Apr 2002 14:00:32 -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 draft - NUL CR LF again [ BC lundberg@vr.net ] > From: Gregory A Lundberg [mailto:lundberg@vr.net] > Sent: Wed 4/24/2002 1:29 PM > Attached: mlst.txt (17,657 bytes) > ... crumudeon ... Thank you, I enjoyed all I read ... but could you (or anyone) explain in more detail how you reached the conclusions you did re the proper treatment of the bytes x 00 .. 1F appearing in pathnames, in particular the bytes x 00 0D 0A NUL CR LF? I thought not-shortest form UTF-8 was broadly accepted as an evil to be discouraged? Particularly evil are implementations that pick and choose when to use not-shortest form? My own personal history of pain includes how differently the de facto standards for Java .class files define the treatment of shortest-form UTF-8. The de jure standard there flatly forbids not-shortest form except for 0, which is required to appear in the minimal not-shortest form x C0 80. > QuotingFrom: > ... mlst.txt (17,657 bytes) 2.2 Pathnames In the third paragraph, discussing encoding of pathnames, it may be informative to explicitly state that the CR character MUST NOT appear in pathnames but that, when using UTF-8, a CR MAY be sub-optimally encoded using a two (or more) byte UTF-8 representation instead of the normal one-byte encoding. Sub-optimal encoding SHOULD NOT be used except to represent the CR character as a data character rather than a line-termination character. The fourth paragraph should read: Implementations should also be aware that the control connection uses a subset of the Telnet NVT conventions. The Telnet IAC character, if part of a pathname sent over the control connection, MUST be correctly escaped as defined by the Telnet protocol prior to transmission and after conversion from to the transport representation from the host's internal representation. > Quoting from: > http://www.unicode.org/versions/corrigendum1.html Corrigendum #1: UTF-8 Shortest Form The conformance clause C12 in The Unicode Standard, Version 3.0 forbids the generation of "non-shortest form" UTF-8, and forbids the interpretation of illegal sequences, but not the interpretation of "non-shortest form". Where software does interpret the non-shortest forms, security issues can arise. For example: Process A performs security checks, but does not check for non-shortest forms. Process B accepts the byte sequence from process A, and transforms it into UTF-16 while interpreting non-shortest forms. The UTF-16 text may then contain characters that should have been filtered out by process A. To address this issue, the Unicode Technical Committee has modified the definition of UTF-8 to forbid conformant implementations from interpreting non-shortest forms for BMP characters, and clarified some of the conformance clauses. > ParaphrasingFrom past Ftp reflector traffic ... I think I understand that we're hoping for shortest-form UTF-8 for Unicode x0020..xFFFF to just plain work in pathnames. I'm not at all clear on what we mean to say about the bytes x00..1F that include the x 0D 0A CR LF that appear in pathnames created by best of breed Gui's such as the classic MacOS. Yours in breathtaking, hopefully refreshing, ignorance, Pat LaVarre -----Original Message----- From: Gregory A Lundberg [mailto:lundberg@vr.net] Sent: Wed 4/24/2002 1:29 PM To: FTPEXT Working Group Cc: Subject: Ftp-WG: Re: comments on the MLST draft Preface: To be honest, the MLST draft as it stands is as good (read: bad) as any other FTP RFC. I've been spending a lot of time recently thinking about the entire FTP, and what I've attached is a mixure of my notes to myself on implementing the FTP applied to the MLST draft, and some specific issues which I happened across when reading/thinking about other issues. That said, turn on "he's being a crumudeon" mode and peruse the attached ... __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From ftp-wg-owner@hethmon.com Wed Apr 24 17:22:17 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 RAA09721 for ; Wed, 24 Apr 2002 17:22:16 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424162856-14463-10 ; Wed, 24 Apr 2002 16:28:56 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424162854-56717-9 ; Wed, 24 Apr 2002 16:28:55 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3OLJOD28406; Wed, 24 Apr 2002 17:19:25 -0400 Message-ID: <004601c1ebd5$b5d3c2c0$0b0d85cd@vr.net> References: <20020424210032.27055.qmail@web21104.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: Wed, 24 Apr 2002 16:28:55 -0500 X-OldDate: Wed, 24 Apr 2002 17:19:17 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: , Subject: Ftp-WG: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit > I thought not-shortest form UTF-8 was broadly accepted > as an evil to be discouraged? It is. But there is no other way to unambiguously separate Telnet end-of-line (CR LF and CR NUL) from data characters with the same encoding. It just bugs me that we can support any file, directory or path name EXCEPT those which include the Telnet EOL. > Where software does interpret the non-shortest > forms, security issues can arise. An FTP conforming implementation SHOULD NOT transmit non-shortest form UTF-8, but it MUST properly interpret it. That was already spelled out in both 959 and 1123 long before UTF-8 came along. > To address this issue, the Unicode Technical Committee > has modified the definition of UTF-8 to forbid > conformant implementations from interpreting > non-shortest forms for BMP characters, and clarified > some of the conformance clauses. Since they did not specify alternate encodings for legacy character sets, there will be times their mandate MUST be ignored. This is a SHOULD NOT requirement and we have a case where their requirement can not be applied; unless they provided some OTHER form of representation for the CR LF and NUL characters elsewhere in the character sets. > I'm not at all clear on what we mean to say about the > bytes x00..1F that include the x 0D 0A CR LF that > appear in pathnames created by best of breed Gui's > such as the classic MacOS. It is specifically those instances which are why I'm loath to have to turn around and clearly state that a file, directory or pathname MUST NOT include UTF-8 encodings 0x00 through 0x20. From ftp-wg-owner@hethmon.com Wed Apr 24 17:58:07 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 RAA10180 for ; Wed, 24 Apr 2002 17:58:00 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424170443-59610-9 ; Wed, 24 Apr 2002 17:04:43 0000 Received: from web21108.mail.yahoo.com (web21108.mail.yahoo.com [216.136.227.110]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424170441-29913-5 ; Wed, 24 Apr 2002 17:04:41 0000 Message-ID: <20020424215612.64453.qmail@web21108.mail.yahoo.com> Received: from [147.178.1.2] by web21108.mail.yahoo.com via HTTP; Wed, 24 Apr 2002 14:56:12 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Apr 2002 17:04:42 -0500 X-OldDate: Wed, 24 Apr 2002 14:56:12 -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: Re: MLST draft - NUL CR LF again [BC lundberg@vr.net] > From: Gregory A Lundberg [lundberg@vr.net] > Sent: Wed 4/24/2002 3:28 PM > It just bugs me > that we can support any file, directory > or path name EXCEPT those > which include the Telnet EOL. Bugs me too. > > > http://www.ietf.org/rfc/rfc854.txt ... > > I thought not-shortest form UTF-8 > > ... an evil to be discouraged? ... > It is. But there is no other way > to unambiguously separate Telnet end-of-line > (CR LF and CR NUL) from data characters > with the same encoding. Sorry, too fast for me. I thought Telnet by design Can exchange lines of completely arbitrary content and length? Yes CR LF ends a line. To send a line with CR inside, to escape the CR, send CR NUL instead. Always on receipt of CR NUL, substitute CR. This is unambiguous on paper ... no? For example, we could send the six byte command "STOR \r" as the nine bytes "STOR \r\0\r\n" to create a file named by the one byte string containing only x0D CR. Somehow in real life Telnet is less robust? You're saying in some sense CR NUL is also a Telnet Eol? And I've seen actual implementations accept NUL and LF as Eol? Somehow it is not properly rfc761 conservative to let real live human people type the three traditional platform-specific end-of-line encodings (LF, CR, and CR LF) in their path names? Maybe we're trying to say Eol in an Ftp path name is x0A LF only, and systems will vary over whether they will report more than one file as having precisely this same path name? Thanks again in advance, Pat LaVarre -----Original Message----- From: Gregory A Lundberg [mailto:lundberg@vr.net] Sent: Wed 4/24/2002 3:28 PM To: p.lavarre@ieee.org; ftp-wg@hethmon.com Cc: Subject: Ftp-WG: Re: MLST draft - NUL CR LF again > I thought not-shortest form UTF-8 was broadly > accepted as an evil to be discouraged? It is. But there is no other way to unambiguously separate Telnet end-of-line (CR LF and CR NUL) from data characters with the same encoding. It just bugs me that we can support any file, directory or path name EXCEPT those which include the Telnet EOL. > Where software does interpret the non-shortest > forms, security issues can arise. An FTP conforming implementation SHOULD NOT transmit non-shortest form UTF-8, but it MUST properly interpret it. That was already spelled out in both 959 and 1123 long before UTF-8 came along. > To address this issue, the Unicode Technical > Committee has modified the definition of UTF-8 to > forbid conformant implementations from interpreting > non-shortest forms for BMP characters, and clarified > some of the conformance clauses. Since they did not specify alternate encodings for legacy character sets, there will be times their mandate MUST be ignored. This is a SHOULD NOT requirement and we have a case where their requirement can not be applied; unless they provided some OTHER form of representation for the CR LF and NUL characters elsewhere in the character sets. > I'm not at all clear on what we mean to say about > the bytes x00..1F that include the x 0D 0A CR LF > that appear in pathnames created by best of breed > Gui's such as the classic MacOS. It is specifically those instances which are why I'm loath to have to turn around and clearly state that a file, directory or pathname MUST NOT include UTF-8 encodings 0x00 through 0x20. ... __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From ftp-wg-owner@hethmon.com Wed Apr 24 18:05: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 SAA10271 for ; Wed, 24 Apr 2002 18:05:27 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424171211-15424-14 ; Wed, 24 Apr 2002 17:12:11 0000 Received: from ACFcluster.NYU.EDU (AXP2.NS.ITS.NYU.EDU [128.122.253.164]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424171209-52528-5 ; Wed, 24 Apr 2002 17:12:09 0000 Received: from ACFcluster.NYU.EDU by ACFcluster.NYU.EDU (PMDF V5.2-33 #41099) id <01KGY6EHM5A80000HY@ACFcluster.NYU.EDU> for ftp-wg@hethmon.com; Wed, 24 Apr 2002 18:03:36 EDT In-reply-to: "Your message dated Wed, 24 Apr 2002 14:29:47 -0500" <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> Message-id: <01KGY8OZ73QS0000HY@ACFcluster.NYU.EDU> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <20020408213339-32186-8@mail.hethmon.com> Date: Wed, 24 Apr 2002 17:12:10 -0500 X-OldDate: Wed, 24 Apr 2002 18:03:34 -0400 (EDT) Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Stephen Tihor To: FTPEXT Working Group Subject: Ftp-WG: Re: comments on the MLST draft bravo From ftp-wg-owner@hethmon.com Wed Apr 24 23:27: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 XAA16701 for ; Wed, 24 Apr 2002 23:27:48 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424223434-61053-9 ; Wed, 24 Apr 2002 22:34:34 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020424223432-57510-5 ; Wed, 24 Apr 2002 22:34:32 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3P3P1D24497; Wed, 24 Apr 2002 23:25:02 -0400 Message-ID: <008301c1ec08$c9694f20$0b0d85cd@vr.net> References: <20020424215612.64453.qmail@web21108.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: Wed, 24 Apr 2002 22:34:33 -0500 X-OldDate: Wed, 24 Apr 2002 23:24:56 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: , Subject: Ftp-WG: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit > I thought Telnet by design Can exchange lines of > completely arbitrary content and length? Yes CR LF > ends a line. To send a line with CR inside, to escape > the CR, send CR NUL instead. Always on receipt of CR > NUL, substitute CR. > > This is unambiguous on paper ... no? > > For example, we could send the six byte command "STOR > \r" as the nine bytes "STOR \r\0\r\n" to create a file > named by the one byte string containing only x0D CR. RFC 1123 *REQUIRES* the TELNET implementation to accept CR NUL as equivalent to CR LF. The the proper intepretation of your example is: STOR And a conforming server SHOULD issue the replies 501 Syntax error in parameters or arguments 500 Syntax error, unrecognizable command in response to the sequence. From ftp-wg-owner@hethmon.com Thu Apr 25 01:26: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 BAA18406 for ; Thu, 25 Apr 2002 01:26:50 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425003330-10639-10 ; Thu, 25 Apr 2002 00:33:30 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425003328-48911-9 ; Thu, 25 Apr 2002 00:33:29 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA13399; Thu, 25 Apr 2002 15:24:58 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <008301c1ec08$c9694f20$0b0d85cd@vr.net> References: <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <8976.1019712297@mundamutti.cs.mu.OZ.AU> Date: Thu, 25 Apr 2002 00:33:29 -0500 X-OldDate: Thu, 25 Apr 2002 15:24:57 +1000 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: Re: MLST draft - NUL CR LF again Date: Wed, 24 Apr 2002 22:34:33 -0500 From: "Gregory A Lundberg" Message-ID: <008301c1ec08$c9694f20$0b0d85cd@vr.net> | RFC 1123 *REQUIRES* the TELNET implementation to accept CR NUL as equivalent | to CR LF. You are misinterpreting 1123, that would make no sense at all. What 1123 is trying to say (perhaps not as well in this instance as it does in most others), is that the telnet server must treat a received CR over the telnet connection the same as it treats a CR from a local keyboard. That is, if CR ends a command, then CR over a telnet connection ends a command - as does end of line. So sending CR NULL or CR LF should be treated the same way - but that applies only if CR is normally treated as an "end of line" at the telnet server. Note, the wording ... On server hosts that use ASCII, in particular, receipt of the Telnet sequence CR LF must cause the same effect as a local user pressing the CR key on a local terminal. That is a reference to ... For terminal input, this corresponds to a command- terminal; on an ASCII terminal, this is the CR key, but it may also be labelled "Return" or "Enter". That is, the "ASCII terminal" or host, being assumed, is one where CR means "end of line". Note this isn't true of unix hosts, on unix, CR is just another character (the fact that the keyboard driver takes the button labelled "CR" (or similar) and generates from it the character that is the end of line indicator is irrelevant - that can easily be turned off if you want to investigate what really happens). For FTP none of this is relevant. CR by itself is never an end of line terminator. Ever. (Buggy implementations ignored). If you want to put a CR in a file name, you so it exactly as Pat LaVarre suggested. If you happen to be talking to a broken implementation, then you might not be able to put a CR in a file name - the answer is to fix the implementation, not to change the way FTP is defined. And it is irrelevant how common such broken implementations might be (creating some new method to encode CR isn't going to work on any existing implementation anyway - it is just as easy, if not easier, to simply fix the bug as it is to support something new). I will look at the rest of the comments later, but I rather suspect (or perhaps even hope) that they're really too late now for this draft. kre From ftp-wg-owner@hethmon.com Thu Apr 25 02:13:13 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 CAA27383 for ; Thu, 25 Apr 2002 02:13:12 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425011954-21615-9 ; Thu, 25 Apr 2002 01:19:54 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425011948-60314-5 ; Thu, 25 Apr 2002 01:19:52 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3P6AKD05454; Thu, 25 Apr 2002 02:10:20 -0400 Message-ID: <009301c1ec1f$e11251a0$0b0d85cd@vr.net> References: <20020424215612.64453.qmail@web21108.mail.yahoo.com> <008301c1ec08$c9694f20$0b0d85cd@vr.net> 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, 25 Apr 2002 01:19:52 -0500 X-OldDate: Thu, 25 Apr 2002 02:10:12 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit At issue are the following rules governing the existing FTP specification: The server-FTP MUST indicate end-of-line using the sequence CR LF. [per RFC 1123] The user-FTP SHOULD indicate end-of-line using the sequence CR LF, but it MAY use the alternate sequence CR NUL or the character LF; and it SHOULD provide the user the ability to chose the form to use for a given session. [per RFC 1123] The CR character MUST NOT be appear except as the first character in one of the two-character sequences CR LF and CR NUL. [per RFC 854]. The FTP SHOULD NOT place constraints upon file, directory or path names unless failing to do so would violate a constraint of underlying host system. [implied, but unstated, in RFC 959, RFC 2640 and the MLST Draft] The characters CR and LF MUST NOT appear in file, directory or path names. [per RFC 1123] And the following observations: The constraint against CR and LF in file, directory or path names violates the fourth rule given above, and is well-known to cause inter-operation problems with the FTP on some host systems. The TVFS constrains the use of "/" in file and directory names, in violation of the fourth rule given above, and could cause inter- operation problems. The number of hosts with contraints upon the NUL character is sufficiently diverse that this character may warrant special attention in the FTP specifications. The problems to be addressed are How to remove the constraint against CR and LF in file, directory and path names; moving the problem from the FTP and its implementation to the host system, where it more properly belongs. How to eliminate the constraint against "/" in file and directory names; moving the problem from the FTP and its implementation to the host system, where it more properly belongs. Whether, and how, to advertize or negotiate a host system's constraint against NUL, CR, LF, "/", or any other character, when used in a file, directory or path name. Let's take the easiest problem first. The FTP already provides a means to advertize a host's contraints against certain characters in file, directory and path names: the 553 response code. We need only clearly state the rules: In response to any command taking a argument (such as STOR, RETR and STAT), the server-FTP MUST issue a 553 reply if the argument contains characters violating a host contraint. The server-FTP SHOULD provide a configurable means to constrain the use of certain characters or patterns; but MUST NOT allow configurations which would violate a constraint imposed by the underlying host system. For example, on a host which uses the NUL character to terminate file name parameters, the server-FTP MUST NOT allow its configuration to create a condition where the it would attempt to violate the constraint against using NUL in a file name. The free-form text of the 553 reply SHOULD clearly indicate the source of the contraint (host, implementation or configuration) and, if possible, the specific character(s) or pattern(s) violating the constraint. Examples, on a host which constrains the use of NUL (represented as ) and has been configured to constrain the use of hyphen (-) as the first character: C> RETR Embedded.Data S> 553 Host constraints prevent NUL in a pathname C> STOR -exec rm -fR . S> 553 Configuration constraints prevent that pathname It MAY be beneficial for the FTP to provide a FEAT response which indicates the current set of constrained characters or patterns, but this does not appear to be required, since it would not enhance inter- operation. Now, to the real problems: we must devise some means to escape the character codes CR and LF when the user-FTP intends them to be treated as "normal" characters (i.e., as part of a file, directory or path name), as opposed to "control" characters indicating end-of-line. The character NUL is not at issue here. It can be transmitted without special consideration; parsing it to the point of issuing a 553 response code (if required) is a solvable implementation issue. The solution chosen for CR and LF should be applicable to "/" as well, when using TVFS and "/" is intended as a "normal" character in a file or directory name as opposed to a path name component separator. We've already identified two cases where special consideration should be given to specific characters. In systems analysis, there are generally only three numbers of import: 0, 1 and infinity. By that I mean something (in this case, a protocol-level constraint) does not occur, it occurs exactly once or not at all, or it can occur many, many times. Applying that principal here, the solution chosen for CR, LF and "/" should be applicable to any character a future FTP specification might need to constrain, so that a mechanism already exists to bypass the protocol's constraint. Possible solutions are: 1) Ignore the issue. This implies problems with inter-operation will occur when an implementation attempts to send CR or LF as "normal" characters. In this case, the FTP would appear to operate normally in all other respects, yet at times the protocol would fail. This way lies CHAOS. Without a specification, implementations will choose whatever means suits them, inter-operation problems grow, and user discontent rises. 2) Specifically state that, while all other characters which may be represented by UTF-8 (or the 7-bit ASCII subset of UTF-8, for older implementations) MAY appear in a file, directory or path name, the characters CR and LF MUST NOT be appear, and the "/" character must not appear in a TVFS path name. In this case, we intentionally create problems with inter-operation where the host supports CR and/or LF in file, directory or path names, or allow "/" in file or directory names. The FTP would appear to operate normally in all other respects, yet at times the user-FTP would refuse to perform certain operations because to do so would require violating the constraint against CR and LF. This is the choice taken by RFC 1123, with respect to the 7-bit ASCII character set (and prior to the advent of UTF-8); and presently taken in the MLST Draft with respect to "/". While we may not envision any future specifications placing protocol- level constraints upon characters in file and directory names, the existance of the MLST Draft proves that such cases may arise. Taken to a ridiculous limit, it is POSSIBLE to specify enough such cases that NO character is left un-constrained. This practice MUST cease. 3) Choose some means to "escape" the CR or LF. To inter-operate properly, the chosen means MUST: a) have the value 128 or greater, to avoid conflict with any value 7- bit ASCII representation, and b) not create a conflict with any valid UTF-8 encoding. One such value which comes to mind is the TELNET IAC command lead-in code. We COULD specify that IAC be used to escape protocol- constrained characters. In fact, the TELNET protocol has already specified exactly that. Unfortunately, the TELNET protocol HAS already specified exactly that. Since the FTP MAY use an external TELNET implementation, should we chose the IAC code, if we have an FTP-level protocol constraint concerning the IAC code, we would escape it as IAC IAC; passing that through the external TELNET would mean the sequence actually transmitted is IAC IAC IAC IAC. I'm sorry, but THAT is just disgusting. Besides, it makes life much harder for implementors; when they see IAC will it be a TELNET IAC escape code or an FTP IAC escape code. Considering the chances of misundertanding and misinterpetation, let's just not go there. That leaves us with the "holes" in the UTF-8 encoding scheme. So which hole do we pick? My suggestion is to state the escaped character code SHOULD be encoded using the next-larger non-shortest (what I call sub-optimal) UTF-8 encoding. The implementation SHOULD accept any non-shortest encoding to represent the escaped character, but SHOULD only transmit the shortest of the non-shortest encodings. (Muhaha! Now, do you see why I call it sub-optimal? .. the shortest of the sub-optimal encodings .. it just reads better.) The advantage of this suggestion is that the UTF-8 schemes presented in RFC 2640 handle the case with only minor modification; and, as has already been pointed out, sub-optimal encodings MUST be supported on the receiving side; but SHOULD NOT be transmitted. All we're doing is "borrowing" some of the holes created by the UTF-8 governing body, using them for our purposes, and .. oh yeah .. we JUST HAPPEN to be putting codes in those places which look an awful lot like their un-encoded, "normal" (yet constrained) representations. They made the road .. they don't have any right to complain if we actually find a use for their potholes! From ftp-wg-owner@hethmon.com Thu Apr 25 02:20: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 CAA27537 for ; Thu, 25 Apr 2002 02:20:10 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425012657-24665-11 ; Thu, 25 Apr 2002 01:26:57 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425012655-64040-10 ; Thu, 25 Apr 2002 01:26:56 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3P6HRD05892 for ; Thu, 25 Apr 2002 02:17:27 -0400 Message-ID: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> References: <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.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: Thu, 25 Apr 2002 01:26:56 -0500 X-OldDate: Thu, 25 Apr 2002 02:17:22 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit Back at ya .. The FTP specification states that the control connection operates using normal Telnet clients. A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line. We don't know which, so we must be prepared for all. Now, if you want to DROP the requirement that FTP work with a normal Telnet client, that's fine. But, if you do, expect inter-operation problems with existing implementations. From ftp-wg-owner@hethmon.com Thu Apr 25 02:47:41 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 CAA27846 for ; Thu, 25 Apr 2002 02:47:40 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425015424-16817-10 ; Thu, 25 Apr 2002 01:54:24 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425015422-55089-9 ; Thu, 25 Apr 2002 01:54:22 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA10233; Thu, 25 Apr 2002 16:45:50 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> References: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <9447.1019717149@mundamutti.cs.mu.OZ.AU> Date: Thu, 25 Apr 2002 01:54:23 -0500 X-OldDate: Thu, 25 Apr 2002 16:45:49 +1000 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: Re: MLST draft - NUL CR LF again Date: Thu, 25 Apr 2002 01:26:56 -0500 From: "Gregory A Lundberg" Message-ID: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> | The FTP specification states that the control connection operates using | normal Telnet clients. yes. | A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line. If it is working correctly, it sends CRLF - nothing else is a telnet end of line. A telnet client on the other hand needs to be able to (somehow) generate all 3 (1123 does say that) in case the user wants to send them - but neither CR NUL nor LF are end of line in telnet. | We don't know which, so we must be prepared for all. not in FTP we don't. The telnet client sends CRLF or it isn't sending end of line. A telnet server needs to treat both CRLF and whatever sequence would be its normal direct connect end of line marker (which might be CR (transmitted as CR NUL) or LF, or conceivably ETX or something) as "end of command" and pass that to the command interpreter (with CRLF replaced by whatever is the appropriate local end of command indicator). But FTP servers aren't telnet servers, and they don't pass commands to command interpreters, and so don't have to deal with that. | Now, if you want to DROP the requirement that FTP work with a normal Telnet | client, that's fine. But, if you do, expect inter-operation problems with | existing implementations. No, I don't want to drop that at all. FTP servers should work fine with any correct telnet client. A telnet client that sends anything other than CRLF when it receives the local user's "end of line" indicator is horribly broken though, we don't need to support those. kre From ftp-wg-owner@hethmon.com Thu Apr 25 08:04: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 IAA02046 for ; Thu, 25 Apr 2002 08:04:13 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425071052-31261-10 ; Thu, 25 Apr 2002 07:10:52 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425071050-4478-9 ; Thu, 25 Apr 2002 07:10:50 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3PC1LD00118 for ; Thu, 25 Apr 2002 08:01:21 -0400 Message-ID: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> References: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.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: Thu, 25 Apr 2002 07:10:51 -0500 X-OldDate: Thu, 25 Apr 2002 08:01:15 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit OK. Obviously we're reading different versions of RFC 1123. I got mine from rfc-editor.org and here's what is says on page 21: 3.3.1 Telnet End-of-Line Convention The Telnet protocol defines the sequence CR LF to mean "end- of-line". For terminal input, this corresponds to a command- completion or "end-of-line" key being pressed on a user terminal; on an ASCII terminal, this is the CR key, but it may also be labelled "Return" or "Enter". When a Server Telnet receives the Telnet end-of-line sequence CR LF as input from a remote terminal, the effect MUST be the same as if the user had pressed the "end-of-line" key on a local terminal. On server hosts that use ASCII, in particular, receipt of the Telnet sequence CR LF must cause the same effect as a local user pressing the CR key on a local terminal. Thus, CR LF and CR NUL MUST have the same effect on an ASCII server host when received as input over a Telnet connection. A User Telnet MUST be able to send any of the forms: CR LF, CR NUL, and LF. A User Telnet on an ASCII host SHOULD have a user-controllable mode to send either CR LF or CR NUL when the user presses the "end-of-line" key, and CR LF SHOULD be the default. The Telnet end-of-line sequence CR LF MUST be used to send Telnet data that is not terminal-to-computer (e.g., for Server Telnet sending output, or the Telnet protocol incorporated another application protocol). Nowhere in there does it make ANY requirement that end-of-line may only be represented by CR LF. The closest I see is the first sentance of the first paragraph, which tells us that CR LF is one possible representation for end-of- line. To arrive at the requirement you infer, the sentance would have been worded as `The Telnet protocol defines "end-of-line" as being the sequence CR LF.' The second paragraph goes on to inform us that, when received via a Telnet connection, the sequences CR LF and CR NUL are interchangable. The third tells us that when sent over a Telnet connection from a user-FTP (the only user-Telnet in the FTP), either CR LF or CR NUL can be sent for the end-of-line, the choice is up to the user, and the default is CR LF. The fourth tells us that when sent over a Telnet connection from a server-FTP, only CR LF may be sent. In RFC 2119 terms: FTP implementations MUST interpret CR LF as marking the end- of-line. [First paragraph, explicitly.] FTP implementations MAY interpret sequences other than CR LF as marking the end-of-line. [First paragraph, by conversion.] FTP implementations MUST interpret CR LF and CR NUL interchangably. [Second paragraph, explicitly.] FTP implementations MUST therefore interpret CR NUL as marking the end-of-line. [Second paragraph, by deduction.] The user-FTP, when implemented as a user-Telnet, MUST offer a configuration option allowing transmission of CR NUL to mark the end-of-line. The default for this option MUST be to transmit CR LF to mark the end-of-line. [Third paragraph, explicitly.] The user-FTP, when not implemented as a user-Telnet, MAY offer a configuration option allowing transmission CR NUL to mark the end-of-line. The default for this option MUST be to transmit CR LF to mark the end-of-line. [Third paragraph, by conversion.] The user-FTP, when not implemented as a user-Telnet and which does not offer a configuration option allowing transmission of CR NUL to mark the end-of-line, MUST transmit CR LF to mark the end-of-line. [Third paragraph, also by conversion.] The server-FTP MUST transmit the sequence CR LF to mark the end- of-line. [Fourth paragraph, explicitly.] While the server-FTP MAY interpret sequences other than CR LF and CR NUL to mark the end-of-line, the user-FTP cannot send any others. So, in answer to the points raised so far about my comments on the MLST draft: 1) You are incorrect. CR NUL quite definitely MUST be interpreted as the Telnet end-of-line. Therefore we have no alternate form for the "bare" CR to be used in a file, directory or path name. 2) You are correct, LF is not to be interpreted as the Telnet end- of line and does not require special escaping when intended as a character in a file, directory or path name. From ftp-wg-owner@hethmon.com Thu Apr 25 08:37: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 IAA03502 for ; Thu, 25 Apr 2002 08:37:54 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425074439-27890-11 ; Thu, 25 Apr 2002 07:44:39 0000 Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425074438-64033-9 ; Thu, 25 Apr 2002 07:44:38 0000 Received: from chirho.texis.com (adsl-65-67-61-15.dsl.austtx.swbell.net [65.67.61.15]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3PCa7R188568 for ; Thu, 25 Apr 2002 08:36:08 -0400 Message-Id: <4.3.2.7.2.20020425073030.01ddebd0@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> References: <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 25 Apr 2002 07:44:38 -0500 X-OldDate: Thu, 25 Apr 2002 07:39: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: MLST draft - NUL CR LF again At 01:26 AM 4/25/2002, Gregory A Lundberg wrote: >Back at ya .. > >The FTP specification states that the control connection operates using >normal Telnet clients. > >A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line. > >We don't know which, so we must be prepared for all. RFC 959 also specifically states: The argument field consists of a variable length character string ending with the character sequence (Carriage Return, Line Feed) for NVT-ASCII representation; for other negotiated languages a different end of line character might be used. It should be noted that the server is to take no action until the end of line code is received. In the absence of any other negotiated language (and, per RFC 1123, the client MUST NOT negotiate a different language), this seems to be specific in that is required, not or . >Now, if you want to DROP the requirement that FTP work with a normal Telnet >client, that's fine. But, if you do, expect inter-operation problems with >existing implementations. I'm trying hard to find that requirement in the RFCs. RFC 959 specifies in several places that the control connection follows the Telnet protocol, but it (and RFC 1123) further defines several places where behaviour is different. Where there is such a contradiction, it would seem that the obvious conclusion is that RFC 959, and the FTP sections of RFC 1123, win out over Telnet. Perhaps this deserves being stated somewhere, but I don't think this is ambiguous. 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 Thu Apr 25 09:00:24 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 JAA04334 for ; Thu, 25 Apr 2002 09:00:24 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425080706-55956-13 ; Thu, 25 Apr 2002 08:07:06 0000 Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425080704-42178-12 ; Thu, 25 Apr 2002 08:07:04 0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA11620; Thu, 25 Apr 2002 08:58:34 -0400 (EDT) In-Reply-To: Your message of Thu, 25 Apr 2002 01:26:56 -0500 Message-ID: Date: Thu, 25 Apr 2002 08:07:05 -0500 X-OldDate: Thu, 25 Apr 2002 8:58:34 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: Re: MLST draft - NUL CR LF again This has nothing to do with client side TELNET protocol. The reason that some so called clients end commands with CR CR-LF LF FF EM is because different operating systems use different end of line indicators. Therefore, when used with TELNET protocol these appear on the wire as CR-NUL CR-LF LF FF EM but are to be convered back to the original form before processing on the server. All TELNET servers will convert CR-NUL to CR. Quoting from RFC 854 "TELNET Protocol": The sequence "CR LF", as defined, will cause the NVT to be positioned at the left margin of the next print line (as would, for example, the sequence "LF CR"). However, many systems and terminals do not treat CR and LF independently, and will have to go to some effort to simulate their effect. (For example, some terminals do not have a CR independent of the LF, but on such terminals it may be possible to simulate a CR by backspacing.) Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. This rule gives assurance to systems which must decide whether to perform a "new line" function or a multiple-backspace that the TELNET stream contains a character following a CR that will allow a rational decision. Note that "CR LF" or "CR NUL" is required in both directions (in the default ASCII mode), to preserve the symmetry of the NVT model. Even though it may be known in some situations (e.g., with remote echo and suppress go ahead options in effect) that characters are not being sent to an actual printer, nonetheless, for the sake of consistency, the protocol requires that a NUL be inserted following a CR not followed by a LF in the data stream. The converse of this is that a NUL received in the data stream after a CR (in the absence of options negotiations which explicitly specify otherwise) should be stripped out prior to applying the NVT to local character set mapping. > Back at ya .. > > The FTP specification states that the control connection operates using > normal Telnet clients. > > A normal Telnet client sends CR LF, or CR NUL, or LF, at the end-of-line. > > We don't know which, so we must be prepared for all. > > Now, if you want to DROP the requirement that FTP work with a normal Telnet > client, that's fine. But, if you do, expect inter-operation problems with > existing implementations. > > > Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ftp-wg-owner@hethmon.com Thu Apr 25 09:00: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 JAA04336 for ; Thu, 25 Apr 2002 09:00:24 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425080650-57005-9 ; Thu, 25 Apr 2002 08:06:50 0000 Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425080648-59629-8 ; Thu, 25 Apr 2002 08:06:48 0000 Received: from chirho.texis.com (adsl-65-67-61-15.dsl.austtx.swbell.net [65.67.61.15]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3PCwJR52366 for ; Thu, 25 Apr 2002 08:58:19 -0400 Message-Id: <4.3.2.7.2.20020425075601.01d9ae50@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> References: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 25 Apr 2002 08:06:49 -0500 X-OldDate: Thu, 25 Apr 2002 08:02:10 -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: MLST draft - NUL CR LF again At 07:10 AM 4/25/2002, Gregory A Lundberg wrote: >OK. Obviously we're reading different versions of RFC 1123. >I got mine from rfc-editor.org and here's what is says on page 21: ... > The Telnet end-of-line sequence CR LF MUST be used to send > Telnet data that is not terminal-to-computer (e.g., for Server > Telnet sending output, or the Telnet protocol incorporated > another application protocol). > >Nowhere in there does it make ANY requirement that end-of-line may >only be represented by CR LF. ... >The fourth tells us that when sent over a Telnet connection from a >server-FTP, only CR LF may be sent. ... > The server-FTP MUST transmit the sequence CR LF to mark the end- > of-line. [Fourth paragraph, explicitly.] That's not how I read the fourth paragraph of RFC 1123, section 3.3.1. I read it as saying that when "the Telnet protocol is incorporated in another protocol", as we have here, "the Telnet end-of-line sequence CR LF MUST be used". 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 Thu Apr 25 09:06: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 JAA04535 for ; Thu, 25 Apr 2002 09:06:07 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425081252-22835-17 ; Thu, 25 Apr 2002 08:12:52 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425081250-8428-17 ; Thu, 25 Apr 2002 08:12:50 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA18763; Thu, 25 Apr 2002 23:04:18 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> References: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <11653.1019739858@mundamutti.cs.mu.OZ.AU> Date: Thu, 25 Apr 2002 08:12:51 -0500 X-OldDate: Thu, 25 Apr 2002 23:04:18 +1000 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: Re: MLST draft - NUL CR LF again Date: Thu, 25 Apr 2002 07:10:51 -0500 From: "Gregory A Lundberg" Message-ID: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> | OK. Obviously we're reading different versions of RFC 1123. No, same thing, just interpreting it differently... | The closest I see is the first sentance of the first paragraph, | which tells us that CR LF is one possible representation for end-of- | line. no, it says "the sequence CR LF to mean "end-of-line"." That is, if you mean end of line, CR LF is how it is represented. Not that this is really very important, for us, as it is about telnet, not FTP. But note it also says: "The Telnet protocol defines" - it is clearly just restating what RFC854 said - and if you look there you'll see quite reasonably defined what CR, LF and CRLF achieve. What wasn't defined well, was what was supposed to happen when a telnet client sends just CR (CR NUL of course) or LF to the server, whereas that was defined from server to client (moving the carriage and all that). That is what 1123 is fixing - making it clear that if the client happens to send what the server system would treat as the end of command sequence, then the that's how it should be treated. Otherwise you get absurd situations where I type DIR on a unix system, where I have mapping from CR to end of line disabled (ie: the CR is just a character) - the telnet client correctly sends D I R SP CR NUL CR LF to the server. Assume that's a DOS type server, where EOL is . Now the telnet server there would have (under some readings of 854) been required to transfer the command "DIR " to the DOS "shell" where the isn't supposed to represent end of line - which is simply impossible (or impossible to do in any rational way). The text in 1123 is all there to make it clear that the telnet server in that case is allowed to (in fact, must) treat that CR as an end of line (and the following CR LF as another). See also, in 854: Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; That's the definition of the telnet "newline" character, which is also called "end of line" in other places (in 854 only when discussing the GA (go ahead) command), but FTP assumes it...). Once again however, we're not concerned with Telnet here, but with FTP, and in rfc959, what it says is ... In accordance with the NVT standard, the sequence should be used where necessary to denote the end of a line of text. (see page 11). Not CR NUL, not LF, but CRLF. For FTP, that is it. Period. See also ... The File Transfer Protocol follows the specifications of the Telnet protocol for all communications over the control connection. Since the language used for Telnet communication may be a negotiated option, all references in the next two sections will be to the "Telnet language" and the corresponding "Telnet end-of-line code". Currently, one may take these to mean NVT-ASCII and . Once again, CRLF, nothing else. | The second paragraph goes on to inform us that, when received via a | Telnet connection, the sequences CR LF and CR NUL are interchangable. No, that's not what it says at all. It says that "On server hosts that use ASCII" (which seems to be some peculiar way to subset servers), "receipt of the Telnet sequence CR LF must cause the same effect as a local user pressing the CR key on a local terminal." Now if that meant what it seems to say, then receiving CR LF on a unix host with cr -> lf mapping turned off (which it would be if you were using one of the terminals that actually had a "newline" key which generated "lf" - which is the kind of terminal that gave unix its LF==end of line characteristic) would simply cause a CR to be inserted into the data stream, and wouldn't be an end of line at all. But since everyone agrees that CR LF is end of line, that would be nonsense. So, instead read this so it makes sense - and assume that by "hosts thst use ASCII" what they really mean is as defined in the previous paragraph... For terminal input, this corresponds to a command- completion or "end-of-line" key being pressed on a user terminal; on an ASCII terminal, this is the CR key, but it may also be labelled "Return" or "Enter". That is, this there's an assumption that on an "ascii host" CR is the normal terminal end of line character. And there, we have exactly the situation described above - whether we send the telnet end of line, or the host's native end of line, they both have to have the same effect (for telnet) because anything else is absurd. Note, this isn't a modification of NVT, where CR LF is end of line, but a specific direction to the server to (in that circumstance) treat CR NUL identically to end of line (they're different, but they both achieve the same thing). | The third tells us that when sent over a Telnet connection from a | user-FTP (the only user-Telnet in the FTP), either CR LF or CR NUL | can be sent for the end-of-line, the choice is up to the user, and | the default is CR LF. no, that paragraph doesn't say that either. What it says is that users need to be able to send all 3 forms, and the telnet client must make a mechanism available (to the end user) to send any of the three when the user desires. That's to allow for interoperability with broken servers, or more likely, with systems that need to be able to receive any arbitrary one of the three. But CRLF is what gets sent unless the user specifically changes things. A user using telnet to talk to a FTP server would have no reason to alter the default, as FTP servers only treat CRLF as end of line (and always treat CRLF as end of line). We don't need to do anything to cope with users who decide to deliberately send something non-conformant. | The fourth tells us that when sent over a Telnet connection from a | server-FTP, only CR LF may be sent. You didn't read that one either ... I'll quote it again... The Telnet end-of-line sequence CR LF MUST be used to send Telnet data that is not terminal-to-computer (e.g., for Server Telnet sending output, or the Telnet protocol incorporated another application protocol). Note the final clause in the parenthesised sentence. or the Telnet protocol incorporated another application protocol That is exactly what we have here (and in SMTP, and others) - the Telnet protocol incorporated in another application protocol. And see what 1123 is telling you "The Telnet end-of-line sequence CR LF MUST be used". Can it be any clearer? The text that Alun Jones just sent is also directly on point. So ... | In RFC 2119 terms: | | FTP implementations MUST interpret CR LF as marking the end- | of-line. [First paragraph, explicitly.] yes. | FTP implementations MAY interpret sequences other than CR LF | as marking the end-of-line. [First paragraph, by conversion.] no. | FTP implementations MUST interpret CR LF and CR NUL | interchangably. [Second paragraph, explicitly.] no. | FTP implementations MUST therefore interpret CR NUL as marking | the end-of-line. [Second paragraph, by deduction.] no. | The user-FTP, when implemented as a user-Telnet, MUST offer a | configuration option allowing transmission of CR NUL to mark | the end-of-line. The default for this option MUST be to | transmit CR LF to mark the end-of-line. [Third paragraph, | explicitly.] no. If you happen to be using a telnet implementation to talk to a ftp server, then the implementation must offer that option, but to correctly interoperate with ftp, the user must not use it. Just as the user must not cause telnet option negotiation to be attempted, though a telnet client would normally allow that as well. | The user-FTP, when not implemented as a user-Telnet, MAY offer | a configuration option allowing transmission CR NUL to mark | the end-of-line. The default for this option MUST be to | transmit CR LF to mark the end-of-line. [Third paragraph, | by conversion.] no. | The user-FTP, when not implemented as a user-Telnet and which | does not offer a configuration option allowing transmission of | CR NUL to mark the end-of-line, MUST transmit CR LF to mark | the end-of-line. [Third paragraph, also by conversion.] just always send CRLF, no options, no choices. | The server-FTP MUST transmit the sequence CR LF to mark the end- | of-line. [Fourth paragraph, explicitly.] yes, though the part you're getting that from isn't the part of the paragraph that is most on point. | While the server-FTP MAY interpret sequences other than CR LF and | CR NUL to mark the end-of-line, the user-FTP cannot send any others. user FTp has to send CRLF, nothing else. | So, in answer to the points raised so far about my comments on the | MLST draft: | | 1) You are incorrect. CR NUL quite definitely MUST be interpreted | as the Telnet end-of-line. Therefore we have no alternate form | for the "bare" CR to be used in a file, directory or path name. No, that is simply wrong. The fact that it takes such a convoluted argument to arrive at this position should be a pretty good clue that it isn't correct. The early RFCs were not big on convoluted arguments. Everything is meant to be interpreted in the obvious way. kre From ftp-wg-owner@hethmon.com Thu Apr 25 18:58: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 SAA08568 for ; Thu, 25 Apr 2002 18:58:39 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425180516-32917-9 ; Thu, 25 Apr 2002 18:05:16 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425180513-7232-8 ; Thu, 25 Apr 2002 18:05:14 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3PMthD14946 for ; Thu, 25 Apr 2002 18:55:43 -0400 Message-ID: <002401c1ecac$544ac1c0$0b0d85cd@vr.net> References: <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20020425075601.01d9ae50@208.55.91.110> 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, 25 Apr 2002 18:05:14 -0500 X-OldDate: Thu, 25 Apr 2002 18:55:37 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alun Jones" To: "FTPEXT Working Group" Sent: Thursday, April 25, 2002 9:06 AM Subject: Ftp-WG: Re: MLST draft - NUL CR LF again > At 07:10 AM 4/25/2002, Gregory A Lundberg wrote: > >OK. Obviously we're reading different versions of RFC 1123. > >I got mine from rfc-editor.org and here's what is says on page 21: > ... > > The Telnet end-of-line sequence CR LF MUST be used to send > > Telnet data that is not terminal-to-computer (e.g., for Server > > Telnet sending output, or the Telnet protocol incorporated > > another application protocol). > > > >Nowhere in there does it make ANY requirement that end-of-line may > >only be represented by CR LF. > ... > >The fourth tells us that when sent over a Telnet connection from a > >server-FTP, only CR LF may be sent. > ... > > The server-FTP MUST transmit the sequence CR LF to mark the end- > > of-line. [Fourth paragraph, explicitly.] > > That's not how I read the fourth paragraph of RFC 1123, section 3.3.1. I > read it as saying that when "the Telnet protocol is incorporated in another > protocol", as we have here, "the Telnet end-of-line sequence CR LF MUST be > used". > > 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 Thu Apr 25 21:05:52 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 VAA10410 for ; Thu, 25 Apr 2002 21:05:51 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425201229-27875-9 ; Thu, 25 Apr 2002 20:12:29 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020425201227-1110-8 ; Thu, 25 Apr 2002 20:12:27 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3Q12wD24027 for ; Thu, 25 Apr 2002 21:02:58 -0400 Message-ID: <003001c1ecbe$1b39d1c0$0b0d85cd@vr.net> References: <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20020425073030.01ddebd0@208.55.91.110> 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, 25 Apr 2002 20:12:28 -0500 X-OldDate: Thu, 25 Apr 2002 21:02:52 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit > >Now, if you want to DROP the requirement that FTP work with a normal Telnet > >client, that's fine. But, if you do, expect inter-operation problems with > >existing implementations. > > I'm trying hard to find that requirement in the RFCs. RFC 959 specifies in > several places that the control connection follows the Telnet protocol, but > it (and RFC 1123) further defines several places where behaviour is > different. Where there is such a contradiction, it would seem that the > obvious conclusion is that RFC 959, and the FTP sections of RFC 1123, win > out over Telnet. Perhaps this deserves being stated somewhere, but I don't > think this is ambiguous. RFC 959, page 1, paragraph 1 "INTRODUCTION" ... FTP, though usable directly by a user at a terminal, is designed mainly for use by programs. The "terminal" being referred to here is the Telnet NVT. This is a "may" statement: "A Telnet user MAY directly use the FTP." RFC 959, page 7, "TERMINOLOGY" ... user A person or a process on behalf of a person wishing to obtain file transfer service. The human user may interact directly with a server-FTP process, but use of a user-FTP process is preferred since the protocol design is weighted towards automata. This already is a "may" statement, followed by a "should": "A human user MAY interact directly with a server-FTP process, but SHOULD use a user-FTP process since the protocol design is weighted towards automata." RFC 959, page 8, paragraph 2, "THE FTP MODEL" ... The user may establish a direct control connection to the server-FTP, from a TAC terminal for example, and generate standard FTP commands independently, bypassing the user- FTP process. The term "TAC terminal" here is historical and unfortunate. It owes to copying this section from older versions. With the advent of Telnet, the physical "TAC terminal" was replaced with the NVT. We cannot get must more clear than this. The clear intention is that the user-FTP process is OPTIONAL. Interaction with the server-FTP is through the control connection. The control connection follows the Telnet protocol. Therefore, the tool to use to bypass the user-FTP process is a user Telnet implementation. RFC 959, page 9 ... The Relationship between FTP and Telnet: The FTP uses the Telnet protocol on the control connection. This can be achieved in two ways: first, the user-PI or the server-PI may implement the rules of the Telnet Protocol directly in their own procedures; or, second, the user-PI or the server-PI may make use of the existing Telnet module in the system. Ease of implementaion, sharing code, and modular programming argue for the second approach. Efficiency and independence argue for the first approach. In practice, FTP relies on very little of the Telnet Protocol, so the first approach does not necessarily involve a large amount of code. This informs us that NOT ONLY can we bypass the user-FTP process, but an FTP implementation (server- OR user-) MAY its own internal implementation of the Telnet protocol, or it MAY use an existing Telnet module provided by the host system. While some hosts may provide a link-time module which an FTP implementation can use, the most widely available Telnet module is the user Telnet implementation. On Unix, for example, this module is generally called the 'telnet command'. Given the relationship described here, a perfectly good (albeit slow) server-FTP could be implemented using nothing more than 'expect' scripts and the 'telnet' command. While doing a server-FTP in 'expect' is probably something few have ever considered, implementing a user-FTP in 'expect' and 'telnet' is uncommon but has been done. Implementing a user-FTP with 'shell' scripts using the 'telnet' command is common enough that I get several questions a year pertaining to it. There are probably several more citations I could make, but I think these are enough. Besides, it's time to put the kids to bed, and I have a contract out-of-town for the next few days so I need to get to bed early and hit the road tomorrow ... From ftp-wg-owner@hethmon.com Sat Apr 27 00:06:04 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 AAA28377 for ; Sat, 27 Apr 2002 00:06:04 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020426231227-37250-9 ; Fri, 26 Apr 2002 23:12:27 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020426231225-10453-8 ; Fri, 26 Apr 2002 23:12:25 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3R42rD15642 for ; Sat, 27 Apr 2002 00:02:54 -0400 Message-ID: <001201c1eda0$685a8e80$0b0d85cd@vr.net> References: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <11653.1019739858@mundamutti.cs.mu.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: Fri, 26 Apr 2002 23:12:26 -0500 X-OldDate: Sat, 27 Apr 2002 00:02:47 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit Bitch all you want, but we ALL support CR NUL as end-of-line. $ telnet telnet>unset crlf Will send carriage returns as telnet . telnet>open munnari.oz.au 21 Trying 128.250.22.2... Connected to munnari.oz.au. Escape character is '^]'. 220 munnari.OZ.AU FTP server (Version 5.95 2000/07/08 21:15:53) ready. user ftp 331 Guest login ok, send ident as password. pass lundberg@ 230 Guest login ok, access restrictions apply. quit 221 Goodbye. Connection closed by foreign host. $ telnet telnet>unset crlf Will send carriage returns as telnet . telnet>open ftp.ipswitch.com 21 Trying 156.21.4.254... Connected to ftp.ipswitch.com. Escape character is '^]'. 220-ftp1.ipswitch.com X2 WS_FTP Server 3.0.1 (1609819023) 220-Welcome to ftp1.ipswitch.com 220-This server is located in Massachusetts, USA 220 ftp1.ipswitch.com X2 WS_FTP Server 3.0.1 (1609819023) user ftp 221 Password required pass lundberg@ 230 user logged in quit 221 Good-Bye Connection closed by foreign host. $ telnet telnet>unset crlf Will send cariage returns as telnet . telnet>open ftp.wu-ftpd.org 21 Trying 205.133.13.60... Connected to ftp.wu-ftpd.org. Escape character is '^]'. 220 ftp.wu-ftpd.org FTP server ready. user ftp 331 Guest login ok, send your complete e-mail address as password. pass lundberg@wu-ftpd.org 230-Welcome to the FTP server for the WU-FTPD Development Group 230- 230-This server is the primary distribution site for the WU-FTPD daemon. 230- 230-The pub directory contains the distribution and supporting files. 230- 230-If you are uploading contributions, please place them in the incoming 230-directory and email wuftpd-members@wu-ftpd.org announcing your upload. 230- 230 Guest login ok, access restrictions apply. quit 221 Goodbye. Connection closed by foreign host. $ From ftp-wg-owner@hethmon.com Sat Apr 27 03:16: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 DAA27181 for ; Sat, 27 Apr 2002 03:16:46 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427022323-28734-9 ; Sat, 27 Apr 2002 02:23:23 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427022320-1555-8 ; Sat, 27 Apr 2002 02:23:21 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id HA08923; Sat, 27 Apr 2002 17:14:48 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <001201c1eda0$685a8e80$0b0d85cd@vr.net> References: <001201c1eda0$685a8e80$0b0d85cd@vr.net> <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <11653.1019739858@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <27767.1019891688@mundamutti.cs.mu.OZ.AU> Date: Sat, 27 Apr 2002 02:23:22 -0500 X-OldDate: Sat, 27 Apr 2002 17:14:48 +1000 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: Re: MLST draft - NUL CR LF again Date: Fri, 26 Apr 2002 23:12:26 -0500 From: "Gregory A Lundberg" Message-ID: <001201c1eda0$685a8e80$0b0d85cd@vr.net> | Bitch all you want, but we ALL support CR NUL as end-of-line. I know, my server is full of bugs in that area, no question about it. kre From ftp-wg-owner@hethmon.com Sat Apr 27 09:17: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 JAA02980 for ; Sat, 27 Apr 2002 09:17:42 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427082418-39660-9 ; Sat, 27 Apr 2002 08:24:18 0000 Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427082414-10064-8 ; Sat, 27 Apr 2002 08:24:15 0000 Received: from chirho.texis.com (adsl-65-67-61-15.dsl.austtx.swbell.net [65.67.61.15]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3RDFhU203486 for ; Sat, 27 Apr 2002 09:15:43 -0400 Message-Id: <4.3.2.7.2.20020427081346.02452560@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <001201c1eda0$685a8e80$0b0d85cd@vr.net> References: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <11653.1019739858@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Sat, 27 Apr 2002 08:24:16 -0500 X-OldDate: Sat, 27 Apr 2002 08:14:27 -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: MLST draft - NUL CR LF again At 11:12 PM 4/26/2002, you wrote: >Bitch all you want, but we ALL support CR NUL as end-of-line. Does this mean that you feel you have lost the argument over standards, and now you want to try and win it by pointing to implementations? 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 Apr 27 16:12: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 QAA18095 for ; Sat, 27 Apr 2002 16:12:08 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427151848-39796-9 ; Sat, 27 Apr 2002 15:18:48 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427151846-12945-8 ; Sat, 27 Apr 2002 15:18:46 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3RK9DD27408 for ; Sat, 27 Apr 2002 16:09:13 -0400 Message-ID: <000701c1ee27$66e678c0$0b0d85cd@vr.net> References: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <11653.1019739858@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20020427081346.02452560@208.55.91.110> 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: Sat, 27 Apr 2002 15:18:46 -0500 X-OldDate: Sat, 27 Apr 2002 16:09:07 -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: Re: MLST draft - NUL CR LF again Content-Transfer-Encoding: 7bit > >Bitch all you want, but we ALL support CR NUL as end-of-line. > > Does this mean that you feel you have lost the argument over standards, and > now you want to try and win it by pointing to implementations? No, actually I think it's just more evidence that no matter how much you don't like it, CR NUL does mean end-of-file. As for the argument, no .. but Here's my opinion in the argument: What the TRUE definition is does not matter. - The standards CAN be analyzed as written, without opinion, and if so, they WILL show CR NUL to end-of-line. - The real-world implementations show CR NUL to be end-of-line. - But those who don't like the fact that CR NUL is end-of-line are so well entrenched in their wrongheadedness that it appears fruitless to try to change their minds. Here's my take on it: 1) FTP is based on Telnet. This has not (yet) been disputed. 2) A server-FTP MUST interoperate with a user-Telnet. This is plain from the wording of RFC 959. A user-FTP is OPTIONAL. 3) A user-Telnet SHOULD send CR LF for end-of-line; A user-Telnet SHOULD have an option to send other codes for end-of-line; That option MUST provide CR NUL as one of the other codes for end-of-line. That option MAY allow other codes beyond CR NUL as alternatives. This is plain from the wording of RFC 1123. In addition, real-world tests show the authors of user-Telnet understand this and provide at least the minimum requirement of CR NUL as an alternative for CR LF. Therefore a server-FTP a) MUST accept CR LF as meaning end-of-line This is plain from the wording of RFC 959. b) SHOULD accept CR NUL as meaning end-of-line c) SHOULD provide an option allowing additional codes to be taken as meaning end-of-line. As a result of (b), there is no means to accept a bare CR (which MUST be followed by a NUL, as is plain from the RFCs) as a "data" character. As a result of (c), there MAY be no means to accept other characters from the 7-bit ASCII character set (EM was given as an example) as a "data" character. Therefore, the FTP needs a method to "escape" any character from the 7-bit ASCII character set so that the user-Telnet's "local convention" of using some other character to mean end-of-line may be circumvented. The arguments I've seen so far are: 1) FTP is not required to interoperate with user-Telnet. Manifestly false. The clear intention of the original FTP authors, from as far back as you care to go, is that FTP interoperate with Telnet. 2) A user has no reason to change the default, therefore we don't need to worry about those who did. Violates the principles of robustness (see the top of RFC 1123, just to name one place where this principle is stated. I believe you'll find it in RFC 959 as well). 3) Early RFCs should were intended to be taken as read and should not require long discussions analyzing the intended meaning. Obviously false. Read RFC 1123 and it becomes clear that the oversights and inclear wording in early RFCs caused a great deal of problems. 4) In matters where FTP and Telnet cover the same ground, the FTP should win out. False. By extension, this faultly thinking would have the FTP rule TCP and IP in matters where the requirements of those protocols differ from the requirements of FTP. Telnet defines Telnet. If the FTP is at odds with Telnet, either the FTP should make it clear it no longer users Telnet, or the Telnet specification wins. 5) The Telnet implementation in the FTP is somehow "different" than the Telnet implementation in Telnet. Well, this _is_ true. But not for end-of-line. The ONLY difference between the Telnet in Telnet and the Telnet in FTP is the Telnet Go-Ahead function: A server-FTP MUST NOT send Telnet Go-Ahead while a server-Telnet MUST send it until negotiated otherwise. (Note this has implications on HOW a server-FTP should "refuse to negotiate" concerning the Telnet Suppress Go-Ahead Option; which I'm still trying to work out the effects of.) From ftp-wg-owner@hethmon.com Sat Apr 27 22:56: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 WAA00608 for ; Sat, 27 Apr 2002 22:56:31 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427220318-42233-9 ; Sat, 27 Apr 2002 22:03:18 0000 Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427220315-12918-8 ; Sat, 27 Apr 2002 22:03:16 0000 Received: from chirho.texis.com (adsl-65-67-61-15.dsl.austtx.swbell.net [65.67.61.15]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3S2siU37172 for ; Sat, 27 Apr 2002 22:54:44 -0400 Message-Id: <4.3.2.7.2.20020427170023.01dbcb80@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <000701c1ee27$66e678c0$0b0d85cd@vr.net> References: <000801c1ec50$ea61c7a0$0b0d85cd@vr.net> <009a01c1ec20$dfa49b60$0b0d85cd@vr.net> <008301c1ec08$c9694f20$0b0d85cd@vr.net> <20020424215612.64453.qmail@web21108.mail.yahoo.com> <8976.1019712297@mundamutti.cs.mu.OZ.AU> <9447.1019717149@mundamutti.cs.mu.OZ.AU> <11653.1019739858@mundamutti.cs.mu.OZ.AU> <4.3.2.7.2.20020427081346.02452560@208.55.91.110> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Sat, 27 Apr 2002 22:03:16 -0500 X-OldDate: Sat, 27 Apr 2002 21:58:19 -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: MLST draft - NUL CR LF again At 03:18 PM 4/27/2002, you wrote: >No, actually I think it's just more evidence that no matter how much you >don't like it, CR NUL does mean end-of-file. As the developer of an FTP server that accepts CR NUL as an end of line sequence, I can tell you that I consciously made the decision to allow CR, LF, or CR LF to act as end-of-line sequences, not because of any reading of the RFCs, but because I saw requests coming from clients that contained those sequences. Originally, I had set the program up to only accept CR LF as an end-of-line sequence, but had received a few reports of incompatibilities (often with user-written clients). Hang the RFC compliance, I thought at the time, nobody's going to actually _want_ a CR or LF in a file name, and if they do, then I can wave the compliance flag at the broken clients, because by that time I'll be more established. >As for the argument, no .. but > >Here's my opinion in the argument: What the TRUE definition is does not >matter. So in other words, it doesn't matter whether anyone else agrees with you or not, your opinion is absolute. >- The standards CAN be analyzed as written, without opinion, and if so, they >WILL show CR NUL to end-of-line. Analysing the standards as written, without opinion, demonstrates that there is contradiction and confusion. >- The real-world implementations show CR NUL to be end-of-line. The real-world implementations _treat_ CR NUL as if it were end-of-line. >- But those who don't like the fact that CR NUL is end-of-line are so well >entrenched in their wrongheadedness that it appears fruitless to try to >change their minds. Those of us who persist in our "wrongheadedness" are convinced that the RFCs are confused and contradictory, and that the FTP RFC outranks the Telnet RFC in describing what behaviour FTP implementations should adhere to. You appear to be of the opinion that Telnet outranks FTP in describing FTP. >Here's my take on it: > >1) FTP is based on Telnet. > > This has not (yet) been disputed. > >2) A server-FTP MUST interoperate with a user-Telnet. > > This is plain from the wording of RFC 959. A user-FTP is OPTIONAL. And yet... you point so frequently to "real implementations" - how many real implementations of FTP clients rely on Telnet client code as their base? How many real implementations of FTP servers rely on Telnet server code as their base? >3) A user-Telnet SHOULD send CR LF for end-of-line; > A user-Telnet SHOULD have an option to send other codes for end-of-line; > That option MUST provide CR NUL as one of the other codes for >end-of-line. > That option MAY allow other codes beyond CR NUL as alternatives. > > This is plain from the wording of RFC 1123. In addition, real-world >tests show the authors of user-Telnet understand this and provide at least >the minimum requirement of CR NUL as an alternative for CR LF. I believe that it is a mistake to apply the Telnet updates in RFC 1123 as if they were an update to the FTP specifications in RFC 959. If the authors of the FTP section of RFC1123 had meant to include such additions, they surely would have - after all, they even went so far as to note that TCP is a stream-based protocol, and that you shouldn't make assumptions otherwise; surely if they had anything to say about including Telnet updates since RFC 854, they would have. >Therefore a server-FTP > > a) MUST accept CR LF as meaning end-of-line > > This is plain from the wording of RFC 959. Nobody is disputing that. > b) SHOULD accept CR NUL as meaning end-of-line Most implementations, if not all, do that at present, but not because of any reading of the RFC, so much as out of a desire to cope with poorly-ported FTP clients on the Macintosh (where CR _is_ the line terminator). Today, when file names with CR in them are more common, and Macintosh client code better written, the desire to support such file names appears stronger than the desire to support poor FTP clients, and thus server implementors seem willing, perhaps eager, to drop the use of CR NUL as EOL. > c) SHOULD provide an option allowing additional codes to be taken as >meaning end-of-line. Good grief, I'm not sure where I could imagine reading that in to being. Such an option would have to be negotiated with a connecting client, surely, using the forbidden Telnet option negotiation. >As a result of (b), there is no means to accept a bare CR (which MUST be >followed by a NUL, as is plain from the RFCs) as a "data" character. So why not make it explicit that CR NUL is not acceptable as an EOL? >As a result of (c), there MAY be no means to accept other characters from >the 7-bit ASCII character set (EM was given as an example) as a "data" >character. Hell, why not decide on a client-server combination that uses 'q' as an end-of-line sequence? By that argument, surely any character should be forbidden from file names? >Therefore, the FTP needs a method to "escape" any character from the 7-bit >ASCII character set so that the user-Telnet's "local convention" of using >some other character to mean end-of-line may be circumvented. You're heading towards arguing that FTP can't use any 7-bit ASCII character to represent anything other than EOL. >The arguments I've seen so far are: > >1) FTP is not required to interoperate with user-Telnet. Manifestly false. And yet, holding FTP back to its "every user is TCP savvy, and is comfortable typing bare protocol" roots would seem to be stifling its future development. >The clear intention of the original FTP authors, from as far back as you >care to go, is that FTP interoperate with Telnet. The clear intention of the original FTP authors is that it support EBCDIC to ASCII translation, and that it handle mail and Instant Messaging as well. Times change, people change, hair styles change. >2) A user has no reason to change the default, therefore we don't need to >worry about those who did. Violates the principles of robustness (see the >top of RFC 1123, just to name one place where this principle is stated. I >believe you'll find it in RFC 959 as well). However, new features often kill off old and unused functionality. Yes, accepting CR NUL as indicative of a CR in a file name would lead to people using poorly written FTP clients, or poorly configured Telnet clients (really, how many people are you talking about) being unable to continue to use such an FTP server. But it would benefit by granting the ability to put a CR into a file name transferred by FTP. Are you so in awe of the original authors of RFC 959 that you believe that it is written in stone tablets by the hand of ghod? Did you join this working group mailing list to suggest that nothing ever be changed? >3) Early RFCs should were intended to be taken as read and should not >require long discussions analyzing the intended meaning. Obviously false. >Read RFC 1123 and it becomes clear that the oversights and inclear wording >in early RFCs caused a great deal of problems. And they still do. But I didn't see anyone arguing that they don't. >4) In matters where FTP and Telnet cover the same ground, the FTP should win >out. False. By extension, this faultly thinking would have the FTP rule >TCP and IP in matters where the requirements of those protocols differ from >the requirements of FTP. Telnet defines Telnet. If the FTP is at odds with >Telnet, either the FTP should make it clear it no longer users Telnet, or >the Telnet specification wins. FTP uses almost nothing of Telnet. Modern FTP implementations, at least as far as I have seen, have no use of Telnet code base. The original reasons for using Telnet as an under-layer for FTP are almost entirely gone. >5) The Telnet implementation in the FTP is somehow "different" than the >Telnet implementation in Telnet. Well, this _is_ true. But not for >end-of-line. > >The ONLY difference between the Telnet in Telnet and the Telnet in FTP is >the Telnet Go-Ahead function: A server-FTP MUST NOT send Telnet Go-Ahead >while a server-Telnet MUST send it until negotiated otherwise. (Note this >has implications on HOW a server-FTP should "refuse to negotiate" concerning >the Telnet Suppress Go-Ahead Option; which I'm still trying to work out the >effects of.) The Telnet in FTP should also not try any option negotiation. The Telnet in FTP is also not designed to be character-based or provide any line-editing facilities. In fact, there's so little of Telnet in FTP that it's strange that it was required to be included. 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 Sun Apr 28 00:01:37 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 AAA06876 for ; Sun, 28 Apr 2002 00:01:37 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427230823-63946-9 ; Sat, 27 Apr 2002 23:08:23 0000 Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020427230821-42166-8 ; Sat, 27 Apr 2002 23:08:22 0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id XAA15480; Sat, 27 Apr 2002 23:59:50 -0400 (EDT) In-Reply-To: Your message of Sat, 27 Apr 2002 22:03:16 -0500 Message-ID: Date: Sat, 27 Apr 2002 23:08:22 -0500 X-OldDate: Sat, 27 Apr 2002 23:59:49 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: Re: MLST draft - NUL CR LF again This whole argument about accepting CR-NUL as an EOL is ridiculous. For starters, the use of CR-NUL is an on the wire representation of CR to allow parsers to know when they can stop reading data from the input channel. The rule becomes if you read a CR and you are an NVT, then you must read at least one more character. if the character is NUL, you throw it away, otherwise, you keep it. Therefore, the use of CR-NUL as anything is stupid since the NUL must be discarded. If you need to send CR NUL as data it must be sent as CR NUL NUL. To send it as anything else would be to corrupt the data stream. Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ftp-wg-owner@hethmon.com Sun Apr 28 08:29:46 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 IAA06411 for ; Sun, 28 Apr 2002 08:29:45 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428073611-64832-9 ; Sun, 28 Apr 2002 07:36:11 0000 Received: from CHINS (163.25.99.33 [163.25.99.33]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428073608-37439-8 ; Sun, 28 Apr 2002 07:36:09 0000 Received: from kimo by ibm.com with SMTP id VXr7PTc6VL9V3fx5V2hLIAEDvzRU; Sun, 28 Apr 2002 20:29:42 +0800 Message-ID: X-Mailer: bYpP6XGRtyaD6FeTqAW Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Date: Sun, 28 Apr 2002 07:36:10 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: 長庚企業管理研究所 To: Thank.You Subject: Ftp-WG: =?big5?Q?=A5u=ADn=A4=BB=A4=C0=C4=C1=B0e=B1z=AA=F7=A5=DB=B0=F3=C2=A7=A8=F7!?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ietf.org id IAA06411 各位社會的先進打擾了! 我是長庚企研所的研究生,透過網路mail搜尋軟體,有幸得知貴公司(或個人)的mail,，由於我的研究是有關B2B網路電子市集的消費者行為,問卷對象是企業用戶在問卷蒐集上並不容易 因此想先以有工作經驗者作為前測。本問卷採用實驗情境的方式 僅有27個量表 大概會花您六分鐘的時間。在問卷確實回收且為有效樣本後，本人將以電子郵件的方式回覆您並郵寄100元的金石堂禮券以感謝您抽空填完本人的問卷。 請點選該網址： 實驗情境五 http://home.pchome.com.tw/society/nikky520/S5.htm From ftp-wg-owner@hethmon.com Sun Apr 28 09:50:37 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 JAA15110 for ; Sun, 28 Apr 2002 09:50:36 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428085659-9971-9 ; Sun, 28 Apr 2002 08:56:59 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428085656-48181-8 ; Sun, 28 Apr 2002 08:56:57 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA23532; Sun, 28 Apr 2002 23:48:24 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <6671.1020001703@mundamutti.cs.mu.OZ.AU> Date: Sun, 28 Apr 2002 08:56:57 -0500 X-OldDate: Sun, 28 Apr 2002 23:48:23 +1000 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: Re: comments on the MLST draft Date: Wed, 24 Apr 2002 14:29:47 -0500 From: "Gregory A Lundberg" Message-ID: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> | Second paragraph SHOULD read | | These commands allow a client to obtain directory listings in a | machine-friendly, predictable format; and MAY allow a client to | restart an interrupted transfer in transfer modes not previously | supported in any documented manner." I have no idea what that trailing quote is about (there's no opening one) but no it shouldn't. If the commands are implemented as described, they do allow a client to restart. That isn't going to always work, because the file might have changed, etc - but the introduction doesn't have get into that kind of detail. (And MAY in upper case would be completely inappropriate anyway). | 2.2 Pathnames | | In the third paragraph, discussing encoding of pathnames, it may be | informative to explicitly state that the CR character MUST NOT | appear in pathnames That would be wrong. If the server supports CR in filenames, and the client desires to use it, then it can do so. There's no requirement on the server to actually allow the CR character to appear in a filename of course. | but that, when using UTF-8, a CR MAY be sub- | optimally encoded using a two (or more) byte UTF-8 representation | instead of the normal one-byte encoding. Sub-optimal encoding | SHOULD NOT be used except to represent the CR character as a data | character rather than a line-termination character. We've just been through this argument, the CR character is not a line-termination character, unless it appears as CRLF, so this is irrelevant, if needed, CR can be sent as CR NUL. If the server is going to support CR in file names, then it had better support that method of transferring it. If it has no CRs in file names, then it really doesn't matter very much (the error messages will be nicer if it does the right thing, but that's about it). | The fourth paragraph should read: | | Implementations should also be aware that the control connection | uses a subset of the Telnet NVT conventions. Actually, it uses all of them. | The Telnet IAC | character, if part of a pathname sent over the control connection, | MUST be correctly escaped as defined by the Telnet protocol prior | to transmission and after conversion from to the transport | representation from the host's internal representation. Those look to be extra words that don't actually say anything new. | 2.2.1 Pathname syntax. | | Last sentence should read: | | The server-FTP implementation SHOULD NOT restrict the syntax of | valid file and directory names unless failure to do so would | violate the contraints placed upon file and directory names by the | host system. The last sentence of that section is currently ... Similarly, a server-PI may parse the pathname, and assign meaning to the components detected. I don't see that your replacement is in any way related. The penultimate sentence would be closer, but I can't think of any reason that we need to attempt to tell FTP server implementors what to do there - that looks more like a quality of implementation issue. If I want to supply a server for a unix system which only allows file names made up of a's and b's, why should any spec attempt to prohibit that? If all the files that some user needs to deal with are named a aa ab ba baa aba (etc) then that server would work fine for that installation. | 2.3 Times | | It may be informative to explicitly state that the reason for the UTC | requirement is to make it possible for a user to compare time stamps | across servers. Perhaps, but I don't think I really want to issue a revision of this doc for just that. And in any case, it also allows the user/client to actually know (reasonably closely) what the time represents. The real reason to pick UTC is because we don't want to have to try and send time zone information (ie: we either pick a zone, and everyone knows what it is, or we have to include the zone with the time ... because part of the use of this is existing code from 16-17 years ago now, we're not going to alter the choice that was made back then). | The user SHOULD be aware that servers MAY not have | synchronized clocks and some may use GMT or one of the other time | standards. I think that's clear enough in there already. | Thus, appropriate use of the time stamps produced by | different hosts would be relative order, not absolute marks, As is that - and if the user can't figure out that attempting to make sense out of unsynchronised clocks, then I'm not sure that anything that is said here will help. | with | differences of less than a few hours being considered equality. If we were to start a discussion on that, I don't think that would be the approach that would make sense. Basically times from different servers are just different - they should be used for two purposes, first for comparing against other times from the same server (where equality is equality, and nothing else is), or for using to modify timestamps of local files to match those of remote files (for mirroring, etc). | It | might also be a good idea to explicitly caution against reliance upon | time stamps; not only are clocks often not synchonized, they are | often set by hand (if set at all) and may be wildly incorrect. I think that's at least implied well enough. | 3.1 (MDTM) Syntax | | This command is OPTIONAL No, I don't think we need to go adding that - it is already obvious in the text, eg, in ... When replying to the FEAT command [6], an FTP server process that supports the MDTM command MUST that makes it pretty clear that there can also be FTP server processes that don't support the FEAT command. The same response applies to the other times you have suggested adding this line, I won't repeat my replies (or any others where the same reply would apply to multiple comments). | Server-FTP implementors are cautioned to carefully consider the | implications of supporting MDTM command. The existance of certain | files MAY be used by attackers to "fingerprint" host systems. Be reasonable! The LIST command is much better at that kind of thing that MDTM will ever be. As is MLSD of course. | In | particular, where the existance of certain non-retrievable files is | to be hidden from the user, the MDTM command SHOULD be implemented | in such a manner that its reply does not inadvertently disclose the | existance of a file. Thus, the choice of response for non- | retrievable files SHOULD be governed by the server-FTP's response | elicited if the RETR were attempted using the same pathname argument. There's nothing here that applies to MDTM any more than to any other file. If you want to write a treatise on how to implement FTP servers that hide things from various subsets of users, please do so, but elsewhere. | 3.3 FEAT response for MDTM | =0A= | The user-FTP SHOULD NOT rely upon support of the FEAT command, or | the response to the FEAT command, to indicate support of the MDTM | command. While the inclusion of MDTM in the FEAT response is | positive indication of support for the command, its absence MUST NOT | be taken as indicating lack of support. There's no need for a MUST NOT there, if a client wants to use the absense of MDTM in FEAT output as indicating lack of support, then let it do so. Since it is clear from the doc that these commands (MDTM/REST/SIZE) have been around for ages, long before FEAT appeared, it should be pretty obvious that servers that implement them aren't necessarily going to implement FEAT. I don't really think we need to go out of the way to say so (and one presumes, that over time, the number or servers that don't support FEAT will dwindle, at which time it might be entirely reasonable to ignore the few that do support the commands but not FEAT - that is, for clients to assume that no FEAT output means no support). Other clients will ignore FEAT and just try the commands anyway - either strategy is acceptable. | 3.4 MDTM Examples | | User-FTP implementors are cautioned that some existing server-FTP | implementations MAY misinterpret the pathname "19990929043300 File6" | as a command to change the modification time of "File6". That might not be bad advice, if the doc were to be re-opened, but again, I don't think we need to issue a new version, just for this. | For maximum inter-operation, the user-FTP SHOULD use other means to | determine the existance of the pathname prior to attempting the MDTM | command. That's not bad advice, but would just be document bloat. It doesn't even help here, as if File6 exists, and "19990929043300 File6" also exists, a broken server will treat "MDTM 19990929043300 File6" as an attempt to modify the time of File6 - simply ignoring the other file (the decision gets made in the command parser, long before the filesystem is consulted). | 4. File SIZE | | This command is OPTIONAL. | | Server-FTP implementors are cautioned to carefully consider the | implications of supporting the SIZE command. The requirement is | that the value returned be precise, when coupled with the current | data transfer options, can consume significant resource. All this is already pretty clear... | To arrive | at a precise value for the SIZE response, the server-FTP=0A= | implementation MAY need to process the entire file as if it were | being transmitted, but without the delays involved with transmission. | An attacker could use the SIZE command to reduce or exhaust | resources, potentially reducing the host's ability to deliver file | transfer or other services offered by the host. Documenting every possible DoS attack that might ever be made would be a nice thing to do, but is way out of scope of this effort. | 4.2 (SIZE) Error responses | | When the current parameters would require conversion or modification | of the file during the data transfer process, the SIZE command | SHOULD return a 550 reply. Huh? You mean that unix servers shouldn't support SIZE in ASCII mode. We're documenting a command that already exists, and the servers *do* support it... | Thus, a positive completion reply to the | SIZE command indicates both the precise size of the file, and that | the data transfer process for the file involves no conversion or | modification operations on the server-FTP. But that isn't what it means in current implementations, and there's no way that is every going to be what it means. | 4.4 Size examples | | In the example give, the correct response to the second (TYPE A) | example should read: | S> 550 Size can not be determined. No, as the doc quite clearly says, all the examples come from actual FTP dialogs (even when I needed to create a bizarre server to make that be true...) No server I have sever seen says that, certainly none that I tested against, hence that response cannot appear in the doc. | 5.1 Restarting in STREAM mode. | | First paragraph, last sentence should read: | | However, there MAY not really be a need to have explicit restart | markers in this case, since restart markers MAY by implied by the | octet offset into the data stream. The upper case MAYs here are totally inappropriate. The paragraph as it stands is completely correct - in stream mode (where there's only one way to ever transfer a particular file), a restart position *can* (always) be determined by counting octets transferred. Sometimes it might be expensive to do, but it can *always* be done. There's no "may" about it. (Compare this with other transfer modes, where several different octet streams can transfer the identical file, so counting octets would be useless). | Second paragraph, second sentence should read:=0A= | | Thus, given the same transfer options, an octet offset SHOULD | always represent the same position within a given file. Again, upper case is totally inapproriate, and it isn't should, it is. If that isn't true, then it is a different file. | Implementors are cautioned to remember that, at the time the REST | command is interpreted, the specific file and direction of transfer | are unknown. That's true, but I have no idea why it is relevant. All the REST command ever does is same the arg to be used on a later STOR/RETR command (assuming it can be parsed correctly of course). | Server-FTP implementors are cautioned to consider the implications of | supporting the REST command for stream mode transfers. When | positioning to the desired octet offset, significant resources can | be consumed when the current transfer options would require the | server-FTP to perform conversion or modification on the data stream. I think this is all already clear. | The server-FTP MUST ensure that the REST command does not, itself, | imlicity extend the size of the file, or allow access to areas of | the file system allocated to, but not actually used by, the file. The server FTP doesn't need to do anything of the kind. It will often do that, but if it chooses to allow REST to extend a file, or write anywhere at all, then that's it's business. | When the octet offset given with the REST command would indicate a | position outside the current range of possible values (i.e., less | than zero or greater than the file's size), the server-FTP MUST | reply 550. To what? It can't be the REST command, as the file's size isn't known then. If a server is unable to restart a transfer, there is already test telling it to issue an error on the following transfer command. I really don't think we should be attempting to enumerate all the possible errors that can occur - and I certainly don't think we should be picking some of them for special treatment. | On some hosts, specifying a file position past the end | of file implicitly extends the file (possibly filling the new area | with uninitialized data). This could be used by an attacker to | exhaust file system resources. You mean as distinct from actually sending lots of data ??? there's nothing new here. | In addition, should the file | subsequently be retrieved, the uninitialized areas of the file could | contain potentially sensitive information which would otherwise not | be available via file transfer. I think I'll leave that bizarre scenario out... | For TYPE I, the acceptable range of values for the octet offset is | (0 <= REST <= SIZE); where SIZE is the size of the file. If the | restart marker is positioned at (or, if allowed, past) SIZE, a | subsequent RETR transfer SHOULD transfer no data, immediately | indicating end-of-file. If the restart marker is allowed to be | positioned past SIZE, a subsequent STOR transfer SHOULD fail; if the | restart marker is positioned at SIZE, a subsequent STOR transfer | SHOULD append to the file (as if REST had not been issued and the | APPE command had been used instead). All that is fine, but I don't think we actually need to say any of it. This is not an implementor's guide. | 5.3 (REST) Syntax | | Support for restart in stream mode is RECOMMENDED. Beats me why this is recommended and the others are just optional... They're all recommended, that's why there being documented. None of them is required. | | Explicitly state the offset zero is the first octet of the file. Not needed, the offset is the count of bytes transferred, if zero have been transferred, then we're at the start of the file. No need to treat the reader like an idiot. | The existing [RFC959] requirement for REST is that the next command | be a transfer command. Many existing server-FTP implementations | ignore this, and many existing user-FTP implementations depend upon | it being ignored. The following additional specification are needed: | | The restart marker MUST be reset to zero following any data | transfer (successful or otherwise). The ABOR and REIN commands | MUST discard any restart marker, resetting it to zero. I think that is already clear enough. | The SIZE command MUST ignore the restart marker and leave it | unchanged. Ignore it, yes, that's fine - leave it unchanged, no, I can think of no reason for that at all, and if existing clients assume that, then they are broken, and should be fixed. | The REST command MAY occur at any time; it SHOULD, however, be | followed by a RETR or STOR command. no, like 959, we want REST as near as practical before REST/STOR, not at any time. | The server-FTP MAY require=0A= | that the following a REST command with a non-zero argument to be | RETR or STOR by issuing a 350 reply; in which case, if the user- | FTP does not intend to issue a RETR or STOR, it MUST issue either | an ABOR command, or a REST 0 command, before proceeding with the | session. This is inventing some entirely new protocol, what we have done here is to document the existing (16 year old, or whatever) protocol, no invention. | If the restart marker has been set to a non-zero value, the | following commands SHOULD return negative completion replies: | LIST, MLST, NLST and STOU. But not MLSD ? But no, none of that. They're just undefined. | Following a STOR (or APPE or STOU), the file SHOULD be truncated | at the point the data transfer stream just completed indicated | end-of-file. For example, the effect of a STOR REST STOR | sequence SHOULD be the same as if the entire file had transferred=0A= | with a single STOR command. STOR commands end the same way regardless of whether a REST occurred or not. Nothing anywhere says any different. Whether the truncation occurs after the STOR has finished, or before it starts, is none of our business. | User-FTP implementors are cautioned ensure the user is well aware | that, although stream mode restart is supported, the results actually | obtained MAY differ from those which would occur if restart were not | used. While the MDTM, SIZE and MLSx commands MAY be used to indicate | when restarting a stream transfer will produce differing results, | they can not be reliably used to indicate the sequences would produce | identical results. For this reason, the user-FTP implementation | SHOULD NOT automatically attempt a restart following an interrupted | transfer, but MAY offer it as a option to the well-informed user. This is all quality of implementation stuff, and doesn't belong. | The server-FTP implementor is cautioned to carefully consider the | implications of allowing restart, especially in stream mode. Just above you said it was recommended... | Many "download accelerators" exploit some TCP features and attempt to | explicitly break up transfers by use of multiple sessions, the REST | command, and other features of the FTP. Such applications MAY | consume excessive host and network resources which MAY adversely | effect file transfer and other services offered by the host. Again, documenting every way that resources can be consumed, or DoS possibilities, is just beyond the scope. | 5.4 FEAT response for REST | | The user-FTP SHOULD rely upon support of the FEAT command, and | the response to the FEAT command, to indicate the REST command is | supported for stream transfers. Beats me why this one is different than the others - stream mode restart is supported in almost exactly the same set of servers that support MDTM and SIZE now, with or without FEAT. I'll reply to the rest another day... kre From ftp-wg-owner@hethmon.com Sun Apr 28 10:30:15 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 KAA19502 for ; Sun, 28 Apr 2002 10:30:14 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428093658-21590-9 ; Sun, 28 Apr 2002 09:36:58 0000 Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020428093654-6239-8 ; Sun, 28 Apr 2002 09:36:55 0000 Received: from loser (212.174.56.149) by mail.san.yahoo.com (6.5.017.1) id 3CBC69E100372869; Sun, 28 Apr 2002 07:28:04 -0700 Message-ID: <003b01c1eec0$ee377d30$9538aed4@loser> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.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: Sun, 28 Apr 2002 09:36:57 -0500 X-OldDate: Sun, 28 Apr 2002 17:27:59 +0300 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Fastream Technologies" To: "FTPEXT Working Group" Subject: Ftp-WG: On new commands Content-Transfer-Encoding: 7bit Hello, In our application (Fastream FTP++ P2P) we have multiple connection downloads (similar to Download Accelerator/GoZilla) with the help of REST command. I simply divide the file into segments and then merge the downloaded parts on the local-side. I want to implement the same feature for remote part also. I mean multiple connection uploads. However, on the remote size, there is nothing like a merge command. There is the command APPE but it only appends a local file to a remote file. Wouldn't it be nice if we add such a command to FTP? Also, in our application, we have a command called SITE MD5 similar to ones found in UNIX systems. But in our case, the MD5's are cached with a background thread. This enables KaZaA/iMesh like P2P functionality with multiple source-IP/port downloads. However lack of support from other applications limit the use to within FTP++-to-FTP++ only. As you may have understood, I propose this command also. Best Regards, G. Ates From ftp-wg-owner@hethmon.com Mon Apr 29 03:09: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 DAA05278 for ; Mon, 29 Apr 2002 03:09:01 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429021512-62004-10 ; Mon, 29 Apr 2002 02:15:12 0000 Received: from CHINS (163.25.99.33 [163.25.99.33]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429021507-37623-8 ; Mon, 29 Apr 2002 02:15:08 0000 Received: from tpts6 by gcn.net.tw with SMTP id mJZRtSfyYb13uDhRbrogVwr; Mon, 29 Apr 2002 15:08:46 +0800 Message-ID: X-Mailer: pEvxvpWdq4CXBMb2HHzfJz Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Date: Mon, 29 Apr 2002 02:15:10 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: 長庚企業管理研究所 To: Thanks Subject: Ftp-WG: =?big5?Q?=A5u=ADn=A4=BB=A4=C0=C4=C1=B0e=B1z=AA=F7=A5=DB=B0=F3=C2=A7=A8=F7!?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ietf.org id DAA05278 各位社會的先進打擾了! 我是長庚企研所的研究生,透過網路mail搜尋軟體,有幸得知貴公司(或個人)的mail,，由於我的研究是有關B2B網路電子市集的消費者行為,問卷對象是企業用戶在問卷蒐集上並不容易 因此想先以有工作經驗者作為前測。本問卷採用實驗情境的方式 僅有27個量表 大概會花您六分鐘的時間。在問卷確實回收且為有效樣本後，本人將以電子郵件的方式回覆您並郵寄100元的金石堂禮券以感謝您抽空填完本人的問卷。 請點選該網址： 實驗情境六 http://home.pchome.com.tw/society/nikky520/S6.htm From ftp-wg-owner@hethmon.com Mon Apr 29 06:32: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 GAA20131 for ; Mon, 29 Apr 2002 06:32:43 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429053918-24598-9 ; Mon, 29 Apr 2002 05:39:18 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429053916-5972-9 ; Mon, 29 Apr 2002 05:39:17 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3TATaD31568 for ; Mon, 29 Apr 2002 06:29:37 -0400 Message-ID: <000801c1ef68$bb6b6760$0b0d85cd@vr.net> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.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, 29 Apr 2002 05:39:17 -0500 X-OldDate: Mon, 29 Apr 2002 06:29:17 -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: Re: comments on the MLST draft Content-Transfer-Encoding: 7bit Granted, a lot of that "implementor be aware" stuff is because the doc started life as my notes to myself to remember to check things. On SIZE and MDTM being optional: I don't think they add anything. MLSx has the info; newer implementations should use MLSx and forget SIZE and MDTM. Older servers which don't have them shouldn't need to add them. Making the commands optional is a strong hint to client authors to switch to MLSx. On the problem with MDTM: You're right, there's really no good workaround if the server tries to change the time as in the example. On whether SIZE should error if the current mode would require conversion: To be honest, having supported the darned thing for years now, I'm just plain tired of explaining to admins that the reason their server got shut down was not an error in the server, but a consequence of them allowing such large files to begin with. I tried adding a sleep call occassionally, to let other processes have a chance, and all that did was gather complaints that it was taking WAY too long to get the size. Can anyone come up with a zero-growth cost means of determining the size? The only solution I can come up with is to marry something like MySQL and store such 'facts' there; and I don't EVEN want to think about the problems keeping that synchronized would cause. I didn't look too closely at the facts for MLSx, but I assume the size fact there is intended to be the actual, stored, size and not the on-the-fly size. If not, it'll suffer the same problems as SIZE. To be BRUTALLY honest, I wish SIZE had never been added. The "error on conversion" solution is the only way I've come up with which maintains the command as a cheap way to get the file's size without having to read through LIST output, and stop the DoS complaints. On why I recommend REST and not SIZE and MDTM: unlike SIZE and MDTM, REST for streams actually adds something useful to the protocol. I don't think it's the panacea the users think it is, and personally dis-recommend its use for most transfers. On why I say REST can appear anywhere: What I was trying to describe was the way existing clients misuse the command in an attempt to see if it _might_ work today. Yes, 959 says it must be immediately followed with a transfer command. But clients send it at the top of the session, when they're doing SYST and such, and it's typically a command or two away from the data transfer. On truncating the file to the STOR: You're right it does not matter that the truncation occur before or after the STOR, but it must occur; and I don't recall ever seeing it stated, though, that STOR following a REST truncates. On letting REST exceed the size: Sure, on a lot of systems, all you get is a huge file. But on others you get memory-image garbage. And on others you get whatever was recorded on that area of the drive. Allowing the creation of holes is much the same as allowing a short-length STOR which does not truncate. With REST we have given the users lseek(). They already have read() and write(). Suddenly we have a random-access file system implemented over FTP. As to whether implementor advice should be part of an RFC; security starts with design. On of the most common complaints about the FTP is it's total lack of regard for security. Much of that owes to the protocol's desire to make it easy to share files. But a lot of it comes from the fact that the common refrain is "Security issues are not discused in this memo." The intention of adding that section to the RFCs was to encourage authors to consider and discuss security issues. To date, it's main purpose, though, has been for the author to admit that, if he did the considering, he didn't do the discussing. On the stuff you're leaving for later: in the Security section, I suggest saying something like some of the issues have been corrected in the memo and others may be handled by implementation and configuration choices. If you don't remove the DoS caused by SIZE (and the size fact, if it's the same there) you should read that as saying "none of the issues reported have been corrected, although some may be handled by implementation or configuration choices." From ftp-wg-owner@hethmon.com Mon Apr 29 06:51: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 GAA21390 for ; Mon, 29 Apr 2002 06:51:43 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429055744-25949-10 ; Mon, 29 Apr 2002 05:57:44 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429055742-64627-9 ; Mon, 29 Apr 2002 05:57:42 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3TAm8D00411 for ; Mon, 29 Apr 2002 06:48:08 -0400 Message-ID: <000d01c1ef6b$51c6b280$0b0d85cd@vr.net> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <003b01c1eec0$ee377d30$9538aed4@loser> 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, 29 Apr 2002 05:57:43 -0500 X-OldDate: Mon, 29 Apr 2002 06:47:49 -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: On new commands Content-Transfer-Encoding: 7bit > In our application (Fastream FTP++ P2P) we have multiple connection > downloads (similar to Download Accelerator/GoZilla) with the help of REST > command. I simply divide the file into segments and then merge the > downloaded parts on the local-side. Yeah. Those are some of the applications causing the DoS complaints. Sure, they're not malicious DoS, but the network operators at your vict..er download site are certainly noticing that you're choking their routers. > I want to implement the same feature for remote part also. I mean multiple > connection uploads. However, on the remote size, there is nothing like a > merge command. There is the command APPE but it only appends a local file to > a remote file. Wouldn't it be nice if we add such a command to FTP? There's some interesting research going on with that. Most of them start with a hacked up FTP daemon. If you want I can root around my bookmarks, but you'll probably find some of it faster if you Google for 'file transfer' and 'satelite'. The US Gov't has a spec which is basically 959 with parallel transfers like you're wanting. > Also, in our application, we have a command called SITE MD5 similar to ones > found in UNIX systems. But in our case, the MD5's are cached with a > background thread. This enables KaZaA/iMesh like P2P functionality with > multiple source-IP/port downloads. However lack of support from other > applications limit the use to within FTP++-to-FTP++ only. As you may have > understood, I propose this command also. I put MD5 (and Unix checksums) into WU-FTPD some time ago, simply because I thought it would be nice to be able to remotely verify signatures. It met with total and complete silence; noone asking how to enable it, no problems with it, nothing. I assume the demand is a very good approximation of zero. I still like the idea, but I expect the users are satisfied enough with the present reliability of downloads that they're not interested in the added step. In specific answer to your question, though, there's no reason the add a new command to support MD5. Adopt MLSx and simply add an MD5 fact to your servers. If you want, write a memo describing the fact. Sorta like the way new Telnet Options get done. From ftp-wg-owner@hethmon.com Mon Apr 29 07:20:24 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 HAA22698 for ; Mon, 29 Apr 2002 07:20:24 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429062618-29449-12 ; Mon, 29 Apr 2002 06:26:18 0000 Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429062609-1040-11 ; Mon, 29 Apr 2002 06:26:16 0000 Received: from loser (212.174.56.43) by mail.san.yahoo.com (6.5.017.1) id 3CBC69E10039566A for ftp-wg@hethmon.com; Mon, 29 Apr 2002 04:17:22 -0700 Message-ID: <000f01c1ef6f$73cba9e0$2b38aed4@loser> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <003b01c1eec0$ee377d30$9538aed4@loser> <000d01c1ef6b$51c6b280$0b0d85cd@vr.net> 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, 29 Apr 2002 06:26:17 -0500 X-OldDate: Mon, 29 Apr 2002 14:17:19 +0300 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Fastream Technologies" To: "FTPEXT Working Group" Subject: Ftp-WG: On new commands Content-Transfer-Encoding: 7bit > > In our application (Fastream FTP++ P2P) we have multiple connection > > downloads (similar to Download Accelerator/GoZilla) with the help of REST > > command. I simply divide the file into segments and then merge the > > downloaded parts on the local-side. > > Yeah. Those are some of the applications causing the DoS complaints. Sure, > they're not malicious DoS, but the network operators at your vict..er > download site are certainly noticing that you're choking their routers. I look into this aspect from the end-users point of view. And we should not forget the fact that router capacity and bandwidth is growing exponentially. So today's DoS, probably will be a small percentage increase in tomorrow's traffic. And standards are designed for future, am I wrong? > > > I want to implement the same feature for remote part also. I mean multiple > > connection uploads. However, on the remote size, there is nothing like a > > merge command. There is the command APPE but it only appends a local file > to > > a remote file. Wouldn't it be nice if we add such a command to FTP? > > There's some interesting research going on with that. Most of them start > with a hacked up FTP daemon. If you want I can root around my bookmarks, > but you'll probably find some of it faster if you Google for 'file transfer' > and 'satelite'. The US Gov't has a spec which is basically 959 with > parallel transfers like you're wanting. Actually a NASA official demanded such feature from me, but since there were a lack of standards, I replied that only for download it is possible. > > > Also, in our application, we have a command called SITE MD5 similar to > ones > > found in UNIX systems. But in our case, the MD5's are cached with a > > background thread. This enables KaZaA/iMesh like P2P functionality with > > multiple source-IP/port downloads. However lack of support from other > > applications limit the use to within FTP++-to-FTP++ only. As you may have > > understood, I propose this command also. > > I put MD5 (and Unix checksums) into WU-FTPD some time ago, simply because I > thought it would be nice to be able to remotely verify signatures. It met > with total and complete silence; noone asking how to enable it, no problems > with it, nothing. I assume the demand is a very good approximation of zero. > I still like the idea, but I expect the users are satisfied enough with the > present reliability of downloads that they're not interested in the added > step. > > In specific answer to your question, though, there's no reason the add a new > command to support MD5. Adopt MLSx and simply add an MD5 fact to your > servers. If you want, write a memo describing the fact. Sorta like the way > new Telnet Options get done. > > Sorry but I am new to MLSx. Which RFC should I be looking for? (I am currently using ICS under BCB for FTP engine) Thanks. From ftp-wg-owner@hethmon.com Mon Apr 29 08:46: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 IAA00401 for ; Mon, 29 Apr 2002 08:46:58 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429075320-15881-9 ; Mon, 29 Apr 2002 07:53:20 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429075318-54134-8 ; Mon, 29 Apr 2002 07:53:19 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA24403; Mon, 29 Apr 2002 22:44:44 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <000801c1ef68$bb6b6760$0b0d85cd@vr.net> References: <000801c1ef68$bb6b6760$0b0d85cd@vr.net> <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <14831.1020084283@mundamutti.cs.mu.OZ.AU> Date: Mon, 29 Apr 2002 07:53:19 -0500 X-OldDate: Mon, 29 Apr 2002 22:44:43 +1000 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: Re: comments on the MLST draft Date: Mon, 29 Apr 2002 05:39:17 -0500 From: "Gregory A Lundberg" Message-ID: <000801c1ef68$bb6b6760$0b0d85cd@vr.net> | On SIZE and MDTM being optional: I don't think they add anything. MLSx has | the info; newer implementations should use MLSx and forget SIZE and MDTM. MDTM doesn't add much, though it can be easier to fetch and parse, but the doc does already recommend using MLST to get the same value MDTM returns. The SIZE cmd and fact return different things though, they're not interchangable. | I didn't look too closely at the facts for MLSx, but I assume the size fact | there is intended to be the actual, stored, size and not the on-the-fly | size. If not, it'll suffer the same problems as SIZE. The size fact is "an approximation to the size of the file" (or words like that), and yes, it's intended that whatever the filesystem reports as the file size can be used (if that's a number in blocks that you then multiply by the block size to get an approximation, and then find out the last block wasn't completely filled later, that's fine -- the unix st_size is definitely fine). transfer modes are irrelevant. This is the one that clients should use when they want the size to display a progress bar, or similar. But it is useless for restart. | To be BRUTALLY honest, I wish SIZE had never been added. The "error on | conversion" solution is the only way I've come up with which maintains the | command as a cheap way to get the file's size without having to read through | LIST output, and stop the DoS complaints. You can certainly do that, I think the spec makes it OK to refuse to calculate the size of a file that you don't like - set a conf file option, files bigger than N and SIZE doesn't work (perhaps except in image mode). | On why I say REST can appear anywhere: What I was trying to describe was the | way existing clients misuse the command in an attempt to see if it _might_ | work today. Yes, 959 says it must be immediately followed with a transfer | command. But clients send it at the top of the session, when they're doing | SYST and such, and it's typically a command or two away from the data | transfer. Yes, it often is, but I don't think we ought to encourage that. In practice, lots of commands are pretty obviously going to have no effect, but I wouldn't like to constrain implementations too much. The doc is (I think) fairly clear that it is pretty undefined to do REST other than just before a transfer. | On the stuff you're leaving for later: Yes, of course. kre From ftp-wg-owner@hethmon.com Mon Apr 29 08:48:41 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 IAA00604 for ; Mon, 29 Apr 2002 08:48:40 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429075513-20415-13 ; Mon, 29 Apr 2002 07:55:13 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429075511-58629-12 ; Mon, 29 Apr 2002 07:55:11 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA02607; Mon, 29 Apr 2002 22:46:38 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <000f01c1ef6f$73cba9e0$2b38aed4@loser> References: <000f01c1ef6f$73cba9e0$2b38aed4@loser> <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <003b01c1eec0$ee377d30$9538aed4@loser> <000d01c1ef6b$51c6b280$0b0d85cd@vr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <14865.1020084397@mundamutti.cs.mu.OZ.AU> Date: Mon, 29 Apr 2002 07:55:12 -0500 X-OldDate: Mon, 29 Apr 2002 22:46:37 +1000 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: On new commands Date: Mon, 29 Apr 2002 06:26:17 -0500 From: "Fastream Technologies" Message-ID: <000f01c1ef6f$73cba9e0$2b38aed4@loser> | Sorry but I am new to MLSx. Which RFC should I be looking for? (I am | currently using ICS under BCB for FTP engine) It isn't yet an RFC, we're patiently waiting for the IESG to tell us that it will be published. See draft-ietf-ftpext-mlst-15.txt in the I-D directories. It is (aside from the different boilerplates etc) possibly identical to what will appear in an RFC (unless some discussion here causes a new one to emerge). kre From ftp-wg-owner@hethmon.com Mon Apr 29 19:36: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 TAA23294 for ; Mon, 29 Apr 2002 19:36:05 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429184249-59013-9 ; Mon, 29 Apr 2002 18:42:49 0000 Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429184247-33877-8 ; Mon, 29 Apr 2002 18:42:47 0000 Message-ID: <20020429233415.98929.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Mon, 29 Apr 2002 16:34:15 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Apr 2002 18:42:48 -0500 X-OldDate: Mon, 29 Apr 2002 16:34:15 -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 for NUL CR LF etc.? > > It just bugs me > > that we can support any file, directory > > or path name EXCEPT those > > which include [Unicode x0..1F] Bugs me too. Do we see enough divergence in reasonable interpretation here to say mlst-16 should include a concrete example, one command of which has a utf-8-name pathname that contains Ctrl+M CR, Ctrl+J LF, Ctrl+@ NUL, and Ctrl+S XOFF? > > unambiguous on paper ... no? > > > > For example, [an Ftp client] > > could send the six byte > > command "STOR \r" as the nine bytes > > "STOR \r\0\r\n" to create a file > > named by the one byte string > > containing only x0D CR. ... > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Wed 4/24/2002 11:33 PM ... > If you want to put a CR in a file name, > ... exactly as ... suggested. > If you happen to be talking to a broken > implementation, then you might not be able > to put a CR in a file name > - the answer is to fix the implementation, > not to change the way FTP is defined. Let's suppose in real life Ftp is normally Not robust enough to handle x0A LF, x0D CR, x00 NUL, x13 Ctrl+S XOFF, x11 Ctrl+Q XON, and the rest of UTF-8 codes x00..1F ... Should we then add protocol to help more compliant clients and servers recognise each other? We don't want servers and clients just volunteering pathnames as arbitrary as mlst-15 allows in lines of the LIST NLST MLST responses and as CWD RETR STOR MKD RNTO arguments, do we? Yours in breathtaking (refreshing?) ignorance, Pat LaVarre __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From ftp-wg-owner@hethmon.com Mon Apr 29 23:34:23 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 XAA28947 for ; Mon, 29 Apr 2002 23:34:22 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429224024-27075-8 ; Mon, 29 Apr 2002 22:40:24 0000 Received: from CHINS (163.25.99.33 [163.25.99.33]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429223809-36544-8 ; Mon, 29 Apr 2002 22:40:21 0000 Received: from pchome by yahoo.com with SMTP id bQOclVLBHIEbhlDGINc4Dy2VVHOFb; Tue, 30 Apr 2002 11:30:48 +0800 Message-ID: X-Mailer: RRiqS6tiRW1siXTYt Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Date: Mon, 29 Apr 2002 22:40:22 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: 長庚企業管理研究所 To: Thanks Subject: Ftp-WG: =?big5?Q?=A5u=ADn=A4=BB=A4=C0=C4=C1=B0e=B1z=AA=F7=A5=DB=B0=F3=C2=A7=A8=F7!?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ietf.org id XAA28947 各位社會的先進打擾了! 我是長庚企研所的研究生,透過網路mail搜尋軟體,有幸得知貴公司(或個人)的mail,，由於我的研究是有關B2B網路電子市集的消費者行為,問卷對象是企業用戶在問卷蒐集上並不容易 因此想先以有工作經驗者作為前測。本問卷採用實驗情境的方式 僅有27個量表 大概會花您六分鐘的時間。在問卷確實回收且為有效樣本後，本人將以電子郵件的方式回覆您並郵寄100元的金石堂禮券以感謝您抽空填完本人的問卷。 請點選該網址： 實驗情境二 http://home.pchome.com.tw/society/nikky520/S2.htm From ftp-wg-owner@hethmon.com Tue Apr 30 00:20: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 AAA29547 for ; Tue, 30 Apr 2002 00:20:43 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429232732-31729-9 ; Mon, 29 Apr 2002 23:27:32 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429232729-4933-8 ; Mon, 29 Apr 2002 23:27:30 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3U4HrD12772 for ; Tue, 30 Apr 2002 00:17:53 -0400 Message-ID: <000a01c1effd$fee57720$0b0d85cd@vr.net> References: <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <003b01c1eec0$ee377d30$9538aed4@loser> <000d01c1ef6b$51c6b280$0b0d85cd@vr.net> <000f01c1ef6f$73cba9e0$2b38aed4@loser> 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, 29 Apr 2002 23:27:31 -0500 X-OldDate: Tue, 30 Apr 2002 00:17:46 -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: On new commands Content-Transfer-Encoding: 7bit > Actually a NASA official demanded such feature from me, but since there were > a lack of standards, I replied that only for download it is possible. NASA should have given you the spec. It's THEIR birds it's being used on. :P > Sorry but I am new to MLSx. Which RFC should I be looking for? (I am > currently using ICS under BCB for FTP engine) I see Elz has answered this one. If you want to come up to speed, faqs.org has all the RFCs organized, and www.wu-ftpd.org has them as well, including the drafts and some other stuff, but I'm biased since I designed that page. From ftp-wg-owner@hethmon.com Tue Apr 30 00:24:07 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 AAA29613 for ; Tue, 30 Apr 2002 00:24:06 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429233057-30532-12 ; Mon, 29 Apr 2002 23:30:58 0000 Received: from mail.vr.net (mail.vr.net [205.133.13.8]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020429233054-3703-12 ; Mon, 29 Apr 2002 23:30:56 0000 Received: from athena (athena.vr.net [205.133.13.11]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g3U4LAD13018 for ; Tue, 30 Apr 2002 00:21:11 -0400 Message-ID: <000d01c1effe$753dca80$0b0d85cd@vr.net> References: <000801c1ef68$bb6b6760$0b0d85cd@vr.net> <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <14831.1020084283@mundamutti.cs.mu.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, 29 Apr 2002 23:30:57 -0500 X-OldDate: Tue, 30 Apr 2002 00:21:05 -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: Re: comments on the MLST draft Content-Transfer-Encoding: 7bit > Yes, it often is, but I don't think we ought to encourage that. > In practice, lots of commands are pretty obviously going to have no > effect, but I wouldn't like to constrain implementations too much. > The doc is (I think) fairly clear that it is pretty undefined to do > REST other than just before a transfer. I guess my only real point there, then, is the 300 reply. that indicates the next command MUST be a transfer command. 959 already says must, so the 300 is appropriate, but actually specifying 300 breaks all those existing implementations and .. if you can't tell .. I'm real big on trying to live with the mess created by existing implementations. From ftp-wg-owner@hethmon.com Tue Apr 30 03:17: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 DAA09761 for ; Tue, 30 Apr 2002 03:17:50 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020430022434-22116-9 ; Tue, 30 Apr 2002 02:24:34 0000 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020430022431-60423-8 ; Tue, 30 Apr 2002 02:24:32 0000 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id HA14332; Tue, 30 Apr 2002 17:15:57 +1000 (from kre@munnari.OZ.AU) In-Reply-To: <000d01c1effe$753dca80$0b0d85cd@vr.net> References: <000d01c1effe$753dca80$0b0d85cd@vr.net> <000801c1ef68$bb6b6760$0b0d85cd@vr.net> <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <14831.1020084283@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <22277.1020150957@mundamutti.cs.mu.OZ.AU> Date: Tue, 30 Apr 2002 02:24:33 -0500 X-OldDate: Tue, 30 Apr 2002 17:15:57 +1000 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: Re: comments on the MLST draft Date: Mon, 29 Apr 2002 23:30:57 -0500 From: "Gregory A Lundberg" Message-ID: <000d01c1effe$753dca80$0b0d85cd@vr.net> | 300 is appropriate, but actually specifying 300 breaks all those existing | implementations and .. Yes, that was what I thought - for this, the intent was just to (finally) document what actually exists, and has done for a long time. The WG spent essentially no time trying to think of ways that restart could be "fixed" or improved, or altered at all - at this late stage, I doubt that there is much real interest in doing that, here anyway. kre From ftp-wg-owner@hethmon.com Tue Apr 30 08:46:13 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 IAA17655 for ; Tue, 30 Apr 2002 08:46:12 -0400 (EDT) Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020430075254-39053-12 ; Tue, 30 Apr 2002 07:52:54 0000 Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mail.hethmon.com (Hethmon Smtpd Perseus) id 20020430075252-9735-11 ; Tue, 30 Apr 2002 07:52:52 0000 Received: from chirho.texis.com (adsl-65-67-61-15.dsl.austtx.swbell.net [65.67.61.15]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3UCiKx49858 for ; Tue, 30 Apr 2002 08:44:20 -0400 Message-Id: <4.3.2.7.2.20020430074547.024267b8@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <22277.1020150957@mundamutti.cs.mu.OZ.AU> References: <000d01c1effe$753dca80$0b0d85cd@vr.net> <000d01c1effe$753dca80$0b0d85cd@vr.net> <000801c1ef68$bb6b6760$0b0d85cd@vr.net> <000f01c1ebc5$0ba79020$0b0d85cd@vr.net> <20020408213339-32186-8@mail.hethmon.com> <6671.1020001703@mundamutti.cs.mu.OZ.AU> <14831.1020084283@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 30 Apr 2002 07:52:53 -0500 X-OldDate: Tue, 30 Apr 2002 07:48:35 -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: comments on the MLST draft At 02:24 AM 4/30/2002, you wrote: > Date: Mon, 29 Apr 2002 23:30:57 -0500 > From: "Gregory A Lundberg" > Message-ID: <000d01c1effe$753dca80$0b0d85cd@vr.net> > > | 300 is appropriate, but actually specifying 300 breaks all those existing > | implementations and .. > >Yes, that was what I thought - for this, the intent was just to (finally) >document what actually exists, and has done for a long time. The WG spent >essentially no time trying to think of ways that restart could be "fixed" >or improved, or altered at all - at this late stage, I doubt that there >is much real interest in doing that, here anyway. There's so many working implementations out there, in client and in server, that to define a new protocol element for resuming that was fundamentally incompatible with the existing implementations would have likely led to the same situation that we have with FTP URLs - the RFCs say one thing, and the implementations completely ignore it. RFCs have a long and cherished history of documenting that which has been implemented, and found to work. Occasionally they document only that which has been found to work "well enough". Changing the behaviour of REST at this point would be a waste of time - we'd end up with an RFC that muddied the water, rather than cleared it. 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.