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

> > Traditionally, the FTP does not inherently imply any length
restrictions.
>
>   OS however usually does.

So?  Which operating system shall we use at the "Internet Standard"?  How
about MS-DOS, it's widely deployed, fairly stable, and I'm sure the Unix
world would find working with a 64-character total limit on pathnames quite
refreshing.

>  Black hats shouldn't matter at all -- if the standard is unambiguous, no
> problems would happen, no matter what is actually passed over the line.

The recommendation I'm making is marrying what I'm told is the UTF-8
governing body's recommendation.  The only thing I'm adding is that after
changing to the shortest form it may look like a character with special
meaning (say, CR) but it is NOT that character because it does not have the
associated special meaning.

So are you objecting to that addition?  Or are you objecting to "wasting the
space" by re-stating the existing recommendations in case the reader is
unaware of those recommendations?

>   Even though my objections to UTF-8-ization of FTP and proposals to
> declare binary transparency, as telnet does, and leave this "problem"
> alone, fell on the deaf ears here, I am happy that for many years this
> group is developing unusable standard modifications that no one is going
> to use -- de-facto standard is to just ignore obsolete ASCII-only
> requirement for filenames, and it works just fine, thank you very much.

Whose defacto standard?

I have a rather largish install base and I'd hazard to say that virtually
all of my users adopt the suggested restrictions on pathnames, which even
exclude certain displayable ASCII characters.  The only point they tend to
want to change from the suggested restrictions is to allow spaces in
pathnames.

(NB. I'm not "selling" those restrictions.  As I see it, the reason they're
in the software is because someone, some time in the past, realized they
SHOULD have been there all along.  In other words, things are as they should
be.  The suggestion, then, is to follow the requirements of the existing
RFCs and the user-configurable option is to allow you to set aside those
requirements when you need to.  The only quibble I have is that our option
is to close down a normally-open case, when it should be to open up a
normally-closed case.  But that's a discussion for the implementor's mailing
list, not here.)


To your basic thesis:

Yes, I agree, the FTP is, both  historically and currently, incapable of
transparently exchanging the full range of possible pathnames.

And, yes, I agree, that this must be fixed.

My point is that the attempts so far have failed because they do not
inter-operate properly with existing implementations.  While I can suggest
fixes to the problem of inter-operation, trial balloons on how to fix the
rest of it met with sufficient resistance that I removed them from the I-D.