Nathaniel Borenstein <nsb(_at_)nsb(_dot_)fv(_dot_)com> writes:
I'd really prefer not to reopen the debate about MIME-Version,
specifically focusing on the one sentence that "encourages" checking the
version number.
Last time around, you closed the debate, which eventually focused on
the one sentence, with "we don't want to delay going to Draft Standard
on this issue." Given the circumstances under which the debate was
closed, I'm not particlularly amenable to a plea to not reopen it.
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.
One, this is completely irrelevant to the particular sentence I am
asking to be removed from section three. While I would very much like
section three to be effectively gutted, this is not what I'm asking
for.
Two, why is it so important to differentiate between malformed MIME
and non-MIME? Malformed MIME isn't guaranteed to have a MIME-Version,
so it can get misclassified as non-MIME. Metamail 2.7 doesn't appear
to look for MIME-Version, so you can't think it's *that* important.
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".
That sounds like a "default subtype" to me.
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.
By my reading of the document, the "serve as a model" meaning does not
apply to message/rfc822. Unrecognized subtypes of message are to be
treated as application/octet-stream.
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.
I think it is useful advice independent of the first argument.
Note that I did not say "require", thus allowing readers that know
something about these non-MIME Content-Types to handle them according
to non-MIME rules.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up