The locale and character set of the filename is actually irrelevant to all
of this discussion. What is needed is to be able to pass a filename to the
system that will be recognized on that system. This only requires a way of
specifying an 8-bit quantity to be passed over a 7-bit wire, and the rfc
1342 mechanism does just fine for doing that.
At least two implementors at the Columbus session indicated that this assertion
is in fact false on some systems. They asserted that on some operating systems
file names have to be qualified with the character set they are written in.
Applications running on those systems that open files can specify the character
set for the file name and files can and do have different names (represented by
a different string of octets) in different character sets. (Of course a
fallback default that applies when no character set is explicitly specified.)
There was also some indication that some of the proposed NFS extensions in fact
make this stuff happen on a network-wide basis. I don't see how this affects
our situation since the file names are always implicitly qualified by some kind
of location information, but I thought I'd better mention it.
There are obviously various different ways the character set information could
be carried -- the RFC1342 mechanism is one, an additional parameter is another.
We could even put the encoding in yet another parameter. (Frankly, I find this
considerably more natural than using RFC1342 and just ignoring the character
set specification.)
There is also the question of how this information gets handled by an FTP
client -- it could be made part of the filename, or it could be handled with a
private mode setting, or ... ? I don't know if these issues have really be
resolved yet. But until we do know how they get resolved we won't be able to
define a meaningful FTP client interaction model that handles 8-bit file names.
Since I'm not one of the people who asserted that these choices have been made
in various operating systems I have no way to assess the validity of these
points.. But I do have to respect the positions presented by attendees of the
working group meeting; I cannot simply discuss these issues as being
nonexistent.
Thus far the points I see in this discussion are:
(1) Specifying that RFC1342 mechanisms be used for the filename parameter
is an incompatible change that will in fact break existing implementations.
It also uses employs only part the RFC1342 mechanism; the result is
a fairly ugly mish-mash.
(2) There are lots of hidden and subtle issues that are a LONG way from being
worked out to the point where this stuff will really be able to
interoperate.
(3) Work is underway in another IETF working group to formalize a much more
general mechanism for locating network resources. Not only do the URL
Working Group's URIs have the potential of solving these problems across a
wider range of applications than just email, the URL group is focused on
this one issue. They are therefore in a much better position to address
this problem than we are. All we need to do is define a URI-based access
type, which can easily be done in a separate document.
Given this situation I think the only viable choice is to leave the filename
stuff alone for now. And unless I see some compelling reason for us to continue
to grapple with these issues, I vote we toss them over to the URL folks to
worry about.
Ned