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

At 14:27 -0700 on 07/03/2002, Dave Crocker wrote about Re: Last Call: 
SMTP Service Extension for Content Negot:

>At 04:40 PM 7/3/2002 -0400, Robert A. Rosenberg wrote:
>  >CONNEG appears at its root to be an attempt to avoid the "wasted"
>  >bandwidth and processing time/effort to create a M-P/A MIME message most
>>of whose content the Recipient is going to ignore after receipt. It also
>>removes the requirement that the Recipient is even capable of parsing a
>>M-P/A MIME message to locate the "correct" version of FAX which it can
>>understand/process.
>
>Hmmm.  As I recall, the specification was not developed with this goal in
>mind.  However I think that you are pointing out a trade-off in the use of
>ESMTP/CONNECT and Multipart/Alternative that is largely correct.
>
>(I say largely rather than completely because there are some feature
>combinations that define so many combinatorials, they could not be
>considered for M/A but are straightforward for CONNEG.)
>
>Still, you do raise an interesting perspective.
>
>d/
>

Thank you. I am looking at the issue from a overview perspective 
(IOW: How does CONNEG work vs. How would M-P/A work). Since I was not 
involved in the development of CONNEG, I do not know the intent of 
the developers - All I can comment on is the effect of its operation 
in comparison with other methods and state what the EFFECT of the 
choices made are (while taking the effect as the intent even though 
this linkage is probably spurious).

As to the multiple combinations, that was covered by my " 'wasted' 
... processing time/effort". Beyond a certain point, the generation 
of multiple versions (just to be complete) when only one (or a 
limited number) are going to ultimately be used is an exercise in 
futility.

The advantage of CONNEG is that you get the information to generate a 
full list of the different combinations you must produce. The issue 
is what you do then. Do you generate the requisite number of 
combinations and send them out as the minimal number of message 
copies (lumping together those addresses that can share a copy - even 
if that copy is not an exact match to the full capabilities of the 
receiver as in the case of sending a B&W Fax to a Color Capable 
Recipient).

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 while at the same time 
generating only the minimum number of copies to allow 
multi-addressing. IOW: A one copy (/limited number of copies) LCD 
"solution" is not the "Best" solution since it will produce a Fax 
that is not the same as would have been delivered if there were no 
other addresses.