< (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.
I must have missed it. In any case, I cannot see how the fundmental objection
here can be refuted. See below.
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.
There is absolutely nothing that prevents RFC1341-compliant server from
offering a filename which is indistinguishable from an RFC1342 encoded word.
Making this change causes such a name to be interpreted differently. This is an
incompatible change, plain and simple. It may not be much of a change, but it
is a change and it is an incompatible change.
< 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.
It see it right there in your original proposal, which said the character set
information is to be ignored. (I can dig up the original text you sent if you
like.) That equates to "only part being used" in my mind.
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.
The RFC1342 mechanism is intended to be used to display information. Its use is
intended to be restricted to places where fiddling around with a string
(specifically, encoding the string and tacking on a prefix and suffix) do not
change the sematics of the header in any way. RFC1342 quite cautiously limits
the use of encoded words to text, comments, and words within phrases. These are
the ONLY (emphasis copied from RFC1342) places where RFC1342 encoded-words can
appear, and all of them involve material whose only purpose is to be used for
display; these things have no semantics aside from this.
The application we are using RFC1342 encoding for here is completely different;
we are using it to encode information that is ONLY intended for machine
consumption.
Side note: What should a MIME reader that is incapable of resolving one of
these references do with the reference? Should it display the encoded word or
should it display the decoding in the proper character set? Doing this requires
YET ANOTHER change -- this time to the set of things that an RFC1342 viewer is
supposed to do.
Another side note: If we decide that the RFC1342-based character set
information should in fact be used for display purposes as well, this carries
with it the tacit assumption that the set of available character sets for
RFC1342 display coincides exactly with the set of character sets used by
servers to actually perform the reference. Are we sure this is workable in
practice? I think not -- the issues that define a character set for display
purposes might well be completely different from those that define a character
set for file reference purposes. As a trivial example, I could easily see the
10646 profiling information being an essential part of RFC1342 characters while
being totally irrelevant to file name presentation.
The pool just keeps getting deeper... This is a lot of changes, and they scare
me a lot given the tremendous difficulties we had in defining the scope of
RFC1342 to begin with. There is absolutely no chance that we've given this the
consideration it deserves at this, the eleventh hour. This one consideration
eliminates any possibility of this change being accepted in a draft-standard
document.
< (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.
I don't believe so either, but I don't know this for a fact. For this change to
be made at this stage pretty much requires the assertion that we know this for
a fact. I entirely fail to see how we can make such an assertion.
< (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?
URI is the name of the working group, as far as I know. It is an official IETF
working group to the best of my knowledge. I don't have a copy of the charter
but I do know the list address: uri(_at_)bunyip(_dot_)com(_dot_)
I'm not sure. There are references in the URL document to a file type of
resource but I don't see a definition for them.
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?
I don't see how the issues of obtaining an arbitrary object for use in an email
application differ in any way from those of obtaining an object for use by any
other application. We're only talking about referencing things here; there is
nothing special about the fact that the reference happens to be embedded in a
MIME message.
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.
This is fine as long as it does not usurp the perogatives of other working
groups. You can make a case for local filenames not being within the
jurisdiction of the URL folks. But I don't think you can make a similar case
for URLs for FTP, AFS, Gopher, NetNews, etc.
We can go about this in one of two ways: (1) We can enhance local files
separately and live with the inevitable differences that will result from two
groups working out different locator schemes. (2) We can try to make sure the
URI work addresses our needs including local files. I would prefer to at least
try (2); it might prove unworkable in which case (1) can be used instead.
Ned