Re: MIME implementation documentation

[Ned Freed <[e-mail]>]

> At 3:10 PM -0700 8/16/96, Ned Freed wrote:
> >So that's three MUAs producing multipart/alternative.

> 	I respectively submit to one an all that the question of
> /alternative is now answered and the topic closed.  I think it was dandy to
> raise the question, but it is well and truly laid to rest.

> 	/parallel seems to be a different matter?

No it isn't. As I previously stated in an earlier message, we had multiple
interoperable implementations of multipart/parallel in 1990, long before the
original MIME RFC came out. Specifically, we had Metamail and MHN. I know for a
fact that Metamail support for multipart/parallel works because I have used it
and I just confirmed with Marshall Rose that MHN did and does support this
construct.

As for the ability to create such things casually in a user agent being a
criteria for interoperability, I remain to be convinced of its validity. Try as
I might I cannot stretch the words in the standards criteria to cover such
a thing.

But even if it is valid, I have already stated that we provide tools in PMDF to
do this sort of thing -- no hand editing required. (You have to specify some
options on the command line, but that's it.) And believe it or not, when I was
checking for what we do with parallel I found that there is even an option in
PMDF-MR (MIME aware gateway to Message Router) that creates multipart/parallel
based on some craziness in ALL-IN-1 -- I don't recall the details, but
apparently there is some construct in ALL-IN-1 that maps best to
multipart/parallel, so there's even a case of an *ancient* (dating back to the
early '80s) user agent that let's users create and can process objects with
parallel semantics.

					Ned