From ftp-wg-owner@hethmon.com Fri Jan 4 03:49:18 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 DAA29399 for ; Fri, 4 Jan 2002 03:49:18 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020104035417-1200-9 ; Fri, 04 Jan 2002 03:54:17 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020104035410-41443-8 ; Fri, 04 Jan 2002 03:54:13 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g048l8S00991 for ; Fri, 4 Jan 2002 15:47:08 +0700 (ICT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <989.1010134028@brandenburg.cs.mu.OZ.AU> Date: Fri, 4 Jan 2002 03:54:15 -0500 X-OldDate: Fri, 04 Jan 2002 15:47:08 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: MLST draft -14 submitted Now that the holiday period is over (and I-Ds should be being processed again), I have submitted what should be the final version of our draft to the I-D system. This has the changes as discussed on the list last month, in response to the IETF last call. When it appears, please take a look, and object if there's some kind of problem suddenly appeared. Otherwise, I will be asking our chair, Paul, to request the IESG to progress this doc sometime near the end of next week. kre From ftp-wg-owner@hethmon.com Tue Jan 8 19:50: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 TAA15226 for ; Tue, 8 Jan 2002 19:50:06 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020108195506-29852-9 ; Tue, 08 Jan 2002 19:55:06 -0500 Received: from web21101.mail.yahoo.com ([216.136.227.103] [216.136.227.103]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020108195501-35626-8 ; Tue, 08 Jan 2002 19:55:02 -0500 Message-ID: <20020109004720.2739.qmail@web21101.mail.yahoo.com> Received: from [147.178.1.2] by web21101.mail.yahoo.com via HTTP; Tue, 08 Jan 2002 16:47:20 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 8 Jan 2002 19:55:03 -0500 X-OldDate: Tue, 8 Jan 2002 16:47:20 -0800 (PST) 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: receive "\n" as NOT obvious as send "\r\xFF"? Should ftpext-mlst also emphasise that excessively liberal legacy hosts accept \n in place of \r\n? I wonder because I see that rfc2640 [International Ftp] mentions that inadequately conservative legacy hosts forget to write \r\0 in place of \r as rfc854 [Telnet] requires, and ftpext-mlst-13 mentions that inadequately conservative legacy hosts forget to write \xFF\xFF in place of \xFF . I'm thinking, before including the rfc2640 UTF8 option in the lines of a 211 reply to FEAT, people upgrading an FtpServer must take care to allow \n to appear anywhere within a command, even as the last byte of a packet. Crawling out on the web, I think I see FtpServer's (e.g. ftp.apple.com ftp.sun.com members.aol.com) commonly accept \n anywhere in the packets of a command as meaning \r\n. Some FtpServer's (e.g. ftp.microsoft.com) then toss the rest of the packet. All of these reply 500 [Unknown Ftp Verb] to the command FEAT. > ... \xFF\xFF in place of \xFF ... My own Ftp code was broken here til I read ftpext-mlst-13: I was passing thru xFF unchanged from the local file system. Raw newbie that I am, I had gone wrong in my first readings of rfc854 [Telnet]. Thanks in advance, hope this helps. Pat LaVarre P.S. Hi. I'm new here. Please tell me offline if I should have posted this query elsewhere? P.P.S. I arrived here by way of news:comp.protocols.tcp-ip mention of which Google connects to which in turn mentions . P.P.P.S. Reentering plain text Url's via copy-paste lets me get from ftpext-charter.html to , but then my .zip reader choked over the last few files of , so then I came here. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Fri Jan 11 08:57: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 IAA14884 for ; Fri, 11 Jan 2002 08:57:22 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020111090243-59639-9 ; Fri, 11 Jan 2002 09:02:43 -0500 Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020111090239-40954-8 ; Fri, 11 Jan 2002 09:02:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14480; Fri, 11 Jan 2002 08:54:51 -0500 (EST) Message-Id: <200201111354.IAA14480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Fri, 11 Jan 2002 09:02:41 -0500 X-OldDate: Fri, 11 Jan 2002 08:54:50 -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-14.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-14.txt Pages : 56 Date : 10-Jan-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-14.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-14.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-14.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: <20020110150237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ftpext-mlst-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ftpext-mlst-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150237.I-D@ietf.org> --OtherAccess-- --NextPart-- From ftp-wg-owner@hethmon.com Sat Jan 12 08:57: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 IAA20575 for ; Sat, 12 Jan 2002 08:57:19 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020112090259-18283-9 ; Sat, 12 Jan 2002 09:02:59 -0500 Received: from web21102.mail.yahoo.com ([216.136.227.104] [216.136.227.104]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020112090254-33687-8 ; Sat, 12 Jan 2002 09:02:54 -0500 Message-ID: <20020112135511.45008.qmail@web21102.mail.yahoo.com> Received: from [147.178.1.2] by web21102.mail.yahoo.com via HTTP; Sat, 12 Jan 2002 05:55:11 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Jan 2002 09:02:56 -0500 X-OldDate: Sat, 12 Jan 2002 05:55:11 -0800 (PST) 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: to mlst-14 from mlst-13 Is there a Url I should visit to see a change history of the draft-ietf-ftpext-mlst? > - draft-ietf-ftpext-mlst-13.txt > - Expiration Date: November 2001 ... > + draft-ietf-ftpext-mlst-14.txt > + Expiration Date: July 2002 Me, the substantive diff's I see to mlst-14 from mlst-13 are as follows: > > 3. File Modification Time (MDTM) > > 3.1 Syntax ... > - ... Attempts to query the modification time > - of files that are unable to be retrieved > - generate undefined responses. ... > + ... Attempts to query the modification time > + of files that exist but are unable to be retrieved > + may generate an error-response, > + or can result in a positive response > + carrying a time-val with an unspecified value, > + the choice being made by the server-PI. Less undefined now, thank you. > > 3. File Modification Time (MDTM) > > 3.1 Syntax ... > + Note that when the 213 response is issued, > + that is, when there is no error, > + the format MUST be exactly as specified. > + Multi-line responses are not permitted. ... > > 4 File SIZE > > 4.1 Syntax ... > + Note that when the 213 response is issued, > + that is, when there is no error, > + the format MUST be exactly as specified. > + Multi-line responses are not permitted. Ouch. I wonder how often in practice FtpClient's conservatively refuse to accept multi-line responses, thus quietly abandoning the rfc959 "recommend" re "spontaneous replies": "such information be queued in the server-PI and delivered to the user-PI in the next reply (possibly making it a multi-line reply)." > > Abstract ... > - ... [the internal reference to] US-ASCII[1] ... ... > - ... [the] consenting clients and servers > - [mention of feature negotiation more symmetric > - than rfc2389 [Ftp Feature Negotiation]] ... ... > - ... [the less implicit deprecation of the] > - LIST command ... ... > - [the] much implemented ... > - [mention of the popularity of REST in MODE S] ... > > 2.2 Pathnames > > the Telnet IAC character ... > > MUST be correctly escaped ... I've as yet found no discussion except my own 8 Jan post re how commonly FtpServer's have been liberally accepting \n as meaning \r\n. > > 2.2 Pathnames > > Note that ASCII is a subset of UTF-8. > + See also [1]. > > 8. Impact On Other FTP Commands > - US-ASCII > + US-ASCII[1] > > [1] Coded Character Set--7-bit American > > Standard Code for Information Interchange, > > ANSI X3.4-1986. > > Acknowledgments > > + Andrew Main > Is there a Url I should visit to see > a change history of the draft-ietf-ftpext-mlst? I see the link is now broken, unless I change to "14" from "13". Thanks in advance. Pat LaVarre P.S. > Me, the substantive diff's I see ... I mean to say, before comparing the texts, ... I gleefully stripped page numbers, headers, trailers. I reflowed the table of contents and I sorted the table of command verbs in "8. Impact On Other FTP Commands". I compressed runs of blank lines to single blank lines. I changed "labeled" to "labelled", "modeled" to "modelled". I disregarded addition/removal of single blank lines (which recklessly I attribute to me having incompletely stripped pagination artifacts.) __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Mon Jan 14 04:00:19 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00125 for ; Mon, 14 Jan 2002 04:00:18 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114040552-10990-9 ; Mon, 14 Jan 2002 04:05:52 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114040535-11580-8 ; Mon, 14 Jan 2002 04:05:49 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0E90I105128 for ; Mon, 14 Jan 2002 16:00:20 +0700 (ICT) In-Reply-To: <20020112135511.45008.qmail@web21102.mail.yahoo.com> References: <20020112135511.45008.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <5126.1010998818@brandenburg.cs.mu.OZ.AU> Date: Mon, 14 Jan 2002 04:05:49 -0500 X-OldDate: Mon, 14 Jan 2002 16:00:18 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: to mlst-14 from mlst-13 Date: Sat, 12 Jan 2002 09:02:56 -0500 From: Pat LaVarre Message-ID: <20020112135511.45008.qmail@web21102.mail.yahoo.com> | Is there a Url I should visit to see a change history | of the draft-ietf-ftpext-mlst? Other than the mailing list archives, no, I don't think so. But all of the versions of the draft are still at ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-NN.txt.Z if you want to repeat your diffs over all versions of the drafts. Go back far enough and you'd get some fairly large changes (you also don't need to go back too far to get the "summary of what changed in this draft" section in the abstract - that was deleted when the document was considered to be done - knowing what changed between version N-1 and version N of the I-D which led up to an RFC wouldn't be useful...) Note the ".Z", on munnari.oz.au they're compressed (unix LZ compress). (All the other current drafts, and a bunch of other historical versions, though certainly not all, are also there - so if you ask for a directory listing, be expected for a long list). | > + Note that when the 213 response is issued, | > + that is, when there is no error, | > + the format MUST be exactly as specified. | > + Multi-line responses are not permitted. | | Ouch. Why? The formats for MDTM and SIZE replies are fixed. Multi-line replies make no sense there. It was just a bug (pointed out during the last call) that this wasn't made explicit before. I can't imagine a server ever issuing a multi-line reply to one of those commands, there's no reason (generating multi-line replies requires effort). | I wonder how often in practice FtpClient's | conservatively refuse to accept multi-line responses, For those two commands, I would expect most, though the client should still do the right thing when processing the reply - if it happened to look like a multi-line reply, it should either be parsed that way (at least the entire reply read) or the connection dropped due to the protocol error at the server. | thus quietly abandoning the rfc959 "recommend" re | "spontaneous replies": "such information be queued in | the server-PI and delivered to the user-PI in the next | reply (possibly making it a multi-line reply)." I'm not sure what you're getting at there? It is impossible to confuse a spontaneous message with a multi-line reply if you're following the specs. A client which received the first line of a multi-line reply and accepted that as the reply, keeping the remaining lines for some other purpose would be so horribly broken as to be useless. | I've as yet found no discussion except my own 8 Jan | post re how commonly FtpServer's | have been liberally accepting \n as meaning \r\n. Probably because there's no-one who feels to have enough knowledge to comment. Only someone who had done a survey of ftp implementations could have done that ... In any case, nothing about that would find a place in this doc - it isn't a "ftp implementors tricks of the trade" - it is sometimes appropriate to restate the rules of the protocol, just so everyone is clear, it wouldn't be appropriate to explain when and why it is sometimes necessary to go beyond the protocol (though I suspect that accepting just \n is more of just a lazy implementation technique on unix servers) | I see the link | | is now broken, unless I change to "14" from "13". Yes, the ietf I-D directory (and most of the mirrors) delete old versions of the draft as soon as the new one is placed there. | I mean to say, before comparing the texts, ... | I gleefully stripped page numbers, headers, trailers. Yes, that's necessary... | I reflowed the table of contents and I sorted the | table of command verbs in "8. Impact On Other FTP | Commands". That would have been, because of my "paper saving device" ... | I compressed runs of blank lines to single blank | lines. That too. | I changed "labeled" to "labelled", "modeled" to "modelled". That's a side effect of my spell checker, and my indecision about whether I am writing this doc in English or American - and some level of oscillation between the two... | I disregarded addition/removal of single blank lines | (which recklessly I attribute to me having | incompletely stripped pagination artifacts.) Not necessarily, some of that kind of change can simply be an artifact of the formatter, and how and where it decides to put page breaks. kre From ftp-wg-owner@hethmon.com Mon Jan 14 11:42: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 LAA06155 for ; Mon, 14 Jan 2002 11:42:22 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114114803-22011-9 ; Mon, 14 Jan 2002 11:48:03 -0500 Received: from mail15b.boca15-verio.com ([208.55.91.59] [208.55.91.59]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114114758-20720-8 ; Mon, 14 Jan 2002 11:47:58 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 12874108 for ; Mon, 14 Jan 2002 11:38:54 -0500 (EST) Message-Id: <4.3.2.7.2.20020114100239.02084ea8@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <5126.1010998818@brandenburg.cs.mu.OZ.AU> References: <20020112135511.45008.qmail@web21102.mail.yahoo.com> <20020112135511.45008.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Mon, 14 Jan 2002 11:48:00 -0500 X-OldDate: Mon, 14 Jan 2002 10:23:38 -0600 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: to mlst-14 from mlst-13 At 03:05 AM 1/14/2002, Robert Elz wrote: > | > + Note that when the 213 response is issued, > | > + that is, when there is no error, > | > + the format MUST be exactly as specified. > | > + Multi-line responses are not permitted. > | > | Ouch. > >Why? The formats for MDTM and SIZE replies are fixed. Multi-line >replies make no sense there. Pat's been taking a very strict approach to reading RFCs and similar documents - as far as I've seen from his Usenet responses, he expects the RFC to completely document all possible scenarios of operation. There are a few commands in FTP whose responses need to be parsed at the text level, as well as at the numeric code. To most of us, it is obvious that these commands have to be responded to as written in the RFC, with no alteration to the text. To Pat, apparently, there is no reason why these shouldn't be multiple line responses. I'm not quite sure how he's expecting such a multiple line response to work for SIZE or MDTM (or PWD, for that matter, or PASV, both of which require a single-line fixed response). One possibility that does suggest itself is that of someone sending "MDTM *" or "SIZE *" to get a listing of several files - however, it's clear that such a command would be redundant. With the MLST draft, an MLST command would provide an unambiguous listing of each of these quantities on such a wild-card argument. 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 Mon Jan 14 19:51: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 TAA27679 for ; Mon, 14 Jan 2002 19:51:07 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114195639-60221-9 ; Mon, 14 Jan 2002 19:56:39 -0500 Received: from web21101.mail.yahoo.com ([216.136.227.103] [216.136.227.103]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114195634-44782-8 ; Mon, 14 Jan 2002 19:56:35 -0500 Message-ID: <20020115004850.63299.qmail@web21101.mail.yahoo.com> Received: from [147.178.1.2] by web21101.mail.yahoo.com via HTTP; Mon, 14 Jan 2002 16:48:50 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 19:56:36 -0500 X-OldDate: Mon, 14 Jan 2002 16:48:50 -0800 (PST) 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: receive "\n" as NOT obvious as send "\r\xFF"? (subject was: Ftp-WG: to mlst-14 from mlst-13) > > re how commonly FtpServer's > > have been liberally accepting \n as meaning \r\n. ... > kre@munnari.oz.au 01/14/02 02:05AM ... > - it is sometimes appropriate to restate > the rules of the protocol, just so everyone is clear, > it wouldn't be appropriate to explain when and why > it is sometimes necessary to go beyond the protocol Understood, thank you for making this premise explicit. > > re how commonly FtpServer's > > have been liberally accepting \n as meaning \r\n. ... > nothing about that would find a place in this doc Could you walk me thru this yet again but more slowly? I think I must be missing something cultural, newbie that I am. If it was Good for rfc2640 [International Ftp] to mention inadequately conservative Ftp senders neglect to write \r\0 in place of \r ... ... if now it is Good for mlst-14 [More Ftp] to mention inadequately conservative Ftp senders neglect to write \xFF\xFF in place of \xFF ... ... why then would it not be Good for mlst-15 to mention excessively liberal Ftp receivers read \r\n in place of \n? Without such an explicit mention in mlst-15, should we anticipate that FtpServer's will begin to include UTF8 among the lines of their 211 reply to FEAT, thus claiming to have implemented rfc2640, without actually having foresworn this popular example of excessive liberality? The existence of such FtpServer's will in turn slow the full adoption of the rfc2640 [International Ftp] provisions for the (Ascii? binary Image?) exchange of pathnames arbitrary enough to include \r and \n? FtpClient's excessively liberal in this way could cause more trouble, since rfc2389 [Ftp Feature Negotiation] defines no protocol for the client to indicate in return what rfc's it has tried to implement (though I see the MS IE FtpClient has pioneered "opts utf8 on"). > ... enough knowledge to comment. > Only someone who had done a survey > of ftp implementations ... Can anyone here easily point me to an anonymous FtpServer that does include UTF8 among the options of its 211 reply to FEAT? My barest beginning of an Ftp survey as yet includes no such FtpServer: I tried only ftp.apple.com, ftp.microsoft.com, ftp.sun.com, and members.aol.com. For FtpClient's as yet I've looked at no more than MS IE. > > mlst-14 ... > isn't a "ftp implementors tricks of the trade" ... > (though I suspect that accepting just \n > is more of just a lazy implementation > technique on unix servers) By contrast, rfc1123 [Requirements] actually is an rfc meant to relate those "tricks of the trade" we wish everyone knew? Thanks again in advance. Pat LaVarre > ppaatt@aol.com > p_lavarre@yahoo.com P.S. Sorry about so many email addresses. I now think this list and all my mail clients get along reasonably well provided I remember to not only to direct reply-to p.lavarre@ieee.org but I also explicitly cc p.lavarre@ieee.org when I post from p_lavarre@yahoo.com. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Mon Jan 14 19:56:10 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 TAA27800 for ; Mon, 14 Jan 2002 19:56:10 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114200147-1617-13 ; Mon, 14 Jan 2002 20:01:47 -0500 Received: from web21103.mail.yahoo.com ([216.136.227.105] [216.136.227.105]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020114200144-48284-13 ; Mon, 14 Jan 2002 20:01:44 -0500 Message-ID: <20020115005359.70807.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Mon, 14 Jan 2002 16:53:59 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 20:01:45 -0500 X-OldDate: Mon, 14 Jan 2002 16:53:59 -0800 (PST) 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: multi-line responses acceptable when? (subject was: Ftp-WG: to mlst-14 from mlst-13) (you should Not also see this message from ppaatt@aol.com - sorry if you do) > > draft-ietf-ftpext-mlst-14.txt > > ... thus quietly abandoning the rfc959 > > "recommend" re "spontaneous replies": > I'm not sure what you're getting at there? Ouch, sorry I was unclear. I meant "spontaneous replies" only in the carefully formal fashion suggested by rfc959. Quoting more fully now: > > > http://www.ietf.org/rfc/rfc959.txt .. > > > 5.4. SEQUENCING OF COMMANDS AND REPLIES .. > > > Spontaneous Replies > > > > > > Sometimes "the system" spontaneously has a > > > message to be sent to a user (usually all > > > users). For example, "System going down > > > in 15 minutes". There is no provision in FTP > > > for such spontaneous information to be sent > > > from the server to the user. .. > > > It is recommended that such information be queued > > > in the server-PI and delivered to the user-PI > > > in the next reply (possibly making it > > > a multi-line reply). In that context ... > draft-ietf-ftpext-mlst-14.txt .. > Note that when the 213 response is issued, > that is, when there is no error, > the format MUST be exactly as specified. > Multi-line responses are not permitted. These specs are flatly in conflict ... except that rfc's differ from commercial products in that she who ships _last_ wins. No? How about a concrete example. I think mlst-14 is telling me that its example of: C> MDTM A S> 213 19980615100045.014 could never be: C> MDTM A S> 213-Please QUIT within five minutes. S> 213 19980615100045.014 nor: C> MDTM A S> 213-19980615100045.014 S> 213 Please QUIT within five minutes. Or have I misunderstood either/both rfc959 and mlst-14? > Or have I misunderstood ... As yet, raw newbie though I am, I think an FtpClient properly liberal in what it accepts would parse at most the reply texts: 125/150 to STOU, 213 to MDTM/SIZE, 227 to PASV, 229 to EPSV, 257 to PWD/MKD. Accordingly, as yet, I think an FtpServer properly conservative in what it sends would keep a "spontaneous reply" secretly queued until the FtpClient sent a command other than EPSV MDTM MKD PASV PWD SIZE STOU. I'd like to say an properly conservative FtpServer would _never_ forward "spontaneous replies" ... except I know personally I'd appreciate the "please QUIT within five minutes" info, whenever I am talking Ftp interactively. Thanks again in advance. Pat LaVarre P.S. > > ... Go back far enough > ... the "summary of what changed in this draft" > ... directory listing ... long ... Helpful, thank you. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Tue Jan 15 12:17: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 MAA05841 for ; Tue, 15 Jan 2002 12:17:12 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115122252-65062-9 ; Tue, 15 Jan 2002 12:22:52 -0500 Received: from mail15b.boca15-verio.com ([208.55.91.59] [208.55.91.59]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115122247-53950-8 ; Tue, 15 Jan 2002 12:22:48 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 03480956 for ; Tue, 15 Jan 2002 12:13:44 -0500 (EST) Message-Id: <4.3.2.7.2.20020115102438.01c32628@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <20020115004850.63299.qmail@web21101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Tue, 15 Jan 2002 12:22:49 -0500 X-OldDate: Tue, 15 Jan 2002 10:58:30 -0600 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: receive "\n" as NOT obvious as send "\r\xFF"? At 06:56 PM 1/14/2002, you wrote: > > > re how commonly FtpServer's > > > have been liberally accepting \n as meaning \r\n. >... > > nothing about that would find a place in this doc > >Could you walk me thru this yet again but more slowly? > I think I must be missing something cultural, newbie >that I am. > >If it was Good for rfc2640 [International Ftp] to >mention inadequately conservative Ftp senders neglect >to write \r\0 in place of \r ... > >... if now it is Good for mlst-14 [More Ftp] to >mention inadequately conservative Ftp senders neglect >to write \xFF\xFF in place of \xFF ... > >... why then would it not be Good for mlst-15 to >mention excessively liberal Ftp receivers read \r\n in >place of \n? Perhaps because the last is a deliberate and conscious design decision to do something not specified in the docs, whereas the former are unconsciously forgetting to do something that _is_ specified in the docs. The idea is that someone making a conscious decision to extend their implementation beyond the RFCs is presumed to be aware of what they are doing - the RFCs are _not_ about hand-holding. However, if implementations consistently fail to meet the required standards, then in updated documents, it's worthwhile reminding implementors of a requirement that was obviously so subtle as to pass them by completely. >Without such an explicit mention in mlst-15, should we >anticipate that FtpServer's will begin to include UTF8 >among the lines of their 211 reply to FEAT, thus >claiming to have implemented rfc2640, without actually >having foresworn this popular example of excessive >liberality? We should always anticipate that other programmers will screw up. If we're really clever, we'll anticipate that we will screw up :-) Documenting this fact in an RFC is hardly necessary, nor should it be appropriate to explain various ways we might expect an implementor to screw things up. The RFC is there to document what is correct, not what is incorrect - that is implied by its exclusion. >The existence of such FtpServer's will in turn slow >the full adoption of the rfc2640 [International Ftp] >provisions for the (Ascii? binary Image?) exchange of >pathnames arbitrary enough to include \r and \n? Or the existence of RFC 2640 will slow the adoption of FTP servers that don't offer good compliance with the RFC - note that I say "good", not "full", since there are frequent cases where not being fully compliant is yet "good enough" for normal operation. Remember our discussion about how broken IIS is? Yet it works "well enough" that there are large numbers of sites using it in day-to-day usage. >FtpClient's excessively liberal in this way could >cause more trouble, since rfc2389 [Ftp Feature >Negotiation] defines no protocol for the client to >indicate in return what rfc's it has tried to >implement (though I see the MS IE FtpClient has >pioneered "opts utf8 on"). An earlier draft may have suggested an OPTS UTF8 command, only to be superceded later - check the archives of this mailing list for discussion on that draft. Unfortunately, it's not something I'm very familiar with at the moment. >By contrast, rfc1123 [Requirements] actually is an rfc >meant to relate those "tricks of the trade" we wish >everyone knew? For the most part, RFC1123 (especially the FTP section) is a clarification of the RFC. Where points are contradictory in 959, 1123 attempts to explain them. Where there have been widespread poor implementations (for instance, the message-boundary statement), 1123 clarifies and attempts to correct these. There are many things that we wish everyone knew, and most of these are discovered as you learn TCP/IP application development, if you work your way through a good book. However, if you learn through a bad book, or worse, merely by reading RFCs, there's a lot you'll miss. The RFCs are not the whole of how to program, they are merely the technical specifications; learning to program TCP/IP applications by reading the RFCs is a bit like learning to write in English by reading a dictionary. 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 Tue Jan 15 17:18:56 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14931 for ; Tue, 15 Jan 2002 17:18:56 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115172432-60206-9 ; Tue, 15 Jan 2002 17:24:32 -0500 Received: from web21101.mail.yahoo.com ([216.136.227.103] [216.136.227.103]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115172428-11512-8 ; Tue, 15 Jan 2002 17:24:28 -0500 Message-ID: <20020115221643.68889.qmail@web21101.mail.yahoo.com> Received: from [147.178.1.2] by web21101.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 14:16:43 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jan 2002 17:24:30 -0500 X-OldDate: Tue, 15 Jan 2002 14:16:43 -0800 (PST) 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: receive "\n" as NOT obvious as send "\r\xFF"? > > I must be missing something cultural ... ... > > ... why ... would it not be Good for mlst-15 to > > mention excessively liberal Ftp receivers > > read \r\n in place of \n? ... > alun@texis.com 01/15/02 10:22AM ... > ... a deliberate and conscious design decision > to do something not specified in the docs, > whereas the [other] are unconsciously forgetting > to do something that _is_ specified in the docs. Maybe slowly I progress, thank you. Let me echo back the distinction I hear you're making, you tell me how wrong I got it? rfc2640 [International Ftp] and mlst-14 [More Ftp] merely emphasise what rfc854 [Telnet] said already: write \r\0 when \r is meant, write \xFF\xFF when \xFF is meant. To mention explicitly that people read \r\n where \n was written would be to mention new protocol. Precisely defining a new protocol in order to discourage its use is ineffective, much like saying "don't think of pink elephants" is ineffective. So far so good? Anything wrong? Anything omitted? Thanks in advance. Pat LaVarre x4402 __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Tue Jan 15 17:27:31 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 RAA15137 for ; Tue, 15 Jan 2002 17:27:31 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115173329-64094-10 ; Tue, 15 Jan 2002 17:33:29 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115173326-12997-8 ; Tue, 15 Jan 2002 17:33:26 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA10663; Tue, 15 Jan 2002 17:25:41 -0500 (EST) In-Reply-To: Your message of Tue, 15 Jan 2002 17:24:30 -0500 Message-ID: Date: Tue, 15 Jan 2002 17:33:27 -0500 X-OldDate: Tue, 15 Jan 2002 17:25:41 EST 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: receive "\n" as NOT obvious as send "\r\xFF"? > Maybe slowly I progress, thank you. Let me echo back > the distinction I hear you're making, you tell me how > wrong I got it? > > rfc2640 [International Ftp] and mlst-14 [More Ftp] > merely emphasise what rfc854 [Telnet] said already: > write \r\0 when \r is meant, write \xFF\xFF when \xFF > is meant. Not quite. The rule is when sending as an NVT whenever a CR is transmitted by the application and the subsequent character is not LF, you must send a NUL. when receiving as an NVT whenever a CR is followed by a NUL, discard the NUL. NVT mode is the default. It can be overridden in either direction by use of TELNET BINARY option. However, this is never done. In all cases, the value 0xFF when sent by the application must be quoted since it is the TELNET command introducer, IAC. > To mention explicitly that people read \r\n where \n > was written would be to mention new protocol. > Precisely defining a new protocol in order to > discourage its use is ineffective, much like saying > "don't think of pink elephants" is ineffective. > > So far so good? Anything wrong? Anything omitted? Not only would it be a new protocol, as a protocol it would break interoperability. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ftp-wg-owner@hethmon.com Tue Jan 15 18:37:39 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16259 for ; Tue, 15 Jan 2002 18:37:38 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115184334-60230-9 ; Tue, 15 Jan 2002 18:43:34 -0500 Received: from web21103.mail.yahoo.com ([216.136.227.105] [216.136.227.105]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020115184329-59930-8 ; Tue, 15 Jan 2002 18:43:30 -0500 Message-ID: <20020115233544.49446.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 15:35:44 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jan 2002 18:43:31 -0500 X-OldDate: Tue, 15 Jan 2002 15:35:44 -0800 (PST) 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: receive "\n" as NOT obvious as send "\r\xFF"? > > To mention explicitly > > that people read \r\n where \n was written > > would be to mention new protocol. ... > jaltman@columbia.edu > Not only would it be a new protocol, > as a protocol it would break interoperability. An FtpServer implementing the read-\n-as-\r\n variation in rfc959 [Ftp] protocol would break the nominal rfc2640 [International Ftp] ability to exchange pathnames that include \n ... ... only if that FtpServer also included UTF8 among the options of its 211 reply to FEAT? This is part of why as yet noone cares that ftp.apple.com, ftp.microsoft.com, ftp.sun.com, members.aol.com, etc. implement the read-\n-as-\r\n protocol. > Not only would it be a new protocol, > as a protocol it would break interoperability. Yes the rfc2640 use of rfc2389 [Ftp Feature Negotiation] is delightfully fragile. rfc2640 defines an _assymetric_ feature negotiation: that rfc defines no protocol for an FtpClient to tell an FtpServer of its capabilities, nothing analogous to the apparent intent of the MS IE invention of "opts utf8 on". Just _one_ significant FtpClient implementing the read-\n-as-\r\n protocol, in the parsing of Ftp replies, NLST/LIST/MLSD data, etc. will break the nominal rfc2640 ability to exchange pathnames that include \n. Accordingly, the de facto network Eol exchanged inside Ascii-transferred pathnames may well end up being the \r of the Apple Mac, rather than the \r\0\n you might guess from reading rfc854. > > rfc854 [Telnet] said already: > > write \r\0 when \r is meant, ... > Not quite. The rule is > > when sending as an NVT whenever a CR is transmitted > by the application and the subsequent character is > not LF, you must send a NUL. > > when receiving as an NVT whenever a CR is followed > by a NUL, discard the NUL. Please tell me if you mean to be _quoting_ a source re the Telnet protocol unknown to newbie me, as opposed to just _paraphrasing_ rfc854 [Telnet]? In rfc854 I see: "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." > > Precisely defining a new protocol in order to > > discourage its use is ineffective, much like saying > > "don't think of pink elephants" is ineffective. So far so good? Anything wrong? Anything omitted? Thanks again in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Wed Jan 16 13:16: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 NAA16401 for ; Wed, 16 Jan 2002 13:16:07 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116131950-58958-9 ; Wed, 16 Jan 2002 13:19:50 -0500 Received: from web21102.mail.yahoo.com ([216.136.227.104] [216.136.227.104]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116131945-20498-8 ; Wed, 16 Jan 2002 13:19:45 -0500 Message-ID: <20020116181159.38761.qmail@web21102.mail.yahoo.com> Received: from [147.178.1.2] by web21102.mail.yahoo.com via HTTP; Wed, 16 Jan 2002 10:11:59 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jan 2002 13:19:47 -0500 X-OldDate: Wed, 16 Jan 2002 10:11:59 -0800 (PST) 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: more explicit Ftp archive links I now possess more explicit Ftp-WG archive links; if you see this, then so do you: > my .zip reader choked over the last few files of > "http://w3.hethmon.com/ftpext/zips/" 1) We trust you to think to try viewing each file as plain text, rather than trying only to view each file as if it were zipped, via a protocol that distorts your view as commonly as does http. Often a zipped file viewed as plain text begins "PK". > "ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-NN.txt.Z" > ... Go back far enough > ... the "summary of what changed in this draft" > ... directory listing ... long ... 2) The free binaries of Cygwin `gunzip` have been seen to decrypt this standard Unix .Z `compress`ion. 3) We mean the quasi-Url here as a summary of ftp://... Url's, not the ftp://... Url of a summary. Sufficiently brain-dead browsers will cope better if you try the series: ... ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-14.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-13.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-12.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-11.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-10.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-09.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-08.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-07.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-06.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-05.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-04.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-03.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-02.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-01.txt.Z ftp://munnari.oz.au/internet-drafts/draft-ietf-ftpext-mlst-00.txt.Z > you ... don't need to go back too far > to get the "summary of what changed in this draft" > section in the abstract 4) You have to go back no further than the mlst-09 draft of December, 1999. Pat LaVarre P.S. As yet, munnari.oz.au:21 replies 500 to FEAT. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Wed Jan 16 13:33:45 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 NAA17077 for ; Wed, 16 Jan 2002 13:33:44 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116133940-23119-9 ; Wed, 16 Jan 2002 13:39:40 -0500 Received: from alpha.ipswitch.com ([216.104.149.100] [216.104.149.100]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116133935-60957-8 ; Wed, 16 Jan 2002 13:39:36 -0500 Received: from wks222 [216.104.149.222] by alpha.ipswitch.com (SMTPD32-7.05) id A74C338D0098; Wed, 16 Jan 2002 13:32:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020116181159.38761.qmail@web21102.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Date: Wed, 16 Jan 2002 13:39:37 -0500 X-OldDate: Wed, 16 Jan 2002 13:31:54 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Mark Symons" To: "FTPEXT Working Group" Subject: Ftp-WG: more explicit Ftp archive links Content-Transfer-Encoding: 7bit > P.S. As yet, munnari.oz.au:21 replies 500 to FEAT. Yes, it does. Try port 9000. Mark Symons Ipswitch, Inc Augusta GA From ftp-wg-owner@hethmon.com Wed Jan 16 19:28: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 TAA24476 for ; Wed, 16 Jan 2002 19:28:11 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116193356-31062-9 ; Wed, 16 Jan 2002 19:33:56 -0500 Received: from web21101.mail.yahoo.com ([216.136.227.103] [216.136.227.103]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020116193351-36224-8 ; Wed, 16 Jan 2002 19:33:51 -0500 Message-ID: <20020117002605.31693.qmail@web21101.mail.yahoo.com> Received: from [147.178.1.2] by web21101.mail.yahoo.com via HTTP; Wed, 16 Jan 2002 16:26:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jan 2002 19:33:53 -0500 X-OldDate: Wed, 16 Jan 2002 16:26:05 -0800 (PST) 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 UTF8 does NOT mean \r and \n ok in pathnames? > > > P.S. As yet, munnari.oz.au:21 > > > replies 500 to FEAT. ... > > msymons@alpha.ipswitch.com 1/16/02 11:39am > > Yes, it does. > > Try port 9000. ... > aka 128.250.22.2:9000 Good fun, thank you. Is munnari.oz.au:9000 intended as a reference implementation of an FtpServer? i.e. made available to be complimented by imitation? I'm pleased to see this FtpServer includes the UTF8 option among the lines of its 211 reply to FEAT ... but I don't yet understand how it complies with rfc2640 [International Ftp]: "On receipt of a pathname containing a sequence the character MUST be stripped away." Here, when my FtpClient writes the thirteen bytes "CWD /\r\0NOOP\r\n", I see the munnari.oz.au:9000 FtpServer replies only to the "CWD /" part, as if it saw CR LF EOP where I wrote CR NUL: C> CWD /%0DNOOP s> 250 CWD command successful. (By "EOP" I mean end-of-packet. To see EOP anywhere but at the end of a packet is to discard all the data that follows within the packet.) Here, when my FtpClient writes the the twelve bytes "CWD /\nNOOP\r\n", I see the munnari.oz.au:9000 FtpServer replies _twice_ rather than once, as if it saw CR LF where I wrote LF: C> CWD /%0ANOOP s> 250 CWD command successful. s> 200 NOOP command successful. Can anyone here easily reproduce my observations? [Anybody even interested?] Have I grossly misunderstood how to escape & delimit Ftp commands sent across the control connection? Maybe "everyone knows" that rfc2640 [International Ftp] is tongue-in-cheek where it says it has abandoned the rfc959 restriction forbidding \r and \n in pathnames? Just as rfc959 [Ftp] was tongue-in-cheek where it said \0 may appear in pathnames? Thanks in advance. Pat LaVarre P.S. The port number "9000" appears as a "whole word" nowhere outside this thread in my local cache of the archives. P.P.S. Most of the FtpServer's I've met respond as munnari.oz.au:9000 does i.e. ftp.apple.com, ftp.sun.com, members.aol.com, .... But ftp.microsoft.com:21 differs usefully: C> CWD /%0ANOOP s> 250 CWD command successful. C> CWD /%0DNOOP C> QUIT s> 550 /QUIT: ... cannot find the file ... Seemingly this ftp.microsoft.com:21 FtpServer is seeing CR LF EOP where I wrote LF and seeing EOP where I wrote CR NUL. Therefore I can't believe my FtpClient is writing other than what I tell it to write without first dreaming up a theory to explain both the munnari.oz.au:9000 and the ftp.microsoft.com:21 kinds of responses. To say the misbehaviour is on my end, I'd also have to explain why my own FtpServer running on my local notwork (not just localhost) says that my FtpClient is writing what I tell it. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Thu Jan 17 08:57: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 IAA15468 for ; Thu, 17 Jan 2002 08:57:50 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117090335-16432-9 ; Thu, 17 Jan 2002 09:03:36 -0500 Received: from mail15a.boca15-verio.com ([208.55.91.57] [208.55.91.57]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117090331-62527-8 ; Thu, 17 Jan 2002 09:03:31 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 65456261 for ; Thu, 17 Jan 2002 08:54:42 -0500 (EST) Message-Id: <4.3.2.7.2.20020117073904.02397f60@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <20020117002605.31693.qmail@web21101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Thu, 17 Jan 2002 09:03:32 -0500 X-OldDate: Thu, 17 Jan 2002 07:42:40 -0600 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: FEAT UTF8 does NOT mean \r and \n ok in pathnames? At 06:33 PM 1/16/2002, you wrote: >Maybe "everyone knows" that rfc2640 [International >Ftp] is tongue-in-cheek where it says it has abandoned >the rfc959 restriction forbidding \r and \n in >pathnames? > >Just as rfc959 [Ftp] was tongue-in-cheek where it said >\0 may appear in pathnames? That's really quite insulting of you to suggest that either RFC was tongue-in-cheek. The RFCs are technical documents of the way that implementations _should_ work. As I've told you several times before, there are many reasons - perhaps even good reasons - why implementations don't work the way that the RFCs document. This does not mean that either one is poking fun at the Internet community in general. While it's somewhat confusing (and galling) to see RFC after RFC describe FTP URLs in a manner completely contradictory to the way they are implemented by most browsers, the case you're discussing isn't nearly as bad as that. You're talking about a very exceptional circumstance as if it's a common occurrence, and then asserting (without any supporting information) that these exceptions are handled incorrectly in order to annoy people. 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 Jan 17 23:20:21 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21476 for ; Thu, 17 Jan 2002 23:20:20 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117232554-13542-10 ; Thu, 17 Jan 2002 23:25:54 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117232546-54690-9 ; Thu, 17 Jan 2002 23:25:49 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0HD30A00524 for ; Thu, 17 Jan 2002 20:03:00 +0700 (ICT) In-Reply-To: <20020117002605.31693.qmail@web21101.mail.yahoo.com> References: <20020117002605.31693.qmail@web21101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <522.1011272580@brandenburg.cs.mu.OZ.AU> Date: Thu, 17 Jan 2002 23:25:51 -0500 X-OldDate: Thu, 17 Jan 2002 20:03:00 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok in pathnames? Date: Wed, 16 Jan 2002 19:33:53 -0500 From: Pat LaVarre Message-ID: <20020117002605.31693.qmail@web21101.mail.yahoo.com> | > > msymons@alpha.ipswitch.com 1/16/02 11:39am | > > Yes, it does. | > > Try port 9000. | ... | > aka 128.250.22.2:9000 Oh well, once that wasn't public information. Never mind... | Is munnari.oz.au:9000 intended as a reference | implementation of an FtpServer? No. Only of the MLST/MLSD commands (and even then not really a reference implementation, most just a sample implementation, were it a reference the code would be available, and it isn't, it is way too ugly). | I'm pleased to see this FtpServer includes the UTF8 | option among the lines of its 211 reply to FEAT ... Probably it shouldn't. I used it to generate a lot of the examples in the mlst draft, and as the draft says, *every* example in it comes from an actual exchange with one ftp server or another (some of the output sometimes deleted, absolutely nothing invented). To get an example with UTF8 in the Feat, I needed a server to say that... | but I don't yet understand how it complies with | rfc2640 [International Ftp]: "On receipt of a pathname | containing a sequence the character | MUST be stripped away." It most likely doesn't. I will look at that sometime. | Here, when my FtpClient writes the thirteen bytes "CWD | /\r\0NOOP\r\n", I see the munnari.oz.au:9000 FtpServer | replies only to the "CWD /" part, as if it saw CR LF | EOP where I wrote CR NUL: | | C> CWD /%0DNOOP | s> 250 CWD command successful. | | (By "EOP" I mean end-of-packet. To see EOP anywhere | but at the end of a packet is to discard all the data | that follows within the packet.) No, there is certainly no knowledge of packets in there, with TCP only a very broken implementation can possibly see that. What actually happens is that the command is read (the whole thing, up to the \r\n) then it is all treated as a C string (terminated by a null) and then the \r before the end of string (which was previously assumed to be a \n) is removed. Packet boundaries have nothing at all to do with it (send more in the same packet, you'll verify that easily enough). And yes, treating this stuff as C strings is broken - but it is also easy, and doesn't actually affect anything (on this VFS, there are no legal pathnames that contain a \0 so none will ever be sent, and there's no rational reason for a client to ever send one). | | Here, when my FtpClient writes the the twelve bytes | "CWD /\nNOOP\r\n", I see the munnari.oz.au:9000 | FtpServer replies _twice_ rather than once, as if it | saw CR LF where I wrote LF: Yes, it will do that too. | Can anyone here easily reproduce my observations? There is no need. I'm quite sure they're all correct. | [Anybody even interested?] Not very. | Have I grossly misunderstood how to escape & delimit | Ftp commands sent across the control connection? No. | Maybe "everyone knows" that rfc2640 [International | Ftp] is tongue-in-cheek where it says it has abandoned | the rfc959 restriction forbidding \r and \n in | pathnames? No. But that they aren't forbidden doesn't mean that any particular server is required to support names like that. | Just as rfc959 [Ftp] was tongue-in-cheek where it said | \0 may appear in pathnames? And the same there. | The port number "9000" appears as a "whole word" | nowhere outside this thread in my local cache of the | archives. No, until now, only a comparatively small set of people knew of that server ... No guarantees it will remain forever (the implementation is not very effecient). And I guess now I'm going to have to disable the "anyone can write" directories that that server provided. | Most of the FtpServer's I've met respond as | munnari.oz.au:9000 does i.e. ftp.apple.com, | ftp.sun.com, members.aol.com, .... They're most probably hosted on unix systems, and all derived from the same code base. | But ftp.microsoft.com:21 differs usefully: But that one almost certainly isn't. | To say the misbehaviour is on my end, No-one is saying that, are they? kre From ftp-wg-owner@hethmon.com Thu Jan 17 23:21: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 XAA21560 for ; Thu, 17 Jan 2002 23:21:10 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117232652-33569-13 ; Thu, 17 Jan 2002 23:26:52 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020117232148-53443-8 ; Thu, 17 Jan 2002 23:26:49 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0HCmbA00510 for ; Thu, 17 Jan 2002 19:48:37 +0700 (ICT) In-Reply-To: <20020116181159.38761.qmail@web21102.mail.yahoo.com> References: <20020116181159.38761.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <508.1011271717@brandenburg.cs.mu.OZ.AU> Date: Thu, 17 Jan 2002 23:26:50 -0500 X-OldDate: Thu, 17 Jan 2002 19:48:37 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: more explicit Ftp archive links Date: Wed, 16 Jan 2002 13:19:47 -0500 From: Pat LaVarre Message-ID: <20020116181159.38761.qmail@web21102.mail.yahoo.com> | P.S. As yet, munnari.oz.au:21 replies 500 to FEAT. It does on the standard FTP port, yes, that's a fairly old ftpd. There is a test server on a different port that anyone seriously testing a client can be aimed at (send me off list mail). That particular munnari.oz.au (the hardware under it) won't be munnari much longer, after it swaps, the new one will support feat on the standard server (and mlst, etc). kre From ftp-wg-owner@hethmon.com Fri Jan 18 00:00:31 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 AAA22711 for ; Fri, 18 Jan 2002 00:00:30 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118000244-3377-9 ; Fri, 18 Jan 2002 00:02:44 -0500 Received: from alpha.ipswitch.com ([216.104.149.100] [216.104.149.100]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118000240-61839-8 ; Fri, 18 Jan 2002 00:02:40 -0500 Received: from wks222 [216.104.149.222] by alpha.ipswitch.com (SMTPD32-7.05) id AAD139B014C; Thu, 17 Jan 2002 23:55:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <522.1011272580@brandenburg.cs.mu.OZ.AU> Importance: Normal Date: Fri, 18 Jan 2002 00:02:41 -0500 X-OldDate: Thu, 17 Jan 2002 23:54:56 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Mark Symons" To: "FTPEXT Working Group" Subject: Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok in pathnames? Content-Transfer-Encoding: 7bit | > > msymons@alpha.ipswitch.com 1/16/02 11:39am | > > Yes, it does. | > > Try port xxxxx > Oh well, once that wasn't public information. Aghhh! Sorry, I was not thinking. > Never mind... You can say that. I still feel embarrassed. =) > To get an example with UTF8 in the Feat, I needed > a server to say that... Try anon login here: ftp://ftp.ipswitch.com FEAT 211-Extensions supported SIZE MDTM MLST size*;type*;perm*;create*;modify*; LANG EN* REST STREAM TVFS UTF8 AUTH SSL;TLS-P; PBSZ PROT C;P; 211 end This is WS_FTP Server v3.00. The current version is actually v3.01. I have not personally tested WS_FTP server myself in the last few months - I am totally tied up with another product. But I will always take time out to chase things if anyone reckons that there is odd behavior vis-a-vis compliance with the MLST or similar drafts. Mark Symons Ipswitch, Inc Augusta GA From ftp-wg-owner@hethmon.com Fri Jan 18 18:12:26 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00276 for ; Fri, 18 Jan 2002 18:12:25 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118181740-43986-9 ; Fri, 18 Jan 2002 18:17:41 -0500 Received: from web21104.mail.yahoo.com ([216.136.227.106] [216.136.227.106]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118181736-35685-8 ; Fri, 18 Jan 2002 18:17:36 -0500 Message-ID: <20020118230949.46953.qmail@web21104.mail.yahoo.com> Received: from [147.178.1.2] by web21104.mail.yahoo.com via HTTP; Fri, 18 Jan 2002 15:09:49 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 18:17:38 -0500 X-OldDate: Fri, 18 Jan 2002 15:09:49 -0800 (PST) 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: ftp.ipswitch.com:21 vs. Ftp rfc & draft-ietf > > P.S. As yet ... replies 500 to FEAT > Try anon login here: ftp://ftp.ipswitch.com ... > Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok in pathnames? Good fun, thank you. [Please everyone tell me offline who feels instead I should have sent this person-to-person.] I think I see ... Per rfc1123, but differing from ftp.microsoft.com, less and more than one command may appear in a packet: C> quote NOOP%0D%0ASYST%0D%0A s> 200 noop s> 215 UNIX C> quote NOOP%0D%0ASYST s> 200 noop C> quote %0D%0A s> 215 UNIX Vs. rf2640 of LANG before "authentication" and FEAT before LANG, this FtpServer replies 530 to FEAT until after authentication: C> FEAT s> 530 Please login with USER and PASS ... Vs. rfc2640, in an area not covered by rfc959, this FtpServer liberally accepts LF as meaning CR LF: C> quote CWD /%0ANOOP%0D%0A s> 250 CWD successful s> 200 noop s> 215 UNIX Vs. rfc2640, this FtpServer conservatively accepts CR NUL as meaning ignore all further commands: C> quote CWD /%0D%00NOOP%0D%0A C> quote QUIT%0D%0A C> quote QUIT%0D%0A ... Vs. rfc959, this FtpServer conservatively accepts NUL as meaning ignore all further commands: C> quote CWD /%00NOOP%0D%0A C> quote QUIT%0D%0A C> quote QUIT%0D%0A ... Thanks for sharing. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Fri Jan 18 18:55:21 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01120 for ; Fri, 18 Jan 2002 18:55:20 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118190114-58129-9 ; Fri, 18 Jan 2002 19:01:14 -0500 Received: from web21103.mail.yahoo.com ([216.136.227.105] [216.136.227.105]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118190110-34003-8 ; Fri, 18 Jan 2002 19:01:10 -0500 Message-ID: <20020118235323.87788.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Fri, 18 Jan 2002 15:53:23 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 19:01:11 -0500 X-OldDate: Fri, 18 Jan 2002 15:53:23 -0800 (PST) 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: transfers of \r, \n, \r\n > Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok ... I read the rfc's as saying an Ftp implementation should pass \r, \n, \r\n thru the control connection as \r\0, \n, and \r\n. For control bytes, the issue of what Eol is locally preferred does not arise. But the rules for an "NVT-ASCII" DATA connection appear less clear to me, in particular the rules for the "TYPE A"scii transfer of NLST data that rfc959 recommends. I think I see rfc959 [Ftp] says an \r appears on a "TYPE A"scii data connection only as \r\0 or \r\n, by way of rfc854 [Telnet]. I think I see rfc959 says the locally preferred Eol passes thru a "TYPE A"scii data connection as \r\n. I hear people vary greatly over how many things other than the locally preferred Eol an Ftp implementation should liberally accept as an Eol to be passed thru as \r\n. Specifically, I hear we see local \r, \n, \r\n pass thru as: \r\n, \n, \r\n \r\0, \n, \r\n \r\n, \r\n, \r\n On my own, I had read rfc1123 [Requirements] as favouring the last: "be liberal in what you accept" as a locally understood Eol. But then on Usenet I hear I should disregard how many Eol's in fact are understood locally. I should "of course" instead choose a behaviour by platform: \r\n, \n, \r\0\n \r\0, \r\n, \r\0\n \r\0, \n, \r\n How clearly, specifically where, do the Ftp rfc's tell us which of these people are wrong? > http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-14.txt ... > all 256 possible octet values are permitted. > as arguments ... and in responses > both to the MLST and MLSD commands, > and all other FTP commands > which take pathnames as arguments. ... > In all cases for MLST, a single set of fact lines > (usually a single fact line) containing > the information about the named file or directory > shall be returned over the control connection, > without opening a data connection. ... > The data connection opened for a MLSD response > shall be a connection as if the "TYPE L 8", > "MODE S", and "STRU F" commands had been given, > whatever FTP transfer type, mode and structure > had actually been set, and without causing those > settings to be altered for future commands. I see mlst-14 plans for us to exchange pathnames via the quasi-"TYPE A"scii of the control connection when pathnames appear as command parameters, NLST data, or mlsT reply text. We will exchange them via a "TYPE L 8" data connection only when pathnames appear as mlsD data. That mixture of data connection TYPE's sounds like an opportunity to fall into disagreement over what the pathname truly is? We cannot intend that the client always disregard the SP pathname of an MLST response - else why include it. Could someone here easily fill me in on the history of why we do not perpetuate the recommendation that any FtpClient request either "TYPE A"scii or "TYPE E"bcdic for MLST data, just as rfc959 recommends for NLST? > > > P.S. As yet ... replies 500 to FEAT > > Try anon login here: ftp://ftp.ipswitch.com C> TYPE I s> 200 Type set to IMAGE. C> MLSD s> 150 Opening ASCII data connection for directory listing ... I find the choice of 150 reply text here confusing. I'd prefer to be told my MLSD connection is a "TYPE L 8, MODE S, STRU F" data connection, or a "binary" data connection, or ... rather than an "ASCII" data connection. Thanks again in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Fri Jan 18 19:09:36 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 TAA01373 for ; Fri, 18 Jan 2002 19:09:35 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118191525-877-9 ; Fri, 18 Jan 2002 19:15:25 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118191521-41661-8 ; Fri, 18 Jan 2002 19:15:21 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id TAA09341 for FTPEXT Working Group ; Fri, 18 Jan 2002 19:07:34 -0500 (EST) In-Reply-To: Your message of Fri, 18 Jan 2002 19:01:11 -0500 Message-ID: Date: Fri, 18 Jan 2002 19:15:23 -0500 X-OldDate: Fri, 18 Jan 2002 19:07:33 EST 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: transfers of \r, \n, \r\n Telnet protocol only applies to the command channel not the data channel. From ftp-wg-owner@hethmon.com Fri Jan 18 19:28: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 TAA01679 for ; Fri, 18 Jan 2002 19:28:27 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118193420-60410-9 ; Fri, 18 Jan 2002 19:34:20 -0500 Received: from web21103.mail.yahoo.com ([216.136.227.105] [216.136.227.105]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118193417-58731-8 ; Fri, 18 Jan 2002 19:34:17 -0500 Message-ID: <20020119002631.93170.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Fri, 18 Jan 2002 16:26:31 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 19:34:18 -0500 X-OldDate: Fri, 18 Jan 2002 16:26:31 -0800 (PST) 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 UTF8 does NOT mean \r and \n ok in pathnames? > > To say the misbehaviour is on my end, > No-one is saying that, are they? I think I've fuzzily been told No, but pending volunteer elaboration, I'll try to ask more clearly: Does "everyone know" we only intend real Ftp implementations to support non-empty pathnames made up of nothing but SP, printable US-Ascii, and Unicode x80..FFFF converted to shortest-form UTF-8: pathname = 1*(%x20-7E / %x80-DF) ? Otherwise, I really really really don't understand a myriad of things I see. In detail: > > > http://www.m-w.com/cgi-bin/dictionary > > > tongue-in-cheek [=] whimsically exaggerated ... > > Maybe "everyone knows" that > > rfc2640 [International Ftp] is tongue-in-cheek > > where it says it has abandoned the rfc959 > > restriction forbidding \r and \n in pathnames? > > > Just as rfc959 [Ftp] was tongue-in-cheek > > where it said \0 may appear in pathnames? ... > kre@munnari.oz.au > Thursday - January 17, 2002 9:30 PM ... > No. ... > ... \0 ... none will ever be sent ... Ouch. I'm so totally not getting it. > [We commonly read rfc959 to mean > that \0 may appear in pathnames > and yet we commonly read rfc959 to mean > that \0 is never sent in a pathname to an > FtpServer whose NVFS happens not to support \0.] You didn't just say that, did you? To me this erroneous paraphrase reads like an irreducible dialectic? Fun, aye ... but not concretely realisable? > ... that they aren't forbidden > doesn't mean that any particular server > is required to support names like that. ... > on this VFS, there are no legal pathnames > that contain a \0 so none will ever be sent, May we focus here a moment? I'm thinking interoperability suffers unless people commonly read the Ftp rfc/draft-ietf's to be saying: 1) All Ftp implementations must parse all Ftp pathnames correctly. 2) rfc959 FtpClient's matter. 3) The rfc's state precisely the pathname ABNF that everyone should parse. 4) rfc2234 [ABNF] precisely defines the meaning of the ABNF in the rfc's. As yet, in my newbie ignorance, I find I can't persuade myself that people do commonly read the Ftp rfc/draft-ietf's this way? > 1) All Ftp implementations must parse all Ftp pathnames correctly. Is this in dispute? Any pathname permitted by the rfc BNF may appear as the parameter to MKD/STOR, precisely in order to determine if the NVFS of the FtpServer supports that pathname . Any pathname permitted by the rfc BNF may appear as the parameter to CWD/RETR, when extracted from an ftp://... Url according to rfc1738 [Url's]. Any pathname permitted by the rfc BNF may appear in NLST/MLSD data. Any Ftp implementation that improperly parses such a pathname - seeing more commands, seeing catenated commands where none exist - flatly violates the rfc's. Maybe nobody cares. But to say improper parsing is not a violation is like saying a C compiler doesn't have to parse string literals properly. De facto truth, I agree. But a de jure crime, unequivocally. > 2) rfc959 FtpClient's matter. It seems this IS in dispute? An FtpServer can passively ask to see only rfc959 pathnames by not replying 211 to FEAT or by neglecting to include a UTF8 option there. But no protocol exists to protect rfc959 FtpClient's from encountering rfc2640 pathnames in NLST/MLSD data. > 3) The rfc's state precisely the pathname ABNF that everyone should parse. It seems this IS in dispute? rfc959 says 1*(%x00-7F) ... but Everyone knows %x00 %x0A %x0D (NUL LF CR) don't work and rfc959 says the other Telnet control bytes can have effect e.g. "a\008cde" may mean "cde" because %x08 is BS i.e. backspace. rfc2640 says 1*(%x01-FF). Thus rfc2640 abandons %x00 NULL without comment but leaves %x0A %x0D and the other Telnet control bytes in place. Why bother to say less than arbitrary sequences of bytes/chars work - why bother to forbid empty pathnames and %x00 NUL and so on - without setting forth a common goal of a BNF we can credibly expect everyone to work to parse properly? 4) rfc2234 [ABNF] defines the meaning of the ABNF in the rfc's. rfc2640 actually says: pathname = 1*(%x01..%xFF) ; in ABNF format [ABNF]. [ABNF] [=] RFC 2234, November 1997 But rfc2234 defines the ".." syntax nowhere. This is nothing but another almost weightless straw on the camel's back. But this camel is flat on the ground. > I'm thinking interoperability suffers ... > As yet, in my newbie ignorance, ... I think I see that "everyone knows" we only intend to work jointly to support non-empty pathnames made up of nothing but SP, printable Ascii, and Unicode x80..FFFF converted to shortest-form UTF-8: pathname = 1*(%x20-7E / %x80-DF) Even there I'm guessing we might not work too hard to properly parse the Unicode control chars x80-A0 and xAD i.e. the shortest-form UTF-8 of %xC2 %x80 to %xC2 %xA0, and %xC2 %xAD. But every time I try to say this, somebody pops up and says no of course not. How many fundamentals have I got wrong here? Anybody out there feel at all able to begin to clue me in? Thanks again in advance. Pat LaVarre P.S. I launched a separate thread titled "Ftp-WG: transfers of \r, \n, \r\n" to try and get me straight on what a "TYPE A"scii data transfer of NLST/MLST (but never MLSD) data does. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Fri Jan 18 19:54: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 TAA01983 for ; Fri, 18 Jan 2002 19:54:16 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118200007-52992-9 ; Fri, 18 Jan 2002 20:00:07 -0500 Received: from web21103.mail.yahoo.com ([216.136.227.105] [216.136.227.105]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020118200003-34985-8 ; Fri, 18 Jan 2002 20:00:03 -0500 Message-ID: <20020119005217.96405.qmail@web21103.mail.yahoo.com> Received: from [147.178.1.2] by web21103.mail.yahoo.com via HTTP; Fri, 18 Jan 2002 16:52:17 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 20:00:05 -0500 X-OldDate: Fri, 18 Jan 2002 16:52:17 -0800 (PST) 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: transfers of \r, \n, \r\n > > > The rules for an "NVT-ASCII" DATA connection > > > appear less clear to me, in particular ... NLST > jaltman@columbia.edu 01/18/02 17:20 PM > Telnet protocol only applies > to the command channel not the data channel. Thanks for listening, thanks for answering, but ... Too fast for me, sorry. Can you say again specifically how the rfc's require a local \r, \n, and \r\n to pass thru a "TYPE A"scii data connection? Myself I can read rfc959 many, many different ways here: many equally credible. You can't mean to say local \r, \n, \r\n should pass thru a "TYPE A"scii data connection unchanged - can you? I thought "everyone" did agree at least the locally preferred Eol changes en route? I wonder if "everyone knows" that rfc959 means ... > > http://www.ietf.org/rfc/rfc959.txt [Ftp] ... > > 3. DATA TRANSFER FUNCTIONS > > 3.1. DATA REPRESENTATION AND STORAGE > > 3.1.1. DATA TYPES > > 3.1.1.1. ASCII TYPE ... > > the default type ... intended primarily > > for the transfer of text files ... i.e. intended primarily intended for the exchange of the bytes %x20-7E. Little thought, less comment re what happens to bytes %x00-1F and %x7F-FF. > > The sender converts the data from an internal > > character representation to the standard 8-bit > > NVT-ASCII representation > > (see the Telnet specification). i.e. portions of rfc854 [Telnet] do apply to the data connection. In particular: \r may appear only as \r\0 or as \r\n, and \xFF may appear only as \xFF\xFF, but all other bytes may appear in any ordering. > > The receiver will convert the data > > from the standard form > > to his own internal form. i.e. the sequence should change into the locally preferred Eol at the receiving end. > > In accordance with the NVT standard, > > the sequence should be used > > where necessary to denote > > the end of a line of text. i.e. at the sending end the locally preferred Eol should pass into a "TYPE A"scii data connection as the sequence. > > (See the discussion of file structure > > at the end of the Section on > > Data Representation and Storage.) Personally I've failed to click thru this link with much confidence, but just guessing: > > 3.1.2.1. FILE STRUCTURE > > > > File structure is the default > > to be assumed if the STRUcture command > > has not been used. > > > > In file-structure > > there is no internal structure > > and the file is considered > > to be a continuous sequence of data bytes. Not especially meaningful - this a declaration of a conscious neglect to require work. > > > The rules for an "NVT-ASCII" DATA connection > > > appear less clear to me, in particular ... NLST ... > > > Can you say again specifically > > > how the rfc's require a local \r, \n, and \r\n > > > to pass thru a "TYPE A"scii data connection? Unless we can answer this, we can't say how to NLST or MLST a pathname that includes \r or \n: we can only say how to MLSD it. Thanks again in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Sat Jan 19 16:14: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 QAA22910 for ; Sat, 19 Jan 2002 16:14:42 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020119162032-20315-10 ; Sat, 19 Jan 2002 16:20:32 -0500 Received: from mail.vr.net ([205.133.13.8] [205.133.13.8]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020119162026-59180-9 ; Sat, 19 Jan 2002 16:20:26 -0500 Received: from hathor (hathor.vr.net [205.133.13.10]) by mail.vr.net (8.10.1/8.10.1) with SMTP id g0JLAib18742 for ; Sat, 19 Jan 2002 16:10:45 -0500 Message-ID: <056c01c1a12e$86bbb2a0$0a0d85cd@vr.net> References: <20020118230949.46953.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: Sat, 19 Jan 2002 16:20:29 -0500 X-OldDate: Sat, 19 Jan 2002 16:16:11 -0500 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: ftp.ipswitch.com:21 vs. Ftp rfc & draft-ietf Content-Transfer-Encoding: 7bit > Per rfc1123, but differing from ftp.microsoft.com, > less and more than one command may appear in a packet: Where does this "packet" junk come from? Packets are immaterial. The only time packets are important is when your supporting FTP and a clueless vendor's software is assuming packets have some special importance or are under the control of the sending application. The FTP is a language specification. As such, a number of things are _intentionally_ left unspecified. Let's examine some byte sequences. For my discussion, assume each byte sequence example begins at the "start of a new line" state. CWD\040PATHNAME\r\n The correct parse yeild the patameter PATHNAME. CWD\040PATH\r\0NAME\r\n The sequence \r\0 is an escaped \r, therefore the correct parse for the parameter yields PATH\rNAME. CWD\040PATH\r\nNAME\r\n The sequence \r\n terminates the command, therefore the correct parse yields the parameter PATH and leaves NAME\r\n in the input stream for subsequent parsing. CWD\040PATH\nNAME\r\n The correct parse for the parameter yeilds PATH\nNAME. On the control connection, a bare \n has no special meaning. CWD\040PATH\rNAME\r\n The correct parse yields the parameter PATH\rNAME. The \r, however, was not followed by either \0 or \n and is technically a syntax error. Client authors SHOULD NOT send this sequence and MUST be prepared for it to be rejected as a syntax error. The intention of the FTP, however, is that the control connection be usable by a human using the TELNET protocol. Here the principle "be liberal in what you accept" comes into play. We have a choice of issuing an error response due to the syntax error or accepting the parameter; the server SHOULD (liberally) accept it and SHOULD NOT issue an error response. This desire to support a user's use of TELNET leads to the other problem: all TELNET commands are preceeded by IAC (\0377). So that character must also be escaped. CWD\040PATH\0377\0377NAME\r\n The correct parse yields the parameter PATH\0377NAME. The TELNET protocol specifies that IAC IAC represents an escaped IAC to be treated as data and not a TELNET command. CWD\040PATH\0377\0375\001NAME\r\n The correct parse yeilds the parameter PATHNAME. The sequence IAC DO ECHO (\0377\0375\0001) is a TELNET command. Whether (and how) the FTP server honors this command is unspecified; it MAY honor the command (injecting IAC WILL ECHO into the return data stream for the control connection), MAY recognize and refuse the command (injecting IAC WONT ECHO), or MAY ignore the command (making no response at all). CWD\040PATH\0377\0375NAME\r\n The correct parse yeilds the parameter PATHAME (note the N is missing). This is because the TELNET protocol requires WILL WONT DO and DONT to be followed by a single-byte option code. The fact that IAC DO 'N' is not a valid TELNET command is immaterial. Why assume the N is part of the TELNET command, and not data? Because, by the rule of being liberal in what we accept, we accept ANY single-byte following IAC DO to be part of some (possibly new) TELNET option negotiation. To assume otherwise would break compatability on the control connection with future TELNET options. (Note that I chose IAC DO ECHO specifically. It shows _why_ the FTP SHOULD NOT honor and implement all of the TELNET options. To do so would imply that characters received by the FTP server following acceptance of the option would be echoed on the return data stream. This would make the responses difficult to separate from command echos. The server has no way of knowing whether the client can handle the echoed characters. By the principle of being conservative in what we send, the server MAY accept IAC DO ECHO and refuse the option by sending IAC WONT ECHO, or MAY ignore IAC DO ECHO, but the server SHOULD NOT accept the option by sending IAC WILL ECHO.) CWD\040PATH\0377NAME\r\n The correct parse yields the parameter PATHAME (again, the N is missing). The TELNET protocol requires IAC to be followed by a command-code byte. The rule of being liberal in what we accept applies here just as it did for IAC DO 'N'. We don't know that 'N' is not a new, unknown TELNET command and must accept it as such. The discussion so far has assumed only ASCII characters. The addition of RFC 2640 complicate matters only slightly. Prior to RFC 2640, the fact that TELNET commands have a higher precidence could safely be ignored. Servers implementing 2640, however, MUST interpret the data stream using the precidence order: - TELNET (highest precidence) - Character set recognition (ie., UTF8) - End-of-line recognition (ie, \r\0 and \r\n) The reason is that character set encoding (such as UTF8) add "shift state". While shifted, bit sequences which appear identical to end-of-line sequences are NOT end-of-line sequences. As an example of a simple character encoding scheme (which my server could advertize as FEAT X-CHARACTER-LITERAL), I will use matching single quote (') characters to "shift" into my alternate character set. For this character encoding scheme we'll use ANSI/ISO C character literal formatting, accepting all bytes as data, except \ and '; following all requirements for ANSI/ISO C character literals but accepting all invalid \ escape sequences by dropping the \ (just as many compilers do). (Remember, however, that I am already using C notation, so if I want to show the \ character as appearing "on the wire" I will note it as \\.) CWD\040'\040PATH\r\0NA\r\n'ME\r\n The correct parse yields the parameter '\040PATH\r\0NA\r\n'ME. This is because the character set "shift" state has higher precidence than end-of-line recognition. Note that the parse accepts the \0 as data. This does NOT violate the rules stated in RFC 2640. At this point, we only have a "parameter" token. The \0 may, or may not, represent an invalid character because the token has not yet been converted into a pathname. The conversion from token to pathname is unspecified (and implementation defined). The restriction in RFC 2640 is that the _pathname_ (the token, after conversion) MUST NOT contain \0 is in deference to the problems faced by ANSI/ISO C programs when dealing with this character. Note that RFC 2640 specifies the use of UTF8, and that \0 will NEVER appear in any "shifted" character encoding under UTF8 except the single, unshifted (ASCII) character NUL. My hypothetical server, therefore, would accept the above as the command-token CWD followed by the parameter-token '\040PATH\r\0NA\r\n'ME. During sematic interpretation, it would find the parameter-token for CWD is a pathname and attempt a conversion. At this point, my server could issue an error response since the character \0 appears in a pathname in violation of RFC 2640. By the rule of being liberal in what we accept, however, if the implementation can handle \0 in a pathname token, my server could accept it and proceed to attempting to execute the CWD action with the (now converted) pathname. CWD\040'\040PATH\377\375\001NA\r\n'ME\r\n The correct parse here is '\040PATHNA\r\n'ME. This is because the TELNET protocol has higher precidence than character set recognition. CWD\040'\040PATH\r\0NA'\r\0ME\r\n The correct parse here is '\040PATH\r\0NA'\rME. The second \r\0 occurred in the unshifted state, an is therefore interpreted at the end-of-line recognition level of precidence. Prior to RFC 2640, the precidence rules were immaterial. The two sets of rules did not intersect and there was no ambiguity. The only possible issue is whether RFC 2640 (or the MLST draft) should exlicity state the precidence rule. My feeling is the fact that the precidence rule MUST exist is obvious to anyone seriously setting out to implement the FTP, and there is no need in the MLST draft to explictly state so. Perhaps, if we ever do a complete replacement for RFC 959, merging it and all subsequent RFCs into a single document, we could add the explicit statement in deference to those who, after being hit with a 2x4, refuse to acknowledge the presence of a 2x4 because it was stated to be present. From ftp-wg-owner@hethmon.com Tue Jan 22 19:48:26 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15708 for ; Tue, 22 Jan 2002 19:48:25 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020122195357-59376-10 ; Tue, 22 Jan 2002 19:53:57 -0500 Received: from web21104.mail.yahoo.com ([216.136.227.106] [216.136.227.106]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020122195353-35178-9 ; Tue, 22 Jan 2002 19:53:53 -0500 Message-ID: <20020123004605.40342.qmail@web21104.mail.yahoo.com> Received: from [147.178.1.2] by web21104.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 16:46:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jan 2002 19:53:55 -0500 X-OldDate: Tue, 22 Jan 2002 16:46:05 -0800 (PST) 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: concrete pathname parsing examples > lundberg@vr.net 01/19/02 02:20PM > Subject: ftp.ipswitch.com:21 vs. Ftp rfc & ... > The intention of the FTP ... > is that the control connection > be usable by a human using the TELNET protocol. Good to hear this said out loud, thank you. > Let's examine some byte sequences. > ... the correct parse ... yields ... Helpful, thank you. > CWD\040PATH\0NAME\r\n > CWD\040PATH\08NAME\r\n > CWD\040PATH\377\367NAME\r\n May I suggest we also discuss these three examples? In rfc854 [Telnet] I see \0 often means NUL, \08 often means BS (Backspace), and \377\367 often means IAC EC (Erase Character), named back before characters commonly appeared as multibyte sequences. I had read rfc959 [Ftp] as making sense of all three of these examples, I had read rfc2640 [International Ftp] as making sense of only the last two, because of the presence of a \0 not preceded by \r in the first example. I think said here that a correct reading of rfc2640 makes sense of all three of these examples, by saying the explicit rfc2640 reference to the "" of the rfc959 BNF is metaphorical. I see rfc2234 tells us the BNF in the old rfc's was often metaphorical - news to me that something as recent as rfc2640 could be commonly understood to be purposefully imprecise in this same way. > CWD\040PATHNAME\r\n > PATHNAME ... > CWD\040PATH\r\0NAME\r\n > PATH\rNAME ... > CWD\040PATH\r\nNAME\r\n > PATH ... > CWD\040PATH\nNAME\r\n > PATH\nNAME ... > CWD\040PATH\0377\0377NAME\r\n > PATH\0377NAME I agree this is how the Ftp rfc's say these commands must be parsed. I think I also see the ftp.ipswitch.com:21 FtpServer includes UTF8 among the options of its 211 reply to FEAT without having chosen to parse these commands this way. > CWD\040PATH\rNAME\r\n > PATH\rNAME ... > CWD\040PATH\0377\0375\001NAME\r\n > PATHNAME ... > CWD\040PATH\0377\0375NAME\r\n > PATHAME ... > CWD\040PATH\0377NAME\r\n > PATHAME > CWD\040'\040PATH\r\0NA\r\n'ME\r\n > '\040PATH\r\0NA\r\n'ME ... > CWD\040'\040PATH\377\375\001NA\r\n'ME\r\n > '\040PATHNA\r\n'ME ... > CWD\040'\040PATH\r\0NA'\r\0ME\r\n > '\040PATH\r\0NA'\rME As for the these: I agree the more liberal ways you cite for sending \r and \0377 merit study, I especially appreciate the example of a char encoding other than UTF-8. New to me was the idea of separating "Telnet" from "\r\0 and \r\n" "end-of-line recognition": rfc2640 sends us explicitly to rfc854 [Telnet] to elaborate \r\0 handling. New to me was the idea that somehow the rfc2640's pathname = 1*(%x01..%xFF) ABNF rule does not preclude \0 in the pathname, in particular does not preclude \0 in the "raw" "any string not being a valid UTF-8 encoding" of mlst-14. > New to me By way of elaborating the rfc2640 English "pathnames are sequences of bytes" ... I was thinking that rfc959 defines a scheme for exchanging arbitrary byte sequences as pathnames and only then says please don't use the scheme for empty pathnames or pathnames that include \r or \n. I was thinking that rfc2640 defines a scheme - shortest-form UTF-8 encoding - for exchanging arbitrary char sequences as pathnames and only then says please don't use the scheme for empty pathnames or pathnames that include \0. Apparently this is wrong thinking? I'll post again to say more as I continue to clue in, presuming I still fall well short of clueing in completely. Thanks again in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Wed Jan 23 08:07: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 IAA07215 for ; Wed, 23 Jan 2002 08:07:23 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123081310-27869-9 ; Wed, 23 Jan 2002 08:13:11 -0500 Received: from web21102.mail.yahoo.com ([216.136.227.104] [216.136.227.104]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123081305-34634-8 ; Wed, 23 Jan 2002 08:13:06 -0500 Message-ID: <20020123130517.3989.qmail@web21102.mail.yahoo.com> Received: from [172.182.113.188] by web21102.mail.yahoo.com via HTTP; Wed, 23 Jan 2002 05:05:17 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jan 2002 08:13:08 -0500 X-OldDate: Wed, 23 Jan 2002 05:05:17 -0800 (PST) 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 UTF8 incoming/ anywhere? Anybody know the address of an FtpServer available for test, not written by me, that BOTH: 1) offers a conventional incoming/ folder 2) includes UTF8 among the options of its 211 reply to FEAT? I mostly want to play with pathnames: I'm likely to store my email address, maybe also a few bytes of \r \n \r\n, a nightly DELE of all incoming/ files would probably not interfere perceptibly with my use. Thanks in advance. Pat LaVarre P.S. > a conventional incoming/ folder For example, I see most of ftp://members.aol.com:21/*/incoming/ lets the world STOR and NLST/LIST/... but forbids RETR, MKD, DELE, RMD, RNFR:RNTO, .... I hear forbidding RETR is common for incoming/ folders. More ideal for me would be an FtpServer that let me RETR, but gave me known garbage back, rather than what I had STORed, to discourage abuse as effectively as the more conventional approach of completely denying RETR privilege. Most ideal for me would be an FtpServer that let me RETR once but erased what I read as a I read it, so we could discourage abuse and yet still test most of the function of RETR of new and strange pathnames. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Wed Jan 23 08:49:55 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08160 for ; Wed, 23 Jan 2002 08:49:54 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123085556-59657-10 ; Wed, 23 Jan 2002 08:55:56 -0500 Received: from web21105.mail.yahoo.com ([216.136.227.107] [216.136.227.107]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123085551-36477-8 ; Wed, 23 Jan 2002 08:55:51 -0500 Message-ID: <20020123134803.315.qmail@web21105.mail.yahoo.com> Received: from [172.182.113.188] by web21105.mail.yahoo.com via HTTP; Wed, 23 Jan 2002 05:48:03 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jan 2002 08:55:53 -0500 X-OldDate: Wed, 23 Jan 2002 05:48:03 -0800 (PST) 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: multi-line responses acceptable when? > Subject: Ftp-WG: to mlst-14 from mlst-13 > From: kre@munnari.oz.au > Date: Monday - January 14, 2002 2:01 AM > I'm not sure what you're getting at there? Am I wrong to infer Ftp folk commonly understand rfc2389 [Ftp Feature Negotiation] and mlst-14 to say .... Many kinds of replies must Never be multi-line replies? I'm guessing the replies that must Never be multi-line are the replies commonly parsed: the 125/150 to STOU, 213 to MDTM/SIZE, 227 to PASV, 229 to EPSV, and 257 to PWD/MKD. I'm wondering again now because I see mlst-14 repeats, almost verbatim from rfc2389 [Ftp Feature Negotiation], explicitly contrary "unless otherwise stated" English: 2.4. Server Replies Section 4.2 of [3] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT Implementors should note that the ABNF syntax (which was not used in [3]) used in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may be of the multi-line format described in [3]. > almost verbatim Vs. rfc2389, mlst-14 replaces "])" with "]) used" and inserts the paragraph break and ABNF. > I'm wondering again now I'm prompted to post because just recently I received a relevant paragraph offline: PASV is another one where it makes no sense for there to be a multi-line reply, had anyone ever really considered the issue before, I'm sure it would have been forbidden. Multi-line replies only make sense when the reply is essentially just meaningless text (intended for humans rather than for the client process)." > I'm wondering again now The final reason I wonder, I mentioned before here to no online reply, namely: I read rfc959 [Ftp] 5.4. Spontaneous Replies to say an FtpServer may choose from among such replies as: C> MDTM A S> 213 19980615100045.014 and: C> MDTM A S> 213-Please QUIT within five minutes. S> 213 19980615100045.014 and: C> MDTM A S> 213-19980615100045.014 S> 213 Please QUIT within five minutes. if it weren't that mlst-14 explicitly says the 213 replies to MDTM/SIZE must be single line replies. I see mlst-14 doesn't mention the 125/150 to STOU, 227 to PASV, 229 to EPSV, and 257 to PWD/MKD replies. I see mlst-14 doesn't say the 250 reply to MLST can't contain rfc959 Spontaneous Replies ... I'm also imagining people commonly understand that restriction to be implied. Thanks in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ftp-wg-owner@hethmon.com Wed Jan 23 09:22:31 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 JAA09500 for ; Wed, 23 Jan 2002 09:22:30 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123092820-8863-9 ; Wed, 23 Jan 2002 09:28:20 -0500 Received: from fw1.manulife.com ([216.208.177.162] [216.208.177.162]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123092815-24224-8 ; Wed, 23 Jan 2002 09:28:15 -0500 Received: by fw1.manulife.com; id JAA06060; Wed, 23 Jan 2002 09:20:28 -0500 Received: from mlismail00.manulife.com(10.200.40.23) by fw1.manulife.com via smap (V5.5) id xma005965; Wed, 23 Jan 02 09:20:14 -0500 X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: X-MIMETrack: Serialize by Router on MLILMAIL00/Servers/Manulife(Release 5.07a |May 14, 2001) at 01/23/2002 09:20:11 AM MIME-Version: 1.0 Date: Wed, 23 Jan 2002 09:28:17 -0500 X-OldDate: Wed, 23 Jan 2002 09:20:10 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: To: ftp-wg@hethmon.com Subject: Ftp-WG: unsubscribe From ftp-wg-owner@hethmon.com Wed Jan 23 09:39: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 JAA10518 for ; Wed, 23 Jan 2002 09:39:51 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123094537-61408-9 ; Wed, 23 Jan 2002 09:45:37 -0500 Received: from web21108.mail.yahoo.com ([216.136.227.110] [216.136.227.110]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123094532-37254-8 ; Wed, 23 Jan 2002 09:45:32 -0500 Message-ID: <20020123143743.69975.qmail@web21108.mail.yahoo.com> Received: from [172.182.113.188] by web21108.mail.yahoo.com via HTTP; Wed, 23 Jan 2002 06:37:43 PST MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-552026833-1011796663=:69733" Date: Wed, 23 Jan 2002 09:45:34 -0500 X-OldDate: Wed, 23 Jan 2002 06:37:43 -0800 (PST) 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: Fwd: concrete pathname parsing examples --0-552026833-1011796663=:69733 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline May I mention? Raw newbie that I am, for all these same examples of pathnames difficult to exchange uncorrupted, I'd also find helpful ... ... discussion of how correct Ftp implementations of "NLST" would pass these pathnames thru a "TYPE A" data connection, and discussion of how a correct Ftp implementations of "MLSD" would pass these pathnames thru a "TYPE L 8" data connection. Again, for many pathnames outside of 1*(x20-FE), I find I'm not able to make NLST/MLSD work except when I've written both the FtpClient and the FtpServer involved. Pat LaVarre P.S. I trust we all agree that ... A commonly understood standard for exchanging creative pathnames as command parameters ... lets the remaining text of the rfc's give us a clear standard for exchanging even creative pathnames in reply text. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ --0-552026833-1011796663=:69733 Content-Type: message/rfc822 Received: from [147.178.1.2] by web21104.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 16:46:05 PST Date: Tue, 22 Jan 2002 16:46:05 -0800 (PST) From: Pat LaVarre Reply-To: p.lavarre@ieee.org Subject: concrete pathname parsing examples To: ftp-wg@hethmon.com Cc: p.lavarre@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 1636 > lundberg@vr.net 01/19/02 02:20PM > Subject: ftp.ipswitch.com:21 vs. Ftp rfc & ... > The intention of the FTP ... > is that the control connection > be usable by a human using the TELNET protocol. Good to hear this said out loud, thank you. > Let's examine some byte sequences. > ... the correct parse ... yields ... Helpful, thank you. > CWD\040PATH\0NAME\r\n > CWD\040PATH\08NAME\r\n > CWD\040PATH\377\367NAME\r\n May I suggest we also discuss these three examples? In rfc854 [Telnet] I see \0 often means NUL, \08 often means BS (Backspace), and \377\367 often means IAC EC (Erase Character), named back before characters commonly appeared as multibyte sequences. I had read rfc959 [Ftp] as making sense of all three of these examples, I had read rfc2640 [International Ftp] as making sense of only the last two, because of the presence of a \0 not preceded by \r in the first example. I think said here that a correct reading of rfc2640 makes sense of all three of these examples, by saying the explicit rfc2640 reference to the "" of the rfc959 BNF is metaphorical. I see rfc2234 tells us the BNF in the old rfc's was often metaphorical - news to me that something as recent as rfc2640 could be commonly understood to be purposefully imprecise in this same way. > CWD\040PATHNAME\r\n > PATHNAME ... > CWD\040PATH\r\0NAME\r\n > PATH\rNAME ... > CWD\040PATH\r\nNAME\r\n > PATH ... > CWD\040PATH\nNAME\r\n > PATH\nNAME ... > CWD\040PATH\0377\0377NAME\r\n > PATH\0377NAME I agree this is how the Ftp rfc's say these commands must be parsed. I think I also see the ftp.ipswitch.com:21 FtpServer includes UTF8 among the options of its 211 reply to FEAT without having chosen to parse these commands this way. > CWD\040PATH\rNAME\r\n > PATH\rNAME ... > CWD\040PATH\0377\0375\001NAME\r\n > PATHNAME ... > CWD\040PATH\0377\0375NAME\r\n > PATHAME ... > CWD\040PATH\0377NAME\r\n > PATHAME > CWD\040'\040PATH\r\0NA\r\n'ME\r\n > '\040PATH\r\0NA\r\n'ME ... > CWD\040'\040PATH\377\375\001NA\r\n'ME\r\n > '\040PATHNA\r\n'ME ... > CWD\040'\040PATH\r\0NA'\r\0ME\r\n > '\040PATH\r\0NA'\rME As for the these: I agree the more liberal ways you cite for sending \r and \0377 merit study, I especially appreciate the example of a char encoding other than UTF-8. New to me was the idea of separating "Telnet" from "\r\0 and \r\n" "end-of-line recognition": rfc2640 sends us explicitly to rfc854 [Telnet] to elaborate \r\0 handling. New to me was the idea that somehow the rfc2640's pathname = 1*(%x01..%xFF) ABNF rule does not preclude \0 in the pathname, in particular does not preclude \0 in the "raw" "any string not being a valid UTF-8 encoding" of mlst-14. > New to me By way of elaborating the rfc2640 English "pathnames are sequences of bytes" ... I was thinking that rfc959 defines a scheme for exchanging arbitrary byte sequences as pathnames and only then says please don't use the scheme for empty pathnames or pathnames that include \r or \n. I was thinking that rfc2640 defines a scheme - shortest-form UTF-8 encoding - for exchanging arbitrary char sequences as pathnames and only then says please don't use the scheme for empty pathnames or pathnames that include \0. Apparently this is wrong thinking? I'll post again to say more as I continue to clue in, presuming I still fall well short of clueing in completely. Thanks again in advance. Pat LaVarre __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ --0-552026833-1011796663=:69733-- From ftp-wg-owner@hethmon.com Wed Jan 23 10:52:53 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13422 for ; Wed, 23 Jan 2002 10:52:52 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123105846-22937-13 ; Wed, 23 Jan 2002 10:58:46 -0500 Received: from alpha.ipswitch.com ([216.104.149.100] [216.104.149.100]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020123105838-60748-10 ; Wed, 23 Jan 2002 10:58:38 -0500 Received: from wks222 [216.104.149.222] by alpha.ipswitch.com (SMTPD32-7.05) id AC0FEBA4013E; Wed, 23 Jan 2002 10:51:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20020123130517.3989.qmail@web21102.mail.yahoo.com> Importance: Normal Date: Wed, 23 Jan 2002 10:58:41 -0500 X-OldDate: Wed, 23 Jan 2002 10:51:00 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Mark Symons" To: "FTPEXT Working Group" Subject: Ftp-WG: FEAT UTF8 incoming/ anywhere? Content-Transfer-Encoding: 7bit > Anybody know the address of an FtpServer > available for test, not written by me, that > BOTH: > 1) offers a conventional incoming/ folder > 2) includes UTF8 among the options of its > 211 reply to FEAT? You've been playing with the WS_FTP Server v3.00 server at ftp://ftp.ipswitch.com. You can download a 30 day evaluation copy of the software from: http://www.ipswitch.com In fact, do that and you'll be getting v3.01. Bear in mind that WS_FTP Server operates on Win NT/2000/XP only. The evaluation is fully functional with one exception: the SSL support is 40 bit instead of the 128 bit supported in the purchased version. Have fun playing. Mark Symons Ipswitch, Inc Augusta GA From ftp-wg-owner@hethmon.com Fri Jan 25 04:49: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 EAA27955 for ; Fri, 25 Jan 2002 04:49:31 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020125045513-8571-9 ; Fri, 25 Jan 2002 04:55:14 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020125045447-56170-9 ; Fri, 25 Jan 2002 04:55:08 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0P9o1807275; Fri, 25 Jan 2002 16:50:01 +0700 (ICT) In-Reply-To: <5922228.1011896065@localhost> References: <5922228.1011896065@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <7273.1011952201@brandenburg.cs.mu.OZ.AU> Date: Fri, 25 Jan 2002 04:55:11 -0500 X-OldDate: Fri, 25 Jan 2002 16:50:01 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Ftp-WG: Re: Comments from IESG on draft-ietf-ftpext-mlst Date: Thu, 24 Jan 2002 18:14:25 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Message-ID: <5922228.1011896065@localhost> | IESG today discussed the document, and have the following comments. I | presume you have to come out with a new version of the document. Yes, it looks like it... | Regardless, let me get comments on these comments. So, let's (WG) decide what should be done about each of these (some are no brainers and easy fixes). | (a) | The second paragraph of section 2.2 says, in part: | | Implementations are advised against converting a UTF-8 pathname to a local | encoding, and then attempting to invert the encoding later. | | I think this incorrectly confuses encodings with charsets. Yes, probably, this is outside my area of expertise (whatever that might be). | In particular, | I don't want an implementation that uses UTF-16 internally to refrain | from converting UTF-16 to UTF-8 on the wire. No, certainly don't want that. | I do want, however to | discourage _charset_ conversions. I suggest this be changed to read: Fine by me. | I also note that even with the changed wording this is slightly in | conflct with the recommendations in section 7.5.9, but I guess this is OK. I'll look at that. | (b) | Should the reference to RFC 2119 follow the form suggested in RFC 2119? I don't know, should it? Does anyone really care? | (c) | Section 3.4 starts: | | If we assume the existence of three files, A B and C, and a directory | D, and no other files at all | | but later it assumes the existence of files named "file6" and | "19990929043300 File6". Yes, I had noticed that one myself, but didn't think it really worthy of a fix, but I guess it should be done. I'll figure out a suitable fix to the "and no other files at all" so it doesn't have to say "and 19990929043300 File6" in the previous clause, and post that to the list later. | (d) | Section 7.1: | | For these purposes, the contents of a directory are whatever | file names (not pathnames) the server-PI will allow to be referenced | when the current working directory is the directory named, and which | the server-PI desires to reveal to the user-PI. | Earlier text refers to both "file names" and "directory names", implying | that they are seperate things, That's not intended, and I think the right fix should be to delete that notion from wherever it might be springing. They might be different, they might be interchangeable, that's up to the implementation. But ... | so this text seems to preclude including | directory names in MLSx responses. Should this say "file or directory | names"? that can certainly be done to handle any cases where files and directories are different beasts. | (e) | In the last paragraph of 7.2: | | Facts | should be provided in each output line only if they both provide | relevant information about the file named on the same line, and they | are in the set requested by the user-PI. | | Should this refer to section 7.9, since this is a forward reference | to the fact that the set is requestable? Sure, can do that easily. | (f) | | Section 7.5.1: | | ... | file -- a file entry | ... | | type-val = "File" / "cdir" / "pdir" / "dir" / | os-type | | Fact values are case-sensitive, right, Most are, but any ABNF strings are case insensitive (see the ABNF spec), so those strings should be case insensitive, so it really shouldn't matter whether it is "File" or "file". But I'm not sure that the WG ever truly considered this (the os-type would be case sensitive...) so now would be a good time - avoid things slipping by without proper consideration. | (g) | | Relevant to section 7.5.1.2 and 7.5.1.4: | | All the examples in section 7.7 show listings where, if present, | "type=cdir" and "type=pdir" are at the beginning, despite the warnings | that they may be anywhere. Even if it means modifying an example from | what was actually returned by an implementation, I think it'd be worth | having an example that has these entries elsewhere, since examples are | commonly heavily used during implementation. Hmmm - I really don't want to fake any examples, so doing this would mean finding (more likely, producing) a server that generates the listing in a different order. I'll see how easy it is to make my server do that - unless someone else has a server that generates MLSD output with cdir/pdir somewhere other than at the top (perhaps if the output is sorted by name...) | (h) | | Section 7.7.9: | | This server seems to use uppercase when fully-qualifying the type=cdir | entry on MLSD responses, and lowercase when fully-qualifying responses | to MSLT. This is a little confusing, so although the explanation does | mention that it is a case-independent NVFS, perhaps it could explicitly | say "and that's why it uses different case for the fully-qualified path | in different responses". Can do that I guess - certainly can't do any harm, but I'd have thought it really ought to be obvious enough... | (i) | The last example in section 7.8.1: | | S> MLST Type*;Size*;Modify*;Perm;Unique*; | | ... All of the facts supported by | this server are enabled by default. | | In the example response, Perm is not enabled by default. Oops ... and I thought my eyesight was better than that. That one I didn't notice. Thanks, will fix. After a couple of days (waiting for suggestions) I'll submit yet another draft... kre From ftp-wg-owner@hethmon.com Fri Jan 25 10:54:05 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 KAA05597 for ; Fri, 25 Jan 2002 10:54:03 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020125105954-32061-10 ; Fri, 25 Jan 2002 10:59:54 -0500 Received: from web21104.mail.yahoo.com ([216.136.227.106] [216.136.227.106]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020125105950-38269-9 ; Fri, 25 Jan 2002 10:59:50 -0500 Message-ID: <20020125155158.67349.qmail@web21104.mail.yahoo.com> Received: from [147.178.1.2] by web21104.mail.yahoo.com via HTTP; Fri, 25 Jan 2002 07:51:58 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 10:59:52 -0500 X-OldDate: Fri, 25 Jan 2002 07:51:58 -0800 (PST) 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: the mlst-14 hobglobins - file6, 15+21, etc. > > > A foolish consistency > > > is the hobgoblin of little minds ... > > ... 3.4 ... If we assume ... A B and C, ... D, > > and no other files at all but later ... > > "file6" and "19990929043300 File6". ... > I'll figure out a suitable fix Hmmm. Do we not mean to be asking the reader to judge independently which inconsistencies in the examples are meaningful and which are not? For example, I remember noticing: > month ... 01--12 ... day ... 01--31 ... > C> MDTM A > S> 213 19980615100045.014 > C> MDTM B > S> 213 19980615100045.014 > C> MDTM C > S> 213 19980705132316 ... > conclude that > both A and B were last modified at the same time > (to the nearest millisecond), and that > C was modified 21 days and several hours later. Here, June 15 + 21 days is June 36 aka July 6, since by the mlst-14 conventions cited we infer June contains only days numbered 1..30. Therefore file C was modified only "20" days and several hours later than files A and B, not "21" days and several hours later. Me, if I'd been here long enough to have a vote, I think I'd vote to make the actual English as imprecise as the seemingly intended meaning, for example: > ... conclude that > both A and B were last modified at the same time > (to the nearest millisecond), but that > C was last modified some time later. Would such a change be helpful/not? (I'm not clued enough into the culture here yet to know.) > > Date: Thu, 24 Jan 2002 18:14:25 +0100 > > From: ... > > Message-ID: <5922228.1011896065@localhost> Anybody have a copy of this original quoted in full? (I don't.) Pat LaVarre __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From ftp-wg-owner@hethmon.com Wed Jan 30 22:14: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 WAA07824 for ; Wed, 30 Jan 2002 22:14:10 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020130221949-19943-9 ; Wed, 30 Jan 2002 22:19:49 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020130221944-3556-8 ; Wed, 30 Jan 2002 22:19:45 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0V3B5W05908; Thu, 31 Jan 2002 10:11:10 +0700 (ICT) In-Reply-To: <01KDMXWC7BEM003WI0@mauve.mrochek.com> References: <01KDMXWC7BEM003WI0@mauve.mrochek.com> <5922228.1011896065@localhost> <5922228.1011896065@localhost> <01KDM3RBOAS2004MWZ@mauve.mrochek.com> <01KDM3RBOAS2004MWZ@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <5906.1012446665@brandenburg.cs.mu.OZ.AU> Date: Wed, 30 Jan 2002 22:19:47 -0500 X-OldDate: Thu, 31 Jan 2002 10:11:05 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: ned.freed@mrochek.com Subject: Ftp-WG: Re: Comments from IESG on draft-ietf-ftpext-mlst Date: Tue, 29 Jan 2002 08:30:09 -0800 (PST) From: ned.freed@mrochek.com Message-ID: <01KDMXWC7BEM003WI0@mauve.mrochek.com> | I'm OK with this -- in fact your wording is better than mine. OK, none of these bother me, and they don't seem to be bothering the rest of the WG, so that's what I'll do... kre From ftp-wg-owner@hethmon.com Thu Jan 31 08:52:36 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 IAA26419 for ; Thu, 31 Jan 2002 08:52:35 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020131085822-4319-10 ; Thu, 31 Jan 2002 08:58:22 -0500 Received: from E-newspaper ([210.71.181.206] [210.71.181.206]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020131085815-41413-8 ; Thu, 31 Jan 2002 08:58:16 -0500 Received: from ksmail by mail.ht.net.tw with SMTP id HjXKDEwjxLRtyOjMfL5zyCbP6v5; Thu, 31 Jan 2002 21:52:43 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_t9slg2sKjq3Ji0xwz" X-Mailer: MmYZLSpohQUCdxLKS4wboE12 X-Priority: 3 X-MSMail-Priority: Normal Date: Thu, 31 Jan 2002 08:58:18 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Net5.Fortune-telling.Online To: Dear.JP.Friends Subject: Ftp-WG: [Advertisement] Net5 E-newspaper This is a multi-part message in MIME format. ------=_NextPart_t9slg2sKjq3Ji0xwz Content-Type: multipart/alternative; boundary="----=_NextPart_t9slg2sKjq3Ji0xwzAA" ------=_NextPart_t9slg2sKjq3Ji0xwzAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQo8ZnJhbWVzZXQgcm93cz0qIGZyYW1lYm9yZGVyPSJOTyIgYm9yZGVyPSIwIiBmcmFt ZXNwYWNpbmc9IjAiIGNvbHM9Kj4NCjxmcmFtZSBzY3JvbGxpbmc9InllcyIgc3JjPSJodHRwOi8v aW1nLm5ldHM1LmNvbS9BRC9KUG5ld3MuaHRtIj4NCjwvZnJhbWVzZXQ+DQo8L2h0bWw+ ------=_NextPart_t9slg2sKjq3Ji0xwzAA-- ------=_NextPart_t9slg2sKjq3Ji0xwz--