On Sat, 7 Apr 2001, Charlie Summers wrote:
> The multipart/digest content-type is only intended to carry a collection
> of messages.
Actually, I read it to carry a collection of TEXT messages (as per 822),
but I conceed I could easily be wrong.
I think the following sentence from Section 5.1.5 from 2046 should clear
up any misunderstanding:
The "multipart/digest" Content-Type is intended to be used to
send collections of messages.
> The preferred way to create a digest with MIME is thus as follows:
Yes, I can clearly see that since the example you used is the
same as the one in 2046, albiet slightly cleaner; it's silly, IMHO,
but is how the standard is defined within the RFC. The result for at
least one mail client I know about would be to take the entire
multipart/digest subpart of the multipart/alternative message and
What multipart/alternative? There is no multipart/alternative, unless
it is in one of the messages that is in the digest, in which case it
should apply only to that specific message.
The outermost type is multipart/mixed, which inside has two parts. The
first is whatever, although I used text/plain to list all the subject
lines. The second is multipart/digest, in which all the messages are
listed.
Strictly speaking the outermost message could be just multipart/digest,
and thus the body could be just the list of messages. All this leaves
out is the table of contents. As far as examples of MUAs that
understand multipart/digest, I use Pine and it understands it just fine.
In any case, any MUA that correctly implements multipart should be able
to deal with multipart/digest. If the parts of the digest are labeled,
there should be no issue at all. This is because MUAs are supposed to
interpret unknown multipart/* as multipart/mixed. It is one of the
compliance requirements. If you take advantage of the default
interpretation of a multipart/digest part and don't label it, then MUAs
that don't understand multipart/digest will think everything in it is a
text/plain, which can look pretty ugly when you've got a lot of headers
to get through.
I'm also sending you a private message to point you at some examples of
my implementations of digests.
I mean, none of this specifically deals with _modern_
issues. Yes, you _might_ have a sub-section of text/html inside the
multipart/mixed multipart/digest subtype, but it's discouraged since
in 1996 no one in their right mind sent HTML mail that required six
times the bandwidth to say the same thing as a simple text
message. No one was including background image files in email, nor
those annoying VCards (a pet peeve), they actually had something to
say that didn't require a ransom note to "punch up."
There's obviously some other point of confusion. There is no such
restriction of which I'm aware, if I understand what you are saying.
The content of a multipart/digest is a message/rfc822. There are no
restrictions on a message/rfc822 so whatever you want can be inside
that. Complete support for all MIME content-types is included. I'm
understanding you to say that all you can do is put text/plain in the
message/rfc822 in the multipart/digest in the multipart/mixed. Am I
wrong about what you are saying?
I'm honestly not trying to do anything but determine whether or
not this is a standard that _I_ should use, and am not suggesting
that it should or shouldn't be implimented by others.
I can tell you that I chose to use it only in part because I'm an avid
supporter of standards and thus believe it is the right thing to do. I
also chose to do it because it is backwards compatible with
anybody/anything that supports MIME.
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. The issues with
non-MIME MUAs are about the same as always, except that in my case I
include all the headers in the digested messages. Historically it is
much more common to only include a small set of relevant headers. Thus,
in my case, non-MIME MUAs have a little more "stuff" to get through.
Jim
