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

I followed the UTF-8 discussion and took a look at 
"draft-ftpext-utf-8-option-00.txt" and "RFC2640".

On the draft, in section 5, "ABNF for Pathnames", the draft
writes:  "
When UTF-8 encoding is not present, the correct syntax is
      PATHNAME = *( %x20-7E )
When UTF-8 encoding is in use, the correct syntax is
      PATHNAME = *( %x20-7E / %x80-FF )
".

while RFC2640 tries to allow pathnames to contain CRLF and
<SP> and recommends "
pathname = 1*(%x01..%xFF) ; in ABNF format [ABNF].
".

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.

In addition, I think it's a good thing that the draft examines 
security more closely regarding the impact of misinterpreting 
UTF-8 encodings.  It may be also in scope to look at the length 
restriction on any submitted UTF-8 pathnames from client 
to server, and any UTF-8 pathname responses from server to 
client.

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).  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.  



Best Regards,
Melvin Chin
XPS Team
SoftML




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

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