<< From: hansen(_at_)pegasus(_dot_)att(_dot_)com (t.l.hansen)
<<
<< Thus it follows that if the message/rfc822 part has a Mime-Version
<< header, treat the part as a mime message. Otherwise, you cannot.
< From: John Gardiner Myers <jgm+(_at_)cmu(_dot_)edu>
<
< There is certainly debate on this topic--the "Otherwise, you cannot"
< statement is much too strong.
<
< There is nothing in the MIME spec which prohibits a reader from
< interpreting a Content-* header in the absence of a MIME-Version: header.
< In fact, a strict reading of the minimal conformance rules gives a
< minimally conformant reader no leeway to ignore a Content-Type: or
< Content-Transfer-Encoding: header, even if there is no MIME-Version.
There is a problem that people trying to use standards documents always
face: What do you do if the "whatever" doesn't follow the spec? The answer
always is: Then it cannot be considered to follow the standard for
"whatever".
In the C world, if you have a compiler which purports to follow the ANSI/ISO
C standard, but doesn't predefine the __STDC__ macro, IT CANNOT BE
CONSIDERED TO BE A STANDARD C COMPILER! It is foolish to say "but, it
follows 99% of the rest of the standard." A programmer writing portable
programs using the the ANSI/ISO standard must be able to make assumptions
based on the properties of the standard, such as assuming beforehand how
unsignedness promotions occur. If the compiler doesn't do this one part the
right way, how many other parts did it mess up on?
Note also that a standard is usually not permitted to say how to handle a
"whatever" that doesn't follow the standard. Such "whatevers" are ALWAYS
outside of the scope of the standard. In fact, standards bodies faced with
this issue are usually constrained from even mentioning these problems
within the standard itself.
So too with MIME. If MIME were to say something about a message that doesn't
have a Mime-Version: header, what would it say? What could it say? It
already says:
A MIME-Version header field, which uses a version number
to declare a message to be conformant with this
specification and allows mail processing agents to
distinguish between such messages and those generated
by older or non-conformant software, which is presumed
to lack such a field.
...
Messages composed in accordance with this document MUST
include such a header field, with the following verbatim
text:
So here is says that a MIME message must have a Mime-Version header. It
further says that messages without such as header should be treated as
non-conformant, which is considerably more than many standards are allowed
to say.
I'd say this is pretty explicit, and am willing to repeat my earlier
statement
Thus it follows that if the message/rfc822 part has a Mime-Version
header, treat the part as a mime message. Otherwise, you cannot.
However, I will continue on and say that what you CAN do is treat it as
anything you want, including a sort-of-looks-like-MIME message. In other
words, if it sort of looks like it's really MIME, treat it as such until
proven wrong. But be aware that you may have to back up and start over if
the assumptions are wrong.
< The MIME reader I wrote completely ignores the MIME-Version: header and
< treats every message as a MIME message unless it has specific knowledge
< that it is something else.
You're welcome to do so. However, don't be surprised if you run into mail
messages which have no Mime-Version header, but do have Content-Type headers
which look like Mime contents, and cannot be treated as such because they're
not. Pragmatically, you may never see such a message. If so, you're lucky.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony