Note: This message was generated automagically. An error was detected,
while processing the enclosed message.
--> Error description: No such local user
--> Error for: NED(_at_)innosoft(_dot_)com
Returned mail follows.
---------------------------------
X-Envelope-To: gyurik(_at_)frodo(_dot_)tii(_dot_)matav(_dot_)hu
Return-Path: <owner-ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>
Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu
(SMTPSRV); Thu 27 Jul 1995 12:30
Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX
V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST
Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
Mon, 24 Jul 1995 17:08:12 gmt+2
Received: (from daemon(_at_)localhost) by dimacs.rutgers.edu
(8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for
ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400
Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by
dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12)
with SMTP id JAA17471 for
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Mon, 24 Jul
1995 09:55:54 -0400
Received: from kilsythe.banyan.com by warren.banyan.com with SMTP
(1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400
Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id
AA11799; Mon, 24 Jul 1995 09:56:53 +0500
Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995
10:01:01 +0500
From: tcrowley(_at_)kilsythe(_dot_)banyan(_dot_)com (Terry Crowley)
Message-ID: <BMSMTP80659212276(_at_)aberdeen(_dot_)banyan(_dot_)com>
In-Reply-To: <01HT7FU4EXI08ZFTD0(_at_)INNOSOFT(_dot_)COM>
Reply-To: Terry Crowley <tcrowley(_at_)aberdeen(_dot_)banyan(_dot_)com>
Date: Mon, 24 Jul 1995 10:01:00 -0500
Subject: Re: Multipart/Alternative Compatibility Issue
To: Ned Freed <NED(_at_)innosoft(_dot_)com>
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Content-Length: 4243
It depends on what you mean by "bad". ("Imagine every atom in your body
exploding at the speed of light...OK, good safety tip, don't cross the
beams.") OK, not that bad if you get one of these messages every couple
days,
but imagine you have 150 messages in your inbox, every one of which
requires
that you go through this multi-step process just to look at what might be a
two sentence message. I think that's worse than bad, that's horrible. And
I
can guarantee it would be sufficient to be a deal-breaker in many cases.
I'm
sure you're familiar enough with the commercial market to know that
pointing
fingers and saying "it's their fault!" doesn't get you very far with a
customer who just wants things to work.
Say what? What you've effectively done here is argue against your own chosen
approach! You're the one that has chosen to package multipart/alternative as
multipart/mixed, not me!
By packaging things as multipart/mixed instead of using
multipart/alternative
properly you guarantee that everyone with a *compliant* MIME agent has to go
through the very process you deplore. Were you to choose to package things
properly you would only have this problem with clients that treat
multipart/alternative as multipart/mixed, and no choice you make is going to
fix this behavior, so you'd best stop trying.
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 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?
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. 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. 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.)
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.
Terry
From "HTMVAX::MX%\"4AD-L(_at_)AMERICAN(_dot_)EDU\""@tiiv04.tii.matav.hu Thu 27
Jul 1995 13:20