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

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

BTW.  On the other side of the coin .. in the BCP-form I-D, I'm thinking
about stepping up and saying that user-FTP implementations should not limit
line length at all, but may limit line length, and that the minimum limit
thay can use is 126 total octets.  server-FTP implementations should not
limit line length either, but will probably choose a limit appropriate to
the host file system.

Why 126?  Because it's one less than 127, which is the maximum unsigned
value in a 7-bit byte.  The idea being that if you're using length/data
encoding (say, a Pascal lstring value on the old TI-990 Pascal compiler I
used to use, where the first byte was the length of the following string)
and your strings are limited to 128 total bytes, some C shims will need one
byte to store the terminating NUL.

Why place a low-end limit on the maximum line length, but recommend against
any upper-end limit?  To encourage inter-operation.  Taking away the 5 bytes
for the command, most pathnames will probably fit in the 121 remaining
bytes.  By the current requirements, it's perfectly acceptable to place a
limit on pathnames of, say, 1 byte.  While I could envision a server-FTP
with that limit (maybe it only needs to store 95 files, ever .. maybe it's a
special purpose device control), it certainly would not make for a very
usable user-FTP talking to other servers.

Is 126 arbitrary?  Yes.  But any limit of this try is arbitrary.  Placing a
lower-limit on the maximum line length, while arbitrary, will not effect
inter-operation.  Placing an upper-limit on the maximum line length will.