Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

> >here are a couple of trivial examples of the effect of a "downgrade to
> >LCD format" implementation strategy. 
> >
> >assume:
> >
> >recipient A accepts only HTML and plain text
> >recipient B accepts only PDF and plain text
> >
> >an HTML message sent only to A gets delivered as HTML, but if B is cc'ed
> >(or bcc'ed) on the message then both A and B get plain text (if the
> >client knows how to convert HTML to plain text).  A is accustomed
> >to receiving HTML from B and is surprised that there's an information
> >loss.
> 
> No - This is a standard M-P/A situation and should be sent to both as 
> such (just as if the original message was generated by the MUA and 
> packaged as M-P/A [which is the normal action of most of the MUAs I 
> know unless the user has overridden the send both option).

I don't follow your reference to multipart/alternative.  The source
message in the example is HTML only.  And I don't think anyone has 
proposed that the SMTP client performing a conversion should use 
multipart/alternative to include both the old and the versions -
if nothing else, the fax stuff that is driving this has had the
ability to use multipart/alternative for 10+ years and they obviously
don't consider it sufficient for their purposes.

Also, B might not want HTML, not even in a multipart/alternative - 
and it seems quite reasonable to me that B would specify this 
(since I don't want it either).

The fact that many MUAs generate multipart/alternative with text+html
by default should not be cited as if it were a desirable practice.
 
> >more seriously, a PDF message sent only to B gets delivered as PDF, but
> >if A is cc'ed on the message then the message is bounced for both A and
> >B because there's no good way to downgrade PDF to a format acceptable
> >to B (or the client doesn't know how).
> 
> This is a more complex case. It would/could be solvable by a Smart 
> MUA that acted the same as the HTML/Plain case by sending/creating as 
> M-P/A with Text/Plain and application/PDF versions. The "Best" 
> solution is if the MUA could also deliver a HTML copy (which would be 
> packaged between the Text and the PDF in the stacking order).

senders' MUAs are irrelevant to this discussion, unless they also perform
conversion based on SMTP CONNEG responses (which would reqiure them
to connect directly to recipients' ultimate MTAs - not likely)

the scenario is this - some MTA gets a message, it looks at the recipient
capabilities, and decides that it needs to convert the message to make
it acceptable to the recipients.  the point of my examples is to demonstrate
that there will be cases where there is no single message format that
is acceptable to all recipients, which implies that any MTA which attempts 
to deliver to more than one recipient at a time (and which uses CONNEG)
must be prepared to handle the case where different behavior is applied 
to different recipients - and this further requires RSET and/or 
close-connection-and-retry logic.
(even with a close RSET should be strongly recommended)

Keith