Hmm, well this conversation is definitely resulting in diminishing returns,
but I'll try to clarify one point and keep it short. I haven't argued against
my approach. The painful process described above results from
multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent
alone, then the text shows up right where it should, the problem is that this
"useless" attachment, which can be ignored, also shows up. The reader of the
message is forced to look upon an attachment indicator, but doesn't need to
take any extra steps to actually see the message body.
Perhaps you don't see this as arguing against your own approach, but I most
certainly do. You apparently have a problem with one client's handling of
multipart/alternative, so instead of dealing with that clients problem somehow
you use a structure that is very suboptimal on compliant clients. For me the
question boils down to whether you do something that's really bad for one or
something that's somewhat bad for everyone. You have chosen the latter. I would
choose the former.
Perhaps we should attempt to shed some light on this topic. How about some
reports from the field about how different clients are actually handling
multipart/alternative. Does your client force you to make an explicit choice
about which alternative you want to see on every multipart/alternative message
you receive or do you configure it once? Does it treat multipart/alternative
as multipart/mixed? If the message contains a nested hierarchy, are you
forced to go through a two-step interaction to see embedded elements?
My experience has been that most clients handle such things tolerably -- they
either handle multipart/alternative correctly or else they flatten everything
so that your two approaches are equivalent.
Maybe I'm not getting my real point across. From a UI perspective,
multipart/alternative and nested hierarchies are difficult to handle in a real
clean way.
On the contrary, since proper handling of multipart/alternative effectively
eliminates the heirarchy, none of these presentation issues arise. If they
do arise there's something wrong with multipart/alternative handling.
Let me put this another way. If what you're arguing for is that if a client
cannot handle multipart/alternative, it should at least flatten out the
structure around it to prevent even more problems, I would tend to agree. But
all the standards can do is define compliance -- the behavior of incompliant
software (and support for multipart/alternative *is* required).
I'd say virtually every mail client that's being modified to
handle MIME started off with no model of alternative content or of
hierarchical structure.
Depends on how the mods are done. If MetaMail is used as a basis for the
mods (and it often is) you end up with alternative handling from the beginning.
Therefore, the MIME implementor needs to make a
choice about how to handle it. By far the simplest approach is to just treat
mp/alternative as mp/mixed. Another approach is to query the user, but I
consider that a total mistake. The best approach is to make a choice based on
configuration information, perhaps provide some subtle indication that a
choice was made, and then provide a way for the user to examine the choices
and possibly make a different one explicitly. I haven't seen any system that
actually does this (Slate came close, but it wasn't always completely clear
what part of the document the alternatives were tied to.)
The first MIME client that was released, MetaMail, seems to handle this just
fine. And MetaMail works with practically every existing user agent around.
Oddly enough, the one thing MetaMail doesn't do well is default to handling
unknown subtypes of multipart as mixed!
Making these decisions consistently across clients is critical to
interoperability. As an analogy, look at the issue of line lengths.
Everyone's read those virtually unreadable messages from someone writing in a
window that lets them put 85 characters on a line. Sure its 822 compliant,
but that doesn't make it easy to read.
Anyone want to add some case histories to this discussion?
One example: A side conversation with Ray Langford from Frontier Technologies
indicates that their SuperTCP mail client flattens hierarchy and treats
mp/alternative as mp/mixed. It also treats the first inline text part as the
message body that is presented to the user. The result of these choices is
that both our encodings result in the same appearance to the user.
But in this case it doesn't matter which of your two approaches you use. Its a
no-win situation either way. If anything this demonstrates a preference for
multipart/alternative -- you lose nothing by using it now, but should Frontier
ever fix their agent old messages will then be handled properly.
Ned