Note: This message was generated automagically. An error was detected,
while processing the enclosed message.
--> Error description: No such local user
--> Error for: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
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); Sat 22 Jul 1995 01:56
Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP;
Thu, 20 Jul 1995 16:18:28 MET_DST
Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
Thu, 20 Jul 1995 16:20:04 gmt+2
Received: (from daemon(_at_)localhost) by dimacs.rutgers.edu
(8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA29623 for
ietf-822-list; Thu, 20 Jul 1995 09:11:08 -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 JAA29620 for
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Thu, 20 Jul
1995 09:11:01 -0400
Received: from kilsythe.banyan.com by warren.banyan.com with SMTP
(1.38.193.4/16.2) id AA21478; Thu, 20 Jul 1995 09:17:33 -0400
Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id
AA10517; Thu, 20 Jul 1995 09:12:08 +0500
Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA03539; Thu, 20 Jul 1995
09:16:11 +0500
From: tcrowley(_at_)kilsythe(_dot_)banyan(_dot_)com (Terry Crowley)
Message-ID: <BMSMTP80624467710(_at_)aberdeen(_dot_)banyan(_dot_)com>
In-Reply-To: <01HT2BTZ7TRWASBNL0(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
Reply-To: Terry Crowley <tcrowley(_at_)aberdeen(_dot_)banyan(_dot_)com>
Date: Thu, 20 Jul 1995 09:16:10 -0500
Subject: Re: Multipart/Alternative Compatibility Issue
To: Ned Freed <NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Content-Length: 1817
I use a couple of different MIME clients, none of which have any problems
with
getting at the data in multipart/alternative. The worst I've seen is where
multipart/alternative is treated as multipart/mixed, and this just isn't
that
bad.
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.
The MIME spec says that "Receiving user agents should pick and display the
last format they are capable of displaying." I'd argue that by just showing
the multipart/alternative object, those user agents have not done any picking.
From a practical point of view, this behavior, if typical of MIME user agents,
makes multipart/alternative significantly less useful. These aren't
abstractions. We give the customer a choice of what format to use, and they
are choosing to use the multipart/mixed form since they find that it
introduces less problems (e.g. users complaining to the mail administrator) in
real day-to-day heterogeneous message exchange. That's a fact, and no amount
of explaining the advantages of semantic accuracy will make them happy. They
just want to read the damn message (and probably delete it).
Terry
From ITUDOC(_dot_)ITUDOC(_at_)ITU(_dot_)CH Sat 22 Jul 1995 02:16