I'm afraid I need to offer a small clarification to the community, although
this entire strain is beginning to look like a debate over the number of
angels one can put in the header of a message...
At 3:25 AM 12/9/94, Barton E. Schaefer wrote:
Neither a MIME message nor a message containing iso-2022-* text is a
A Mime message very much IS a valid RFC822 message, based on the current
Internet standards process.
However, a MIME message isn't *intended* to be valid RFC 822. It is not
Well, actually it very much IS. The design and wording of the Mime spec
was very carefully done to be as completely orthogonal to RFC822 as we
could get away with. That is because RFC822 really devotes itself to
headers and Mime really devotes itself to the body. The definition of a
few headers, by Mime, is entirely within the style of extensibility offered
by RFC822 and the standards process.
On the other hand, one could view Mime as being applicable far beyond the
context of Mime, such as demonstrated by its use in the Web. (I refer to
Mime as an object "stapler".)
of the presence of the Mime-Version: header, is announcing that it is
not an RFC 822 message and that it therefore should not be treated as one.
The thrust of your statement is exactly correct. The reason I'm hassling
folks with this message is that I'm concerned that your particular wording
might exacerbate the already-persistent confusion.
An old-style RFC822 message was/is unable to distinguish different kinds of
bodies. In that sense, you are right that Mime makes a message "different"
from RFC822-classic. On the other hand, I hope folks don't refer to this
as "violating" RFC822. Mime has been incorporated according to the
standards process and hence it formally and validly modifies iterpretation
of the RFC822 message body. In that sense, it very much DOES conform to
RFC822 rules.
I hope you all find this as confusing as I do...
...the point is
that unlabeled iso-2022-* does not conform to ANY currently-accepted
Bingo. Exactly right. Thank you for stating this so concisely.
Sending iso-2022-* without telling the recipient what he's getting is
equivalent to sending B encoded US-ASCII without telling the recipient
that it is B-encoded. Niether of them is valid anything.
right.
But wait! There already IS a specification that redefines the format of
oh, you clever dog, you. right again.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email:
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu