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.
> 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... ;)