On Mon, Apr 09, 2001 at 02:16:36PM -0400, Charlie Summers wrote:
> 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...
Maybe. But you did raise the concern that this behavior is
technically illegal. If the only concern is strict adherence to
the standard, then this part isn't a problem. And if the concern
is simply that users can't process data formatted this way, it
hardly matters if it's officially legal.
> > 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.
This gets us back to whether strict conformance is putting the cart
before the horse. Is the real problem that the digests aren't officially
legal, or is the problem that users aren't able to read them well?
My guess would be that mail clients may get a little confused by
an RFC822 enclosure with no headers, but that they would be able
to handle it reasonably well, and that it would be an acceptable
compromise if it's important for every digest enclosure to be
message/rfc822. Maybe not. But try it out if you need to know
for sure.
Remember that the whole purpose of a standard is to give providers
and clients a common framework for exchanging data. If the point
of agreement turns out not to be exactly permissible under the
appropriate specification, that's okay. It suggests that the spec
should be revised or clarified at some point, but you shouldn't
let it hold you up if you need to get a job done.
References:
|
|
