Subject: Ftp-WG: FEAT UTF-8 in review

From: Pat LaVarre <[email-masked]>
Date: Wed, 17 Jul 2002 15:02:35 -0500

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

> X-Listname: [email-masked]
> ... 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

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Thu, 18 Jul 2002 18:38:30 -0500

> Clients & servers should also liberally accept LF as

The only eol talked about for telnet are CRLF and CRNUL, the telnet allows
others as local options.  The problem is you don't know what is eol, except
that it's not going to be one of the 96 graphical ASCII characters.

> any char of the x0000..FFFF range.

From the point if view of the FTP, 'should' is good enough.  Let's allow
that there may be good and valuable reasons for some applications to ignore
the requirement.

> supposing the client asked for FEAT UTF-8 NLST?

It cannot appear on ANY FTP command or response.  Sorry.

> be transmitted as the next shortest form i.e. x C0 80

I avoided the issue in this draft as being too contentious.  I'm happy if
people just realize that you cannot send ( %x00-1F / %x7F ) on ANY FTP
command or reply and expect correct interoperation.

> And what about LIST and MLST and MLSD and so on?

I only specified NLST because I don't see LIST as being useful for automata,
and MLSx already seems to handle the issue.