Great Circle Associates List-Managers
(April 2001)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Digest MIME types...
From: James M Galvin <galvin @ acm . org>
Date: Sun, 08 Apr 2001 10:25:36 -0400 (EDT)
To: Charlie Summers <charlie @ lofcom . com>
Cc: List-Managers @ GreatCircle . COM
In-reply-to: <v0313036db6f51490e9f4@[208.165.39.28]>



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




Follow-Ups:
References:
Indexed By Date Previous: Re: Digest MIME types...
From: J C Lawrence <claw@kanga.nu>
Next: Re: Digest MIME types...
From: Tim Pierce <twp@rootsweb.com>
Indexed By Thread Previous: Re: Digest MIME types...
From: Charlie Summers <charlie@lofcom.com>
Next: Re: Digest MIME types...
From: Charlie Summers <charlie@lofcom.com>

Google
 
Search Internet Search www.greatcircle.com