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