At 1:07 PM -0400 4/9/01, James M Galvin is rumored to have typed:
> Is this is a transcription error:
Nope...and I checked it _really_ carefully from an untouched copy of the
shell script (I've made some changes to the various production versions),
since I didn't want to make any "multipart/alternative" mistakes
again...besides embarassing myself again, Philip would kill me if I misquoted
his structure. ;)
> However, it turns out it's legal regardless and, in fact, the form in
> which you transcribed it is arguably preferred.
>
> With the blank line, as you transcribed it, the content is actually a
> message/rfc822 for which the content is a text/plain. This is because
> the default content-type in a multipart/digest is a message/rfc822 and a
> blank line separates MIME headers from its content.
Ok, but it surely sounds like you're _really_ streching a point...
> Of course, 2046
> also says that a message/rfc822 should have at least a From:, Date:, and
> Subject: header, but that's a different issue.
Not really; if it's required by the standard, and the "message" doesn't
contain it, then it's non-conforming, QED.
> It occurs to me that a good example of what a digest could look like
> (which is probably what LISTSERV does) is the following:
>
<example snip>
>
> Thoughts?
Exactly what I was thinking when I read Mr. Fajman's note, since I _think_
it could be done with simple modifications to the existing SmartList code
(with the possible exception of an accurate Date header field...has to do
with SmartList building the digest.header file on the FIRST message then
appending the message topics to it, not building it from scratch right before
release), while still avoiding the entire text/plain boondogle.
Of course, the question _still_ remains as to what specific clients will
do with the type, but it should be simple enough to set up a test list to
determine the viability and practicality of building the digests this way...
Personally, I kinda like it.
Charlie
Follow-Ups:
References:
|
|
