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