Ftp-WG: mlst-16 will correctly say *( %x20-7E )?

Robert E:

I'm not trying to be difficult, but I must be
completely missing something ...

> From: Robert Elz [mailto:[email protected]] 
> ... I'm currently working out just where and how
> to say that CRLF isn't handled (suggestions welcome)

How about we disavow and override the rfc2640 ABNF for
PATHNAME, as in the utf-8 draft?

> ... names ...
> Whether any of those make sense
> to any particular implementation
> is up to the implementation.

Eh?  I'm not sure I understand this.  It's not ok for
a client or server to offer the other a name it can't
handle, is it?  How can the client or server decide
what the other can handle, except by assuming that
PATHNAME = *( %x20-7E ) until told otherwise?

> There is one particular set of characters
> that we can't transfer in a path name (CRLF) but
> that's it.  All the rest are OK.

So we agree rfc2640 is incorrect here?

Our next question then is how incorrect.  Me, I
thought, in practice, NUL in a path name was as
problematic as CR or LF.  And SP used to be bad.  But
if we say "All the rest are OK", then I must conclude:

> From: Gregory A Lundberg [[email protected]]
> you cannot send ( %x00-1F / %x7F )
> on ANY FTP command or reply and expect correct
> interoperation.

Robert E disputes this?  Gregory L stands by it?

>
http://www.ietf.org/internet-drafts/draft-ietf-ftpext-utf-8-option-00.txt
> ...
> The ABNF for pathnames presented in [RFC2640]
> is incorrect ... the correct syntax is
> PATHNAME = *( %x20-7E )...

Robert E also disputes this?

> Note: what is being specified here is
> what the protocol can transfer.
> ... The protocol allows the name \0\0\0
> (and treats it differently from \0\0 and \0\0\0\0)

Yes.

> and all of that works just fine.

Not in real life.

> That is only just peripherally related
> to the set of names
> that any particular client and server will allow.

I think I see we're discussing three sets of names.

1) In theory, the protocol can transfer a large set of
names.  

2) The set of names actual implementations can
transfer is considerably smaller, and awkward to
measure automagically, because of how creatively
implementations fail when assaulted with unusual
names.

3) After we agree what name was transferred, then we
can ask if the file system of the client or server can
give that name to a folder or a file, and if the file
system can distinguish that name from another.

I think I hear Robert E saying the Ftp Rfc's should
define only (1) and Gregory L saying the Ftp Rfc's
should define a (1) similar to (2).

How irretrievably confused am I?

Curiously yours, Pat LaVarre


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com