ietf-822
[Top] [All Lists]

Re: Content-Disposition ancillary

1999-04-12 06:41:36

On Thu, 08 Apr 1999 00:04:00 +0200 Harald Tveit Alvestrand 
<Harald(_at_)Alvestrand(_dot_)no> wrote:

I still think that content-disposition is an inferior approach to
those based on multipart/related; the disposition is part of a bodypart's
context, not part of the bodypart itself.

But I recognize that this battle is lost, and support moving ahead with
this specification; in our current situation, this is the useful thing to do.

Harald,

"Ancillary" may not be the appropriate example to induce the
discussion that follows, but it appears to be time to review the
context in which we are making these decisions and the "bodypart
context" questions themselves.

While I was mostly indifferent to this set of issues when they
first came up, some recent unpleasant experiences with systems
interpreting content-disposition in bizarre ways (see below)
have convinced me that it is time to revisit the issue.  Stated
more strongly, the current pattern of use for
content-disposition can be demonstrated to be causing
interoperability problems; such problems are usually considered
a strong argument for blocking things from progressing to or
beyond Draft and going back to the proverbial drawing board.


Explanation of the problem, for those who haven't seen it or
understood the symptoms (sorry, but this is going to be a little
long):

MIME was designed very carefully to interoperate to the extent
possible with MIME-ignorant and MIME-weak MUAs.  The main
failure in that regard was anticipated and accepted, i.e., that
encoding message components for safe transport would make them
difficult or impossible to read with MIME-ignorant (and really
stupid) readers, e.g., it was generally understood that
multimedia, multi-character-set, MIME mail would be the end of
convenient mail reading with "cat".  But, the encoding issue
aside, the intent was that relatively simple MIME messages
appear in useful and comprehensible form to a MUA-reader that
lacked extensive MIME capabilities (even if some useless
protocol chatter was inflicted on the user).

One feature of MIME that has turned out in retrospect to be
radical was that it changes the then-common metaphor of a
"message" with "attachments" to a "multiple body parts" model.
While many MUAs have been "taught" (more or less) to read MIME,
the "message and attachments" metaphor has persisted, both in
old MUAs that have been upgraded and in newly-developed ones.
In the latter cases (at least), that metaphor presumably
persists because users find it comfortable.  If their designers
are correct, we may have done a reasonable protocol job, but
slipped up on the UI implications.

Now content-disposition was, to some extent, supposed to solve
the "message and attachments" problem by permitting that model
to be specified by the sender in the context of the much more
general "body part" system.  In practice, it has often made it
worse. It appears to me that MUA designers have found it just
too painful to elicit the right information from users and that
their attempts to figure things out heuristically have either
failed outright or created a level of complexity that leads to
more subtle failures.  

For example, a number of popular MUAs (the five that I've
examined probably collectively include a very large fraction of
the desktops in the world among their users) interpret valid but
unnecessary content-disposition fields as an indication that the
mail is "no message, just attachments".  All of them are
sufficiently attachment-competent that the user can open the
text attachment (what the sender intended to be the message
body) without much difficulty.  But, for most of them, that
requires an extra step for the user, which causes irritation.
Worse, attempting to reply to the message and include some of
the original text ranges in difficulty from "time consuming and
irritating" to "nearly impossible" and facilities in those MUAs
for quoting, etc., usually are not available.

This is not a situation in which those receiving MUAs are
non-conformant: their behavior is well within the interpretation
flexibilities of content-disposition.  But, from a user
standpoint, we have MUA-senders producing conforming
content-disposition fields that produce bizarre behavior in
conforming MUA-receivers/readers.

If we did this stuff (or parts of it) with multipart/related,
the (IMO very clear) "what to do with multipart when you can't
figure out what is going on" rules would protect us.  The worst
case would be that the user would see the disposition protocol
elements, not that various hidden mechanisms would essentially
foul up the message.

Of course, an alternative might be much more detail, and
conformance rules that contain a lot of "MUST"s, about just
exactly where and how content-disposition is to be used.  We
haven't had much success with that type of approach lately, but
it is an alternative.  Of course, going that way probably would
require simplifying content-disposition considerably, which
might impact "ancillary" and other debatable add-ons.

There is a case to be made that the marketplace is beginning to
speak clearly to us here and that some radical reconsideration
is in order.

    john



<Prev in Thread] Current Thread [Next in Thread>