I thought I'd say publicly what I've said to Nathaniel privately.
The benefit of /alternative will be huge, especially during the phase-in
process for RFC-XXXX. Xerox, and PARC in particular, has been shipping
mail back and forth for years between people who either have various
fancy document formats (Viewpoint, Tioga, TEdit), and people who don't
(SMTP, Mac). One of the biggest complaints comes up when "dumb" UAs are
sent "fancy" messages. People just react negatively to strange
characters and strings all over their messages (or, if they're sent a
Viewpoint document, a huge chunk of opaque uuencoded data -- you know
there's a message there, but have no idea of what it might be).
I think this is going to be a big problem over the next 3-5 years, as
people phase-in use of RFC-XXXX. One of the ways in which this might be
mitigated is to use /alternative, in some fashion such as:
Content-type: multipart/alternative;
boundary=PLEASE_IGNORE_STUFF_BELOW_THIS_LINE
Hi, this is what I wanted to say.
Bill
--PLEASE_IGNORE_STUFF_BELOW_THIS_LINE
Content-type: application/x-viewpoint
<some BASE64 data here>
--PLEASE_IGNORE_STUFF_BELOW_THIS_LINE
Content-type: text/plain; charset=X-Xerox-Character-Set-0
Hi, this is what I wanted to say.
Bill
--PLEASE_IGNORE_STUFF_BELOW_THIS_LINE--
This kind of message should work (albeit cruftily) with non-RFC-XXXX
mailers, simple (text-only) RFC-XXXX mailers, and RFC-XXXX
Viewpoint-capable mailers. And, for at least a few years, this had
better be the kind of message you send, if you want your fancy mail to
be assured of being readable.
Bill