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); Sun 23 Jul 1995 23:34
Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP;
Sun, 23 Jul 1995 20:32:09 MET_DST
Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
Sun, 23 Jul 1995 20:33:35 gmt+2
Received: (from daemon(_at_)localhost) by dimacs.rutgers.edu
(8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id NAA05162 for
ietf-822-list; Sun, 23 Jul 1995 13:29:41 -0400
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by
dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12)
with ESMTP id NAA05157 for
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Sun, 23 Jul
1995 13:29:06 -0400
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id
<01HT6H116N288ZFTD0(_at_)INNOSOFT(_dot_)COM>; Sun, 23 Jul 1995
10:27:59 -0700
(PDT)
Date: Sun, 23 Jul 1995 10:11:48 -0700 (PDT)
From: Ned Freed <NED(_at_)innosoft(_dot_)com>
Subject: Re: Multipart/Alternative Compatibility Issue
In-reply-to: "Your message dated Thu, 20 Jul 1995 09:16:10 -0500"
<BMSMTP80624467710(_at_)aberdeen(_dot_)banyan(_dot_)com>
To: tcrowley(_at_)kilsythe(_dot_)banyan(_dot_)com
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Message-ID: <01HT7FU4EXI08ZFTD0(_at_)INNOSOFT(_dot_)COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
References: <01HT2BTZ7TRWASBNL0(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
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.
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.
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.
I completely agree. But so what? You've made a choice that at best is
no worse that multipart/alternative but at worst is considerably less useful.
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.
My experience has been exactly the opposite. I too sell MIME software and
the preference thus far has been strongly in favor of multipart/alternative.
But even if my experience agreed with yours, letting one broken agent dictate a
highly suboptimal strategy is only a good idea in the short term. Eventually
that agent will be fixed and then you will have angry customers all over asking
you why you encouraged them to do the wrong thing.
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).
Semantic accuracy is not the issue. I could not care less about it. Standards
and expected behavior are. Compliant agents exist and will do the right thing
with properly formatted messages. Eventually these agents will dominate and
your sop to one broken agent will change from a small and problematic asset
into a big liability.
Explaining this to a customer as a sematic issue is pointless as well. It needs
to be explained as an issue where compliance with the standards provides major
benefits. Show the customer how well it works with software that does support
the standard and explain that this one agent is broken. See if they cannot get
the vendor to fix it based on this explanation. And if they cannot, well, it
sounds to me like a golden opportunity to sell them some agents that do work!
Ned
From owner-winnews(_at_)microsoft(_dot_)nwnet(_dot_)com Mon 24 Jul 1995 00:17