Re: multipart/alternative extension

> >  Whether or not a new subtype makes sense is dependent why the
> >  extension in RFC 1766 wasn't widely implemented. If the reason is
> >  that multipart/alternative got implemented in a particular way before
> >  RFC 1766 came out and people didn't want to revise that, then a new
> >  type is the right way to go. But if the reason is that people simply
> >  didn't understand what needed to be done and are willing to do the
> >  right thing once they understand it, then building off of the
> >  established base of support for alternative will get you a lot
> >  further a lot faster.

> Its is not reasonable to expect that a new definition of this
> will be rapidly implemented. It is reasonable to expect that
> many mailers will for a long time follow the original MIME
> specification of multipart/alternative.

This may or may not be so. For one thing, implementation and deployment have a
lot more to do with timing than anything else. I've seen plenty of instances of
new features being implemented quite rapidly. A good example is NOTARY support.
NOTARY happened to arrive a time when various mailers were being extensively
modified for other reasons so support for it started appearing quite rapidly --
far more rapidly than most of us involved in the effort would have predicted
given the complexity of the necessary code.

Deployment is a trickier proposition than implementation. But in the present
case we can chear: When you're talking about recipient functionality all you
really need is implementation availability. Users will decide whether or not
they need to upgrade on an individual basis. (This differs markedly from things
like NOTARY, which requires that all intermediaries support it to be effective,
and hence despite rapid implementation is still short of being universally
deployed.)

> Note that there are
> still many implementations which treat multipart/alternative
> as multipart/mixed (which actually happens to be better
> than the most common present implementation of
> multipart/alternative in the case of multiple languages).

> Is there an established base of support for alternative,
> which is better than multipart/mixed for multi-language
> messages?

Chris Newman already answered this question in the affirmative: Mulberry
gets this right.

> None of the systems I tested did better than
> multipart/mixed. And none of the systems seemed to
> recognize the "differences" attribute to
> multipart/alternative.

The problem with building something completely new is that there's a very real
chance that essentially nobody will implement it. So suppose this turns into a
choice between rapid uptake of an enhancement to alternative in several key
clients versus new facility that remains unimplemented for the forseeable
future. What then?

				Ned

Received on Monday, 7 May 2001 02:51:44 UTC