At 22:59 -0700 on 07/03/2002, ned.freed@mrochek.com 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.