In the spirit of the season, I have the following observations:
1. External-body
Issues:
Greg illuminates a valid need, but I believe that this is simply outside
the scope of MIME. The purpose of message/external-body is to provide a
pointer to a discrete content at some remote site. What Greg wants is a
standard syntax for talking to info servers via e-mail. These are two
separate things.
Further, Nathaniel recently posted some new text. I had two minor
comments on it, which I understand he has incorporated. My only remaining
concern, is one that Greg mentioned, namely that the AV pairs are
open-ended.
Resolution:
For the purposes of the MIME document, I suggest we punt on issue #1.
Instead, I invite Greg to write a separate document about a new
content-type application/info-server, or whatever, which details what he
wants.
I suggest that Nathaniel rewrite the text to be something like this.
///////
The only mandatory parameter is access-type, which can take one of
these values: .... . Based on the value of access-type, other
parameters may be mandatory or optional.
For the "ftp" and "anon-ftp" access-type, the additional mandatory
parameters are: name, site. The optional parameters are: directory
and mode.
For the ...
///////
So, this is really just a bit of wrapper-text around bits of the
existing text.
2. Charsets
Issues:
It all boils down to Dave saying that it is inappropriate for the
MIME document to list a whole bunch of charsets. This followed by a
whole bunch of discussion as to which charsets are good ones, bad ones,
real ones, etc. Independent of the discussion on the individual
charsets, the meta-issue remains that the MIME document should not try
to provide the exhaustive list of these in the short time we have for
closure.
Resolution:
I suggest that the MIME document define a single-value for charset=,
namely us-ascii. It should then refer to the IANA, who will maintain
the complete list. Once the MIME document is in the standards pipe, we
can develop a list of initial charsets for the IANA to consider.
3. MIME-Version
Issues:
Mark points questions the usefulness of the MIME-Version field by
observing the future difficulty of having defined multiple values for
this field. He even goes so far as to suggest we achieve
version-increments by changing the name of header fields. In practice,
this is probably just as ambiguous. Given his comments, MIME-Version is
probably superfluous.
Resolution:
Get rid of the field. It doesn't help anything. If someone is silly
enough to want to completely revise MIME, they can pick new names for
the headers or otherwise deal with the problem.
4. And finally
I can't recall seeing any other issues go unresolved since the
publication of the latest drafts. I wish to remind everyone of the
impending deadline for closure. As such, it is imperative to achieve
resolution on these issues, produce the final draft, and move this to
the steering group. Of course, the first thing the steering group will
do is put out a "last call" message requiring a three week comment
period. Nonetheless it is important to finish and get the clock
running. The community has waited far too long for the capabilities
offerred by MIME. It is time we deliver it to them.
/mtr