OK, sorry this took so long, I was swamped.
First of all, thank you for the comments, John. As usual, you obviously
read it very carefully, and I'm grateful for the time and effort
involved.
I'd really prefer not to reopen the debate about MIME-Version,
specifically focusing on the one sentence that "encourages" checking the
version number. I definitely agree with Tony's point that checking for
its existence is often worth doing, particularly in situations where
pre-MIME content-type headers are floating about. Just treating
syntactically invalid content-types as the pre-mime ones is not a good
solution, because it doesn't allow you to differentiate between
something that is malformed MIME and something that was never intended
to be MIME in the first place. Anyway, my inclination is to leave this
as it is unless there's a clear consensus to change it.
The term "primary subtype" is used throughout the document. It is
never defined and has no practical meaning. It should be removed as
being potentially misleading.
I think a lot of this prose is historical, dating back to when there
were default subtypes in MIME. What I meant, however, by "primary
subtype" was "the type that might serve as a model for the treatement of
unrecognized subtypes". The phrase is used in reference to text/plain,
message/rfc822, application/octet-stream, and mulitpart/mixed, in all of
which cases this meaning applies. If there's general sentiment that
this is important I can either try to clarify that usage of the phrase
or delete it. As far as I know it hasn't proved a problem for anyone,
but the point is unimportant enough that I could live with either
keeping things as they are, adding a definition, or eliminating the
phrase. My instinct is to let inertia prevail.
In section four, the paragraph starting "Default RFC 822 messages"
defines the default content-type and specifies its use in the absence
of any Content-Type: header. It should also explicitly recommend (or
at least explicitly allow) its use when a Content-Type: header does
not conform to the "content" nonterminal in the grammar.
This reopens the first argument, I think.
Certain individuals have previously stated that the transfer-encoding
restrictions on "message" were actually intended to only be applied to
"message/rfc822". The current spec clearly states the restriction
applies to all subtypes of "message" and includes text dealing with
the restriction on "message/partial". I wish to verify that this is
actually what is being intended. (I do note that one of my own MIME
readers, munpack, does not allow nontrivial transfer-encodings on
"message/partial".)
That's definitely intentional.
I also agree with Valdis' interpretation of section 5.2. The first few
='s are legal, and everything after that is ignored.
The examples which refer to "text/richtext" should be changed to refer
to "text/enriched".
Good point. Consider it done.
The grammars for text-type, message-type, application-type, et al.
unnecessarily and incorrectly restrict the possible values of the
Content-Type field. For example, the text-type nonterminal prohibits
the value of the "charset=" parameter from being quoted and prohibits
parmeters other than "charset=". They should all be removed.
Sigh. If there's one thing I've really come to HATE in the MIME process
it is the formal grammar. I will make a pass at improving it and post a
new Internet-Draft soon. -- Nathaniel