On Sun, 8 Apr 2001, Charlie Summers wrote:
> 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. ...
Ah, now I understand where you're coming from. I guess I'm too close to
it all. I think section 5.2.1 from 2046 has what you're looking for:
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict
conformance to RFC822, nor are the semantics of "message/rfc822"
objects restricted to the semantics defined in RFC822. More
specifically, a "message/rfc822" message could well be a News article
or a MIME message.
Continuing with your message:
> 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.
Please don't misunderstand my position. I agree with you 100%. But
what we want can not be mandated by standards. The Standard sets up the
opportunity for what you propose, assuming of course that it is an
opportunity of interest to both implementors and users.
This is why I chose to create multipart/digest for my digests. Recall I
said I did it in part because I do try to support standards, but what I
didn't say is that I understand that standards are not a panacea. I
also said I did it because in this case it is backwards compatible with
MUAs that do not understand it. This is important because whenever you
have a new standard you always seem to have this catch-22 between
implementor and user. This is one opportunity for implementors to do
something that doesn't break anything and sets up an opportunity for
newer and better service.
Jim
