At 10:25 AM -0400 4/8/01, James M Galvin is rumored to have typed:
> What multipart/alternative?
Blame this darned head cold...I _meant_ to type multipart/mixed. (I did
get it right in later references, at least, but was brain-damaged here. With
my apologies, please mentaly replace mixed for alternative, unless followed
by lifestyle or universe.)
> There are no
> restrictions on a message/rfc822 so whatever you want can be inside
> that.
Maybe, maybe not. I mean, good grief, 822 was written in 1982, discussing
ARPAnet commiunications, long before the concept of MIME, and specifically
says:
"Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
and the standard tends to be free with the number of bits con-
sumed. For example, field names are specified as free text,
rather than special terse codes."
Although you may not agree (I don't necessarily, either), it is perfectly
reasonable to assume that a message compliant with 822 contains ONLY what we
now consider MIME type of text/plain.
> Complete support for all MIME content-types is included.
That makes no sense, since MIME didn't exist at the time this RFC was
written.
> Am I
> wrong about what you are saying?
I'm not _saying_ it, I'm infering it...that is, I don't consider it
"fact," nor do I necessarily agree with it, it's only another intepretation
to be considered. (Hey, I haven't earned the chops to be "stating"
anything...if I did, I'd go so far as to say that 822 is completely
irrelevant to email today and should probably be ignored, but I don't, so I
won't.)
> As long as you label the content-type of the interior parts of the
> multipart/digest, there should be no issue with a MIME compliant MUA.
> None at all. If there are, the MUA is non-compliant.
I'd disagree here slightly, too. The client should handle multipart/digest
_differently_ than it does multipart/mixed, and have support for the ability
to properly handle MIME digests as either seperate messages (immediately
available within the client) or a text stream at the user's desire, and maybe
even some other method I haven't even thought about. If it doesn't, and only
handles the type as multipart/mixed, it may be compliant, but may also make
multipart/digest _worthless_ as a seperate standard.
The whole idea here is to make a digested group of messages _easier_ to
read, not harder. If (as some clients do) the message is broken into seperate
files dumped together in some attachment folder for _each_ message contained
therein, and the user has no choice in this matter, then the user must work
significantly harder to read the messages while the client may still be in
compliance (I dunno, I'm not researching multipart/mixed and don't claim to
be an expert on compliance). If a multipart/digest message doesn't give
_more_ choices to the client to make the user's life easier, what's the point
of using it? (This comes from someone using Eudora 3.1 from 1997, which
_does_ appear to properly handle the MIME type, or at least the test messages
I've created based on the RFC.)
I'm actually kinda curious where this MIME type went...I remember having
digests way-back-when that were multipart/digest (I'll need to research my
email archives sometime this week to prove or correct my admittedly-failing
memory), but like I said, I checked the mailing lists to which I'm subscribed
now, and _none_ of them use it. (This particular list, which is the rule
rather than the exception, contains no MIME headers at all. Others are
shipped in text/plain.)
Charlie
