Re: MIME implementation documentation

[Ned Freed <[e-mail]>]

> Unfortunately, I'm looking at the source for MHN right now, and unless I'm
> more caffeine-deficient than I thought, it appears that multipart/parallel
> is basically punted to multipart/mixed.  Specifically, in function
> user_content(), it basically says "if it's /parallel, pretend it's /mixed"
> (near line 6122).

> Since, as I remember it, MIME-conformant agents are required to punt
> unknown multipart/bogon's to /mixed, I don't see how this *really* qualifies
> as "full" support.

Well, all I can tell you is that I specifically asked Marshall if his MHN
implementation fully supported parallel and he said "yes". I took that to mean
it handles it as something more than mixed, but perhaps Marshall doesn't see it
that way. (This is justifiable; see below.)

> Do any implementations do anything for /parallel *ABOVE AND BEYOND* treating
> it as /mixed?

Not according to the specification, they don't. Full MIME conformance is
obtained by just treating parallel as mixed. This is as it should be: Unlike
alternative, the semantics of parallel are so "light" that treating it as mixed
is, if you'll pardon the overloading, an acceptable alternative. This is why
you don't see a lot of people jumping up and saying they support it -- nothing
more than this is required by the specification. 

If we actually go by what the specification says is required to have a
conformant implementation of parallel then I would say that there are
undoubtedly dozens of implementations of it.

I note in passing that another way to address this matter would be to call for
better support of parallel in the conformance section of the document. I am
somewhat opposed to this as I believe that supporting parallel as mixed is
sufficient in most cases. Nevertheless, I do not want to lose the
distinction between parallel and mixed in the specification, so I am
opposed to dropping the concept from the document.

				Ned