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

At 22:59 -0700 on 07/03/2002, [email protected] wrote about Re: 
Last Call: SMTP Service Extension for Content Negot:

>One final comment. A general-purpose MTA using arbitrary site-provided
>conversion routines doesn't have the luxury of being able to bound the
>performance or other characteristics of those conversion routines. This makes
>the entire convert-on-the-fly scenario problematic in ways that 
>don't arise for
>a device built around a specific, limited and well understood set of 
>on-the-fly
>converters, regardless of whether that device is a fax machine or something
>else entirely. Indeed, if I were to implement based on past bad experiences
>with various general-purpose conversion routines I'd be likely to break the
>problem down into three steps: (1) Collection of conneg information 
>online, (2)
>Message splitting and conversion offline, (3) Sending the resulting 
>emssages to
>their destination. I doubt I'd support using REQUIRED in (1).

As I said in another reply, one POSSIBLE solution to this problem is 
to go for a methodology where the CLIENT does the transforms and 
ships one copy of the message as Multi-Part/Alternate with ALL the 
transforms to the MTA. The MTA then decides what Transforms are 
needed (based on the CONNEG info) and grabs out those that are needed 
from the M-P/A set. This removes the Real-Time transform overhead by 
off-loading it to the Client. It is, of course, based on a model 
where the number of different transforms are limited AND can be 
enumerated in the absence of info on the capabilities of the 
designated recipients.