I can clarify the requirements for you. I assure you my implementation
follows the RFCs. Although I wrote the code that creates the digest, I
use a mail system that is standards compliant, and I know it is because
its principal developer is one of the authors of the MIME standards.
The multipart/digest content-type is only intended to carry a collection
of messages. 2046 strengthened this requirement by changing the default
content-type inside a multipart/digest to be message/rfc822. Thus, it
is legal to do this
Content-type: multipart/digest
--boundary
RFC822_MESSAGE_HEADERS
RFC822_MESSAGE_BODY
--boundary
RFC_MESSAGE_HEADERS
RFC_MESSAGE_BODY
--boundary--
Outside a multipart/digest those embedded body parts would default to
text/plain, which is the MIME default.. However, 2046 falls short on
requiring that a multipart/digest only carry message/rfc822. It comes
close when it says that content other than message/rfc822 is
undesirable. The same is true for the conformance document, 2049.
The preferred way to create a digest with MIME is thus as follows:
OUTERMOST MESSAGE HEADERS
Content-Type: multipart/mixed; boundary="boundary1"
This message contains MIME. If you see this your MUA is ancient.
--boundary1
Content-Type: text/plain
Table_of_Contents
--boundary1
Content-Type: multipart/digest; boundary="boundary2"
--boundary2
RFC822_MESSAGE
--boundary2
RFC822_MESSAGE
--boundary2--
--boundary1--
Does this help?
Jim
On Sat, 7 Apr 2001, Charlie Summers wrote:
Date: Sat, 07 Apr 2001 12:46:16 -0400
From: Charlie Summers <[EMAIL PROTECTED]>
To: James M Galvin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Digest MIME types...
At 11:49 AM -0400 4/7/01, James M Galvin is rumored to have typed:
> I use multipart/digest. I'd send you an example but all my digest lists
> are collections from discussion groups.
Any chance I might subscribe to a list on your server? And might I impose
on you to know what manager you're using?
> What specifically were you looking for in examples of the format?
I'm trying to see how it's being implimented outside of SmartList. The RFC
(2046, 5.1.5. - see
http://src.doc.ic.ac.uk/computing/internet/rfc/rfc2046.txt to read it) _is_
pretty old and unclear, but it's obvious that it was never intended to permit
HTML, attachments, or other types not message/rfc822. (Like I said, it's from
1996, before the idea of sending HTML mail was considered an issue.) It also
suggests that there should be a multipart/mixed wrapper if there's a
text/plain TOC.
(*sigh*) I'm not sure after re-reading the thing a whole bunch of times
how a multipart/digest message _should_ look, but I'm pretty darned certain
that SmartList in its default configuration is NOT following the RFC in any
way, shape, or form. So I'm looking to see other implimentations, which I'm
betting also won't follow the RFC, to see if I can at least discover an
"accepted" method of using the MIME type, anyway. And if it is as little-used
as it appears to be, whether it should be used at all.
Charlie
