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

From: Pat LaVarre <[email-masked]>
Date: Tue, 15 Jan 2002 18:43:31 -0500

> > To mention explicitly
> > that people read \r\n where \n was written
> > would be to mention new protocol.
...
> [email-masked]

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