At 1:28 PM -0400 4/7/01, James M Galvin is rumored to have typed:
> Does this help?
Yes, but only to worry me that it is probably a _bad_ idea to use it.
> I can clarify the requirements for you. I assure you my implementation
> follows the RFCs.
And I certainly believe you, although I'd suggest that there is
considerable room for intepretation.
> 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.
> 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 strip it out as a text-based attachment,
which is _not_ the intended result. I wonder how many _other_ clients would
make the same mistake? (This might explain why I'm interested in whether,
why, and why NOT people use this suggested MIME type for their digests, and
why I'm trying to get ahold of physical examples of the various
implimentations.)
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."
The question is not necessarily what do five-year-old standards have to
say, but how is it being implimented _today,_ which brings me back to my
request to see an issue or two of existing implimentations of the MIME type
(which may be different from yours but equally, "follow[ing] the RFCs" based
on a diferent intepretation of the request for comments mentioned) and
comments from people who specifically do NOT use this MIME type.
I'm also _terribly_ interested in seeing how many different mail client
packages work with the various implimentations, which is why I requested
subscription information; I want to run samples of various implimentaitons
through various clients and chart what happens. A standard that isn't handled
by the bulk of modern mailers, or is handled incorrectly, isn't much of a
standard at all (I will specifically remove Microsoft clients from the
equation for the sake of discussion, since I have yet to figure what kind of
standard they follow, if any).
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. But considering the large number of
digested email lists to which I'm subscribed do NOT use this type (the only
one that does, out of all the lists to which I subscribe, is one of MINE
implimented incorrectly according to the way I intepret the standards but
correctly the way the author of Smartlist inteprets the standards, and
differently from the way _you_ suggest the standard should be followed) and
indeed don't use _any_ explicit MIME type thereby defaulting to text/plain,
and that I actually had to come here to find any that might (and so far found
only you, for which I am grateful), the implication is that this _isn't_ an
acceptable or accepted standard for the bulk of list managers...or at least
the bulk of list administrators.
I guess I'm really searching to find out exactly _why._
Charlie
