On 4/12/99 at 9:40 AM -0400, John C Klensin wrote:
"Ancillary" may not be the appropriate example to induce the
discussion that follows...
Indeed, I think "ancillary" has nothing to do with the discussion you
start below. In fact, I'm not even convinced that it is a particulary
interesting standards issue, but may be simply an issue of "how do we
deal with people who can't follow the rules."
I think (and correct me if I've missed the point), your entire
discussion comes down to this section:
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".
This seems to simply say that there are certain sending clients out
there which are generating "Content-Disposition: attachment" for text
parts which are not intended by the author to be attachments, and
that this leads to bad behavior on the part of recipients who honor
the C-D. A few points:
1) Broken sending UAs are broken sending UAs. It is possible to have,
and we have seen, UAs who send HTML in body parts that are text/plain
and who send non-US-ASCII text in body parts with incorrect charset
information. When these arrive at the other end which honors the
(conformant) labelling, bad things happen. This is not the fault of
the MIME standard which requires labelling; it's the fault of poorly
implemented *sending* UAs.
2) There are clearly cases (I make use of them myself) where "no
message, just attachments" is truly the intention of the sender of
the message: I want to send a text document to someone who is
expecting a text document. To put such information into the body of
the message in my UI simply makes the process of getting it into an
attachment one step more annoying, just as is the case you cite.
3) This can easily be dealt with by receiving UAs and you should talk
to your UA writer about dealing with this bug. We've done such things
before. In this case, we could throw in a piece of code which says,
"If the message is multipart and the first part is text, display it
inline regardless of the Content-Disposition." Even better, have this
as a message by message toggle which you can set for yourself.
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.
You leave out the key factor: These messages are conforming, but sent
*against the intentions of the message authors*.
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.
I'm waiting patiently to see the long list of complaints sent to the
bug list for my UA. I don't. I don't even remember seeing one of
these when last it was my week to do the bug list review. I don't see
any marketplace speaking clearly to us and no justification
whatsoever for "radical reconsideration." That seems like utter
hyperbole on your part, John. There is a serious lack of real
examples in your message of a widespread number of UAs that are
sending out this broken Content-Disposition. Until such time as there
is such a demostration of a real problem, I must insist that this is
not an IETF issue.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102