Ftp-WG: FEAT UTF-8 in review

http://www.ietf.org/rfc/rfc2640.txt

> X-Listname: [email protected]
> ... NVT processing, obviously.

http://www.ietf.org/html.charters/ftpext-charter.html
http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt
http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt

> May 2002

Hey, wow, I just now (17 July) stumbled into this FEAT
UTF-8 draft, distinct from FEAT UTF8, courtesy the
links quoted.  Great stuff, thank you.

> To restore inter-operation with existing
implementations,
> the FTP should provide a means for the user
> to express its willingness to accept UTF-8 encoded
pathnames,
> and servers should not transmit UTF-8 encoded
pathnames
> without prior authorization from the user.

Yes!

But am I understanding correctly?  According to this
FEAT UTF-8 draft ...

> The assertion in [RFC2640] that CR NUL
> is not a Telnet end-of-line sequence is incorrect.
...
> RFC1123 ... accept either CR LF or CR NUL
> as representing Telnet end-of-line when received

Clients & servers should also liberally accept LF as
Telnet end-of-line, yes?

> When transmitting UTF-8 encoded characters,
> the shortest form should be used.

http://www.unicode.org says Must use shortest form, to
avoid the hole of a s*curity filter rejecting only
shortest-form and failing to reject a longer, not so
plainly equivalent, form, such as the UTF-8 outside of
*( %x20-7E / %x80-EF ) that isn't shortest form for
any char of the x0000..FFFF range.

> The ABNF for pathnames presented in [RFC2640] is
incorrect.
> ... the correct syntax is
> PATHNAME = *( %x20-7E )
> PATHNAME = *( %x20-7E / %x80-FF )
> both cases render moot all discussion
> about the use of the characters CR, LF, and NUL, in
pathnames.

Eh?

As a server, in a folder, I have a local filename that
includes a local Eol.

How should that filename appear in my NLST data,
supposing the client asked for FEAT UTF-8 NLST?

Shortest-form UTF-8 would commonly be x0A or x0D or x
0D 0A, depending on locale, sent as x0A or x 0D 00 or
x 0D 00 0A.

When should & must contradict, must wins, so I must
conclude that I must not use shortest form UTF-8 to
represent EOL in a path name?  I should use the next
shortest form i.e. x C0 8A and x C0 8D and x C0 8D C0
8A?

If that conclusion is correct, should we state it?  If
the shortest form UTF-8 encoding at the client or at
the server contains %x00-1F, then those bytes should
be transmitted as the next shortest form i.e. x C0 80
.. x C0 9F?

> allow internationalized pathnames
> support internationalization of response text

Distinct requirements, the first alone more commonly
useful, aye, thank you.

> OPTS <SP> UTF-8 [ <SP> NLST ] <CRLF>

Why is NLST an option?  Why not require it in the
syntax.  Why not say every path name is UTF-8 or not? 
And what about LIST and MLST and MLSD and so on?

Pat LaVarre

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com