Subject: Ftp-WG: to mlst-14 from mlst-13

From: Pat LaVarre <[email-masked]>
Date: Sat, 12 Jan 2002 09:02:56 -0500

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
<[email-masked]> 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
<http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-13.txt>
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: Robert Elz <[email-masked]>
Date: Mon, 14 Jan 2002 04:05:49 -0500

Date:        Sat, 12 Jan 2002 09:02:56 -0500
    From:        Pat LaVarre <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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
  | <[email-masked]> 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
  | <http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-13.txt>
  | 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: Alun Jones <[email-masked]>
Date: Mon, 14 Jan 2002 11:48:00 -0500

At 03:05 AM 1/14/2002, Robert Elz wrote:
>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 [email-masked]
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.