[Top] [All Lists]

RE: 8-bit filenames and MIME

1993-04-14 21:08:22
<< 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.)

And on those systems the character set would HAVE to be specified as part of
the RFC1342 string; it couldn't be defaulted to unknown. It's a
system-dependent string that has two parts: a character set name and the
file name.

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

I'm not aware of those proposals. They may make sense for some systems while
not for others.

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

Why would you ignore the RFC1342 character set specification? On some
systems it will be irrelevant, and on others it will be very relevant.

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

Quite true; however, 8-bit filenames also have applicability for local file
references, and those have nothing to do with FTP.

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

I wish they were participating here as well.

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

Greg V. refuted this claim quite thoroughly. Existing implementations have
no mechanisms for handling 8-bit filenames, so adding one (in a way which
doesn't change the way 7-bit filenames are handled) will not break any of
those implementations.

< It also uses employs only part the RFC1342 mechanism; the result is a
< fairly ugly mish-mash.

How do you see only part of the RFC1342 mechanism being used. The RFC1342
mechanism requires a character set name. On some systems, it will be
relevant and on others it won't be; the later systems can choose a character
set name that will be ignored, or specify unknown. There's no bastardization
of the RFC1342 mechanism occurring, and no 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.

There are two types of filenames in question: names for local references,
and names for remote references. I don't believe that lots of hidden and
subtle issues exist for the local reference filenames.

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

What is "URI" and "URL"? What working group is it? What's their charter?
Does it even cover local filename references?

Also, how do we know that the issues pertaining to email will be grappled
with unless we either discuss them in the email group, or have
cross-representation to the other group?

Note: I think we are all agreed that the discussion on this matter must not
hinder the publication of the next MIME spec, but it could lead to a
separate rfc on the topic which extends that particular parameter.

                                        Tony Hansen
                                att!pegasus!hansen, attmail!tony