Subject: Ftp-WG: Fwd: concrete pathname parsing examples

From: Pat LaVarre <[email-masked]>
Date: Wed, 23 Jan 2002 09:45:34 -0500

May I mention?

Raw newbie that I am, for all these same examples of
pathnames difficult to exchange uncorrupted, I'd also
find helpful ...

... discussion of how correct Ftp implementations of
"NLST" would pass these pathnames thru a "TYPE A" data
connection, and discussion of how a correct Ftp
implementations of "MLSD" would pass these pathnames
thru a "TYPE L 8" data connection.

Again, for many pathnames outside of 1*(x20-FE), I
find I'm not able to make NLST/MLSD work except when
I've written both the FtpClient and the FtpServer
involved.

Pat LaVarre

P.S. I trust we all agree that ...

A commonly understood standard for exchanging creative
pathnames as command parameters ... lets the remaining
text of the rfc's give us a clear standard for
exchanging even creative pathnames in reply text.

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

Subject: concrete pathname parsing examples
From: Pat LaVarre <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 22 Jan 2002 16:46:05 -0800 (PST)

> [email-masked] 01/19/02 02:20PM
> Subject: ftp.ipswitch.com:21 vs. Ftp rfc & ...
> The intention of the FTP ...
> is that the control connection
> be usable by a human using the TELNET protocol.

Good to hear this said out loud, thank you.

> Let's examine some byte sequences.
> ... the correct parse ... yields ...

Helpful, thank you.

> CWD\040PATH\0NAME\r\n
> CWD\040PATH\08NAME\r\n
> CWD\040PATH\377\367NAME\r\n

May I suggest we also discuss these three examples?

In rfc854 [Telnet] I see \0 often means NUL, \08 often
means BS (Backspace), and \377\367 often means IAC EC
(Erase Character), named back before characters
commonly appeared as multibyte sequences.

I had read rfc959 [Ftp] as making sense of all three
of these examples, I had read rfc2640 [International
Ftp] as making sense of only the last two, because of
the presence of a \0 not preceded by \r in the first
example.

I think <[email-masked]> said here that a correct
reading of rfc2640 makes sense of all three of these
examples, by saying the explicit rfc2640 reference to
the "<pathname>" of the rfc959 BNF is metaphorical.

I see rfc2234 tells us the BNF in the old rfc's was
often metaphorical - news to me that something as
recent as rfc2640 could be commonly understood to be
purposefully imprecise in this same way.

> CWD\040PATHNAME\r\n
> PATHNAME
...
> CWD\040PATH\r\0NAME\r\n
> PATH\rNAME
...
> CWD\040PATH\r\nNAME\r\n
> PATH
...
> CWD\040PATH\nNAME\r\n
> PATH\nNAME
...
> CWD\040PATH\0377\0377NAME\r\n
> PATH\0377NAME

I agree this is how the Ftp rfc's say these commands
must be parsed.

I think I also see the ftp.ipswitch.com:21 FtpServer
includes UTF8 among the options of its 211 reply to
FEAT without having chosen to parse these commands
this way.

> CWD\040PATH\rNAME\r\n
> PATH\rNAME
...
> CWD\040PATH\0377\0375\001NAME\r\n
> PATHNAME
...
> CWD\040PATH\0377\0375NAME\r\n
> PATHAME
...
> CWD\040PATH\0377NAME\r\n
> PATHAME

> CWD\040'\040PATH\r\0NA\r\n'ME\r\n
> '\040PATH\r\0NA\r\n'ME
...
> CWD\040'\040PATH\377\375\001NA\r\n'ME\r\n
> '\040PATHNA\r\n'ME
...
> CWD\040'\040PATH\r\0NA'\r\0ME\r\n
> '\040PATH\r\0NA'\rME

As for the these:

I agree the more liberal ways you cite for sending \r
and \0377 merit study, I especially appreciate the
example of a char encoding other than UTF-8.

New to me was the idea of separating "Telnet" from
"\r\0 and \r\n" "end-of-line recognition": rfc2640
sends us explicitly to rfc854 [Telnet] to elaborate
\r\0 handling.

New to me was the idea that somehow the rfc2640's
pathname = 1*(%x01..%xFF) ABNF rule does not preclude
\0 in the pathname, in particular does not preclude \0
in the "raw" "any string not being a valid UTF-8
encoding" of mlst-14.

> New to me

By way of elaborating the rfc2640 English "pathnames
are sequences of bytes" ...

I was thinking that rfc959 defines a scheme for
exchanging arbitrary byte sequences as pathnames and
only then says please don't use the scheme for empty
pathnames or pathnames that include \r or \n.

I was thinking that rfc2640 defines a scheme -
shortest-form UTF-8 encoding - for exchanging
arbitrary char sequences as pathnames and only then
says please don't use the scheme for empty pathnames
or pathnames that include \0.

Apparently this is wrong thinking?

I'll post again to say more as I continue to clue in,
presuming I still fall well short of clueing in
completely.

Thanks again in advance.    Pat LaVarre

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