Great Circle Associates List-Managers
(April 2001)
 

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

Subject: Re: Digest MIME types...
From: Charlie Summers <charlie @ lofcom . com>
Date: Sun, 8 Apr 2001 12:24:57 -0400
To: Tim Pierce <twp @ rootsweb . com>
Cc: James M Galvin <galvin @ acm . org>, List-Managers @ GreatCircle . COM
In-reply-to: <20010408112536.O8469@ma-1.rootsweb.com>
References: <v0313036db6f51490e9f4@[208.165.39.28]>; from charlie@lofcom.comon Sat, Apr 07, 2001 at 03:38:37PM -0400<v03130363b6f4eda6be8b@[208.165.39.28]><Pine.BSF.4.21.0104071308360.30133-100000@two.elistx.com><v0313036db6f51490e9f4@[208.165.39.28]>

At 11:25 AM -0400 4/8/01, Tim Pierce is rumored to have typed:

> One of my co-workers uses Pegasus for all his mail and absolutely
> loves the way SmartList handles multipart/digest messages.

   According to my reading of the RFC, however, Smartlist handles it
_incorrectly,_ since there's no multipart/mixed section outside to contain
the text/plain TOC section. Philip (who send me out on this quest, BTW)
inteprets the RFC to mean that it's an option and not a requirement (not a
quote; my words not his), even though there is a specific format flow in the
RFC for digests with TOCs.

   But looking at Mr. Galvin's restatement of the format of a
multipart/digest message which matches that in the RFC, SmartList appears not
to be handling it correctly at all, since there is a _non-message_ section
inside the /digest part.

> I'm
> told that Netscape Mail also handles them nicely, with an option
> to view all digest attachments inline or as separate messages.

   Would I be correct in this case that there are technically no attachments,
but rather messages? (MIME parts? Subparts? I dunno...the termonology gives
me a headache. Maybe it's just the cold...)

> Therein lie the risks of hewing blindly to standards.  Just about
> every specification is going to have holes in it, and some issues are
> going to slip through the cracks.

   With respect, shouldn't the holes be patched and the projected standard
changed to handle them, instead of allowing the confusion to continue?

> The issue isn't
> whether the message format is "correct" in some abstract sense according
> to the specification.  It's whether people can actually read the messages.

   Agreed completely. But then, you're biting yourself in the rear making
that argument, since if those, "clicky-clicky graphic mail clients" to which
you refer, which are the _majority_ of people receiving the digests (outside
some technically-specifific mailing lists), CANNOT handle them, or do not
handle them CORRECTLY, then again why use it? You yourself suggested the
standard was non-specific and open to intepretation; should clients be forced
to "hew" to every conceivable intepretation? By your own argument, if the
people _can't_ actually read them (or not without jumping through hoops), it
should _not_ be used.

> There is an old discussion on the Internet Mail Consortium's site about
> multipart/digest (http://www.imc.org/mailext/old-archive/index.html#351),
> and the consensus among the implementors there appears to have been that
> it is technically legal, but not a good idea, to include a text/plain
> table of contents within a multipart/digest message.

   I can't see where it's even technically legal, since the RFC specifically
requires a multipart/mixed wrapper for text/plain segments outside the
multipart/digest, but like I said before, I haven't earned the chops to make
pronouncements like that, and certainly Philip has. (If I keep asking
questions, and learning things, maybe in another 10-15 years or so, if I
don't die of old age first... ;)

         Charlie





Follow-Ups:
References:
Indexed By Date Previous: Re: Digest MIME types...
From: Charlie Summers <charlie@lofcom.com>
Next: Re: "Digest" MIME types
From: "Bernie Cosell" <bernie@fantasyfarm.com>
Indexed By Thread Previous: Re: Digest MIME types...
From: Tim Pierce <twp@rootsweb.com>
Next: Re: Digest MIME types...
From: James M Galvin <galvin@acm.org>

Google
 
Search Internet Search www.greatcircle.com