In section 3, the sentence "However, conformant software is encouraged
to check the version number and at least warn the user if an
unrecognized MIME-version is encountered." is poor implementation
advice and should be removed. The value of MIME-Version: is never
going to change and readers should not waste code checking for its
existence, much less verifying its value.
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.
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.
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".)
The requirement in section 5.2:
Any characters outside of the base64 alphabet are to be
ignored in base64-encoded data. The same applies to any
illegal sequence of characters in the base64 encoding, such
as "====="
contradicts the previous paragraph and is onerous to implement. For
example, metamail botches this requirement completely. Most of my
implementations botch it as well. I am aware of no implementations
that expect this requirement to be followed.
The examples which refer to "text/richtext" should be changed to refer
to "text/enriched".
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.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up