Subject: Ftp-WG: Re: receive "\n" as NOT obvious as send "\r\xFF"?

From: Pat LaVarre <[email-masked]>
Date: Mon, 14 Jan 2002 19:56:36 -0500

(subject was: Ftp-WG: to mlst-14 from mlst-13)

> > re how commonly FtpServer's
> > have been liberally accepting \n as meaning \r\n.
...
> [email-masked] 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 <mailto:[email-masked]>

> [email-masked]
> [email-masked]

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 [email-masked] but I also explicitly cc
[email-masked] when I post from
[email-masked].

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: Alun Jones <[email-masked]>
Date: Tue, 15 Jan 2002 12:22:49 -0500

>mention excessively liberal Ftp receivers read \r\n in

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.

>having foresworn this popular example of excessive

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.

>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.

>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.

>meant to relate those "tricks of the trade" we wish

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 [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.