Ftp-WG: Re: MLST draft - NUL CR LF again

[BC [email protected]]

> From: Gregory A Lundberg [[email protected]]
> Sent: Wed 4/24/2002 3:28 PM 

> It just bugs me
> that we can support any file, directory
> or path name EXCEPT those
> which include the Telnet EOL.

Bugs me too.

> > > http://www.ietf.org/rfc/rfc854.txt
...
> > I thought not-shortest form UTF-8
> > ... an evil to be discouraged?
...
> It is.  But there is no other way
> to unambiguously separate Telnet end-of-line
> (CR LF and CR NUL) from data characters
> with the same encoding.

Sorry, too fast for me.

I thought Telnet by design Can exchange lines of
completely arbitrary content and length?  Yes CR LF
ends a line.  To send a line with CR inside, to escape
the CR, send CR NUL instead.  Always on receipt of CR
NUL, substitute CR.

This is unambiguous on paper ... no?

For example, we could send the six byte command "STOR
\r" as the nine bytes "STOR \r\0\r\n" to create a file
named by the one byte string containing only x0D CR.

Somehow in real life Telnet is less robust?

You're saying in some sense CR NUL is also a Telnet
Eol?  And I've seen actual implementations accept NUL
and LF as Eol?

Somehow it is not properly rfc761 conservative to let
real live human people type the three traditional
platform-specific end-of-line encodings (LF, CR, and
CR LF) in their path names?

Maybe we're trying to say Eol in an Ftp path name is
x0A LF only, and systems will vary over whether they
will report more than one file as having precisely
this same path name?

Thanks again in advance,    Pat LaVarre



-----Original Message----- 
From: Gregory A Lundberg [mailto:[email protected]] 
Sent: Wed 4/24/2002 3:28 PM 
To: [email protected]; [email protected] 
Cc: 
Subject: Ftp-WG: Re: MLST draft - NUL CR LF again


> I thought not-shortest form UTF-8 was broadly
> accepted as an evil to be discouraged? 

It is.  But there is no other way to unambiguously
separate Telnet end-of-line (CR LF and CR NUL) from
data characters with the same encoding. 

It just bugs me that we can support any file,
directory or path name EXCEPT those which include the
Telnet EOL. 

> Where software does interpret the non-shortest 
> forms, security issues can arise. 

An FTP conforming implementation SHOULD NOT transmit
non-shortest form UTF-8, but it MUST properly
interpret it.  That was already spelled out in both
959 and 1123 long before UTF-8 came along. 

> To address this issue, the Unicode Technical
> Committee has modified the definition of UTF-8 to
> forbid conformant implementations from interpreting 
> non-shortest forms for BMP characters, and clarified

> some of the conformance clauses. 

Since they did not specify alternate encodings for
legacy character sets, there will be times their
mandate MUST be ignored. 

This is a SHOULD NOT requirement and we have a case
where their requirement can not be applied; unless
they provided some OTHER form of representation for
the CR LF and NUL characters elsewhere in the
character sets. 

> I'm not at all clear on what we mean to say about
> the bytes x00..1F that include the x 0D 0A CR LF
> that appear in pathnames created by best of breed
> Gui's such as the classic MacOS. 

It is specifically those instances which are why I'm
loath to have to turn around and clearly state that a
file, directory or pathname MUST NOT include UTF-8
encodings 0x00 through 0x20. 

...


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/