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

At 15:15 -0400 on 07/04/2002, Keith Moore wrote about Re: Last Call: 
SMTP Service Extension for Content Negot:

>>  IMO, the ultimate aim (even if this is not practical) is to deliver
>>  to each recipient the same version of the Fax as they would have
>>  received IF they were the only addressee
>
>I think this is a reasonable and practical goal.  I don't think that
>recipient A should experience a difference in message quality
>(or worse, fail to receive the message at all) based on whether or
>not you cc'ed recipient B.
>
>>  while at the same time
>>  generating only the minimum number of copies to allow
>>  multi-addressing.
>
>I think this is an implementation decision.  It should be *possible*
>to do this (and it is), but it shouldn't be required of implementations.

Bad phrasing on my part (I had intended the minimal message count to 
be a target not a cast-in-stone requirement). If you must degrade 
into one message per address mode - so be it - BUT I think that if 
you are going to do so, you are cheaping out by not trying to add 
some minimal logic to run the chain of pending copies to see if any 
can be satisfied by the current version. I'm not asking for a full 
matrix analysis (which is the "Best"/"Optimum" Method) - just take 
them in order of the addresses and run the pending chain. This will 
probably not create the minimal count (except by luck) but can still 
reduce the count somewhat.


>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).

>
>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).

Note: I am assuming a 2 stage MUA where the messages are created and 
queued for delivery and upon connect, the MUA can drop out (if it 
wants) unneeded alternatives (instead of doing the transforms in real 
time). I see no reason that the M-P/A creation (with optional 
deletion prior to transmit) could not be a viable alternative for 
real-time transforms (at least in the case where the number of 
different variations is limited/minimal such as in the above case or 
in the case of a Fax where you must convert Color to B&W and/or 
support 2 or 3 resolutions). I am working in a Blue Sky mode with 
these comments and I'm just tossing out a best functionality case 
which must/will be modified by implementation and real-world 
constraints.

>
>So far I have not been able to identify conditions for which downgrading
>to LCD is a viable implementation strategy.  My conclusion is that
>implementations that support CONNEG and that attempt to deliver to
>mutliple recipients in one transaction MUST be prepared to do RSET and
>split up the delivery if it becomes evident that delivering the same
>version of the message to all recipients is not appropriate.
>
>Keith

Note: I am offering all of the above ideas/processing methods as 
suggestions for possible listings of ways to reach the goal of 
delivering the message to the recipient as if in a one-to-one mode 
while trying to minimize the overhead that is associated with 
one-to-one mode by leveraging the processing overhead of the message 
generation/uploading for additional addressees. As someone who has 
not been associated with the evolution of this effort I think my "new 
perspectives" can, at times, point out methodologies that might not 
be obvious those who have participated in its design. OTOH, I may be 
totally of base and my ideas may have already been raised and 
considered <g>.