Ftp-WG: Re: UTF-8 pathnames: pathname nature & length

> > The draft therefore precludes the use of some control characters
> > such as tab, bell, backspace, CR, LF as part of pathname
> > constituent characters.  The use of such characters in the
> > native pathnames may be strange, but should not be excluded
> > by a FTP server complying to the draft.  One example is
> > Linux on which a file "abc^Gdef.txt" (read as "abc" control-G
> > "def.txt") is created on-purpose (perhaps to give a sound for
> > that important file), or accidentally (perhaps due to telnet
> > terminal/dial-up mess-ups).  The user logins in via FTP but the
> > complying FTP server cannot send the filename because ^G is
> > not a valid pathname, and user cannot delete the file because
> > a complying client cannot send the filename.
> >
> > For that reason, I tend to agree with RFC2640 more.
> 
> You would be wrong.

Saying this doesn't explain how using the draft's pathname defintion
of:
         PATHNAME = *( %x20-7E / %x80-FF )
could solve the above for draft-compliant FTP servers and clients.




> Consider: what will you do when you send a pathname containing the ASCII DEL
> character, such as:
> 
> RETR myfile(%x7F)DELE myfile
> 
> where (%x7F) is the DEL character.
> 
> A compliant FTP server which implements command editing, as it is
> *specifically* allowed to do by RFC 959, could interpret the DEL as "erase
> line".
> 
> That RETR command isn't a RETR command, it's a DELE command.

(1)  RFC959 does not read as "*specifically* allowed to do" for command
editing.  It does read as "
      Servers are under no obligation to provide for editing 
      of command lines and may require that it be done in the
      user host.
".

(2) If Erase Line (EL) function is what you intended to illustrate,
then RFC854 will let the server see:
      RETR myfile<IAC><EL>DELE myfile
where
      <IAC>=%xFF and <EL>=%xF8

There is no significance in the character %x7F.  If erasing a
character is needed in an edit-supporting server, the client
should be sending:
      RETR myfile3<IAC><EC>4 CRLF
to retrieve "myfile4",  not
      RETR myfile3<%x7F>4 CRLF

"myfile3<%x7F>4", on the other hand, remains as it is.  On 
Windows, for instance, you can create "myfile3<%x7F>4.txt" and
have it listed on Explorer as "myfile3|4.txt" where "|" is
a black block to display the <%x7F> character.  How do you operate
on such a file then without allowing <%x7F>?




> The black-hats love this sort of mistake.
What are "black-hats"?


> Traditionally, the FTP does not inherently imply any length 
> restrictions.
True.  It is possible that due to the edit-supporting option
that RFC959 allowed, pathnames unedited could potentially be 
very very long with repetitions of "<IAC><EC>4" in the above
example, yet the actual realized pathname is very short.
But in view of modern day business concerns about security,
bandwidth cost, hackers, attacks, etc, some form of byte
length restriction is good.

How many edit-supporting clients and servers are there?





> > The draft recognises that there are multiple lengths of
> > encodings for a given UCS4 character (though I don't really
> > see how if one sticks to the UCS4-->UTF8 encoding by range,
> > and rejects invalid UTF8 encodings during UTF8-->UCS4
> > translations).
> 
> The black-hats, of course, don't particularly care about "rules".
> 
> Also, neophites can mis-code the routine.  It's real easy to just punt and
> use the 6-byte (longest-possible) UTF-8 encoding for everything.

For these cases, they're not UTF-8-encoding-compliant.
The draft recommends the use of shortest-possible encoding,
which is already recommended by UTF-8 encoding.  As for
the example of "just punt and use 6-byte for all", that's
on the decoding side.  Perhaps the draft could do better 
by saying how a server/client could/should/must behave
upon encountering an invalid string that is supposed to 
be UTF-8-encoded.  Just a suggestion.


> >  Regardless, there may be a need to define
> > a maximum number of bytes for the UTF-8 encoded pathname
> > so that servers and clients can allocate relevant amount
> > of resources (eg. memory) to handle UTF-8 pathname processings
> > when they comply to the draft.  Beyond the stated maximum
> > number of bytes, the pathname is categorically considered
> > invalid.  The purpose is primarily to prevent the exploitation
> > through overflowing of buffers or memory/CPU resource abuse by
> > sending lengthy pathnames.
> 
> Nah.  Let the server decide its own maximum length and 501 the command if it
> does not like it.  Similarly, the client can discard/truncate any reply
> which exceeds the length.

Really any length?  Is that part of the draft?  I didn't know
until you say so.  So a FTP server complying to your draft
may decide that 128-byte pathname is maximum for its English
native file system, and when a client issues a 128-character
pathname encoded as 768-byte (each UCS4 character requiring
6-byte encoding) UTF-8 sequence to the FTP server, it gets
rejected.  The draft could do better by stating such length
requirement behaviors.



> Put another way: once we set a limit (N), the OS vendors will start allowing
> pathnames which are (N+1) long.

Without having a section that deals with the length limits
on characters and/or encoded byte-lengths, we already have a
problem making server & client talk when they both comply
to your draft.



Best Regards,
Melvin Chin
XPS Team
SoftML




===================END FORWARDED MESSAGE===================

Paul Hethmon
[email protected]
http://www.hethmon.com