Subject: Ftp-WG: FEAT UTF8 does NOT mean \r and \n ok in pathnames?

From: Pat LaVarre <[email-masked]>
Date: Fri, 18 Jan 2002 19:34:18 -0500

> > To say the misbehaviour is on my end,
> No-one is saying that, are they?

I think I've fuzzily been told No, but pending
volunteer elaboration, I'll try to ask more clearly:

Does "everyone know" we only intend real Ftp
implementations to support non-empty pathnames made up
of nothing but SP, printable US-Ascii, and Unicode
x80..FFFF converted to shortest-form UTF-8:

        pathname = 1*(%x20-7E / %x80-DF)

?

Otherwise, I really really really don't understand a
myriad of things I see.  In detail:

> > > http://www.m-w.com/cgi-bin/dictionary
> > > tongue-in-cheek [=] whimsically exaggerated
...
> > Maybe "everyone knows" that
> > rfc2640 [International Ftp] is tongue-in-cheek
> > where it says it has abandoned the rfc959
> > restriction forbidding \r and \n in pathnames?
>
> > Just as rfc959 [Ftp] was tongue-in-cheek
> > where it said \0 may appear in pathnames?
...
> [email-masked]
> Thursday - January 17, 2002 9:30 PM
...
> No.
...
> ... \0 ... none will ever be sent ...

Ouch.  I'm so totally not getting it.

> [We commonly read rfc959 to mean
> that \0 may appear in pathnames
> and yet we commonly read rfc959 to mean
> that \0 is never sent in a pathname to an
> FtpServer whose NVFS happens not to support \0.]

You didn't just say that, did you?  To me this
erroneous paraphrase reads like an irreducible
dialectic?  Fun, aye ... but not concretely
realisable?

> ... that they aren't forbidden
> doesn't mean that any particular server
> is required to support names like that.
...
> on this VFS, there are no legal pathnames
> that contain a \0 so none will ever be sent,

May we focus here a moment?

I'm thinking interoperability suffers unless people
commonly read the Ftp rfc/draft-ietf's to be saying:

1) All Ftp implementations must parse all Ftp
pathnames correctly.
2) rfc959 FtpClient's matter.
3) The rfc's state precisely the pathname ABNF that
everyone should parse.
4) rfc2234 [ABNF] precisely defines the meaning of the
ABNF in the rfc's.

As yet, in my newbie ignorance, I find I can't
persuade myself that people do commonly read the Ftp
rfc/draft-ietf's this way?

> 1) All Ftp implementations must parse all Ftp
pathnames correctly.

Is this in dispute?

Any pathname permitted by the rfc BNF may appear as
the parameter to MKD/STOR, precisely in order to
determine if the NVFS of the FtpServer supports that
pathname .  Any pathname permitted by the rfc BNF may
appear as the parameter to CWD/RETR, when extracted
from an ftp://... Url according to rfc1738 [Url's].

Any pathname permitted by the rfc BNF may appear in
NLST/MLSD data.

Any Ftp implementation that improperly parses such a
pathname - seeing more commands, seeing catenated
commands where none exist - flatly violates the rfc's.

Maybe nobody cares.  But to say improper parsing is
not a violation is like saying a C compiler doesn't
have to parse string literals properly.  De facto
truth, I agree.  But a de jure crime, unequivocally.

> 2) rfc959 FtpClient's matter.

It seems this IS in dispute?

An FtpServer can passively ask to see only rfc959
pathnames by not replying 211 to FEAT or by neglecting
to include a UTF8 option there.

But no protocol exists to protect rfc959 FtpClient's
from encountering rfc2640 pathnames in NLST/MLSD data.

> 3) The rfc's state precisely the pathname ABNF that
everyone should parse.

It seems this IS in dispute?

rfc959 says 1*(%x00-7F) ... but Everyone knows %x00
%x0A %x0D (NUL LF CR) don't work and rfc959 says the
other Telnet control bytes can have effect e.g.
"a\008cde" may mean "cde" because %x08 is BS i.e.
backspace.

rfc2640 says 1*(%x01-FF).  Thus rfc2640 abandons %x00
NULL without comment but leaves %x0A %x0D and the
other Telnet control bytes in place.

Why bother to say less than arbitrary sequences of
bytes/chars work - why bother to forbid empty
pathnames and %x00 NUL and so on - without setting
forth a common goal of a BNF we can credibly expect
everyone to work to parse properly?

4) rfc2234 [ABNF] defines the meaning of the ABNF in
the rfc's.

rfc2640 actually says:

pathname = 1*(%x01..%xFF) ; in ABNF format [ABNF].
[ABNF] [=] RFC 2234, November 1997

But rfc2234 defines the ".." syntax nowhere.

This is nothing but another almost weightless straw on
the camel's back.

But this camel is flat on the ground.

> I'm thinking interoperability suffers ...
> As yet, in my newbie ignorance, ...

I think I see that "everyone knows" we only intend to
work jointly to support non-empty pathnames made up of
nothing but SP, printable Ascii, and Unicode x80..FFFF
converted to shortest-form UTF-8:

        pathname = 1*(%x20-7E / %x80-DF)

Even there I'm guessing we might not work too hard to
properly parse the Unicode control chars x80-A0 and
xAD i.e. the shortest-form UTF-8 of %xC2 %x80 to %xC2
%xA0, and %xC2 %xAD.

But every time I try to say this, somebody pops up and
says no of course not.

How many fundamentals have I got wrong here?

Anybody out there feel at all able to begin to clue me
in?

Thanks again in advance.    Pat LaVarre

P.S. I launched a separate thread titled "Ftp-WG:
transfers of \r, \n, \r\n" to try and get me straight
on what a "TYPE A"scii data transfer of NLST/MLST (but
never MLSD) data does.

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