From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
this is indeed an interesting question. what Andrew does in this case
is simply to treat the alternatives as if they were enclosures, but to
label them as alternatives. What shows up is a compound doucment that
shows the "best recognized" alternative, and then is followed by a button
for each additional alternative. The buttons are labelled things like
"alternative version #1" and I think that users generally ignore them.
The truth is, if you recongize everything in the "preferred" alternative,
there's no good reason for even keeping the alternative version around,
but somehow I, like you, felt reluctant to throw away even this information
which was almost guaranteed to be redundant... -- Nathaniel
I assume the "buttons" can be easily expanded by selecting on them?
This seems like a reasonable approach, although I've got at least one example
where that doesn't work so well. The current notices of availability of new
RFC's includes a multipart/alternate sub-object that specifies two
message/external-body objects: one retrieved through a mail server and one
retrieved through anonymous FTP. Obviously both are recognizable, and
one may be preferable over the other in certain circumstances (depending
on network connectivity). It seems unlikely that a user agent should be doing
the work to determine which of these two approaches is better prior to
displaying the alternatives. And in the case where the MIME version is being
converted into something like Slate or Andrew in "batch" mode, there is no
way to determine (since the context in which the translation occurs may be
different from the context in which the message is read).
The most obvious approach is to just make both versions available and let the
user see and decide which version to use for retrieval. However, that violates
the "minimal conformance" guidelines of MIME (only one alternative should
be shown). Any thoughts on this particular usage?
Terry