Thanks, Mark, for your usual insightful comments, couched in your usual
soothing prose style. :-)
I agree with Ned that we're debating syntactic minutae where character
set specification is concerned. I admit that, as you perceived, I put
in content-charset as an attempt to forge a compromise between two
camps. If I were writing it exactly as I think it should be, I would
eliminate it in favor of an optional attribute-value notation for
application, binary, and image. I would leave character sets as the
subtype for text because I think that non-ASCII text is an extremely
widely-desired "special case" for which an extremely simple syntax
should be available. In short, I'm about 90% in agreement with you, but
would prefer to keep the charset subtypes of text. The question is,
WOULD THE ELIMINATION OF CONTENT-CHARSET BE A SHOWSTOPPER FOR ANYONE
ELSE?
I think Ran summarized the ISO-2022 problem very ably. Given prose that
clarifies the usage of ISO-2022, I would happily remove the "not
recommended" language.
I like Ned's compromise on multipart boundary-specs: alphanum is too
restrictive, but I'd like to keep them to the 70-odd characters that are
safe across, for example, EBCDIC gateways.
I think that multipart/alternative could well prove to be a key to
increasing the use of true multimedia mail, and I'd really like to make
it as close to mandatory as we can agree on. Is there wiggle room here
for softened wording?
I have to agree with Marshall that keeping multipart/digest is very
little overhead and adds some nice backward-compatibility.
On the subject of message/partial: I think I made that change at
Marshall's suggestion, so if he's now changed his mind and is opposed to
it I have no problem taking it out!
The BNF for Application leaves out ODA by accident, ATOMICMAIL on
purpose. (By the way, ATOMICMAIL has nothing to do with Andrew -- it is
a separate project, from Bellcore.) APPLICATION/ATOMICMAIL is the first
content-type to be registered with IANA, but I saw no reason to include
it in the RFC.
The audio format definition is a big headache about which I have no
strong opinions. If we can reach a consensus on this list, great. If
not, I really want to replace the whole mess with a placeholder, much
like video, and suggest a new IETF working group on audio formats. How
about if those of you (Marshall, Mark, ???) who have strong feelings
work together to come up with a joint position on audio formats? If you
can agre on ANYTHING, I promise not to oppose it... - Nathaniel