At 22:59 -0700 on 07/03/2002, ned(_dot_)freed(_at_)mrochek(_dot_)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.