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