--On Wednesday, 03 July, 2002 22:59 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
I, at least, would find such comments helpful. But I'd also
like to hear comments from at least one person responsible
for a general-purpose MTA (as distinct from a fax-over-email
engine) who expects to implement this feature and how they
propose to do so and how this feature fits in.
There are two cases here: Client and server implementations.
I definitely plan to implement the server side of this
proposal. From that perspective all of the proposed variants
are easy to implement as long as you have a source of conneg
information to tap. I plan to use an LDAP attribute for this
purpose.
...
Interesting. Instead of "ask the receiving client", you would
rely on a database that proported to know the client's behavior
and capabilities. That certainly makes implementation easier
and might also deal with the relay situation by permitting the
first (and subsequent?) relays to ask the database rather than
replying "no clue about the client, I don't deliver to it" (the
latter is one of the cases I've been concerned about). However:
(i) It would seem to me to be reasonable to write this option
down (as an option) rather than leaving implementers guessing.
(ii) Given the notorious "wks" experience, with trying to put
target host capabilities into an ancillary database, it seems to
me that this would further justify experimental status so that
we can get some sense as to whether the database would be kept
adequately up-to-date. Certainly our experience should cause us
to be skeptical about that.
The client side for a general-purpose MTA is much harder, but
not because of any aspect of the protocol. The issue I have
there is how to match up an arbitrary set of site-provided
conversion operations with the current group of recipient
feature sets. I don't see a good solution to this other than
making the whole thing something the site specifies, and if I
do that I see little chance of the capability actually being
used by enough sites to justify the cost of implementation.
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).
I can only agree with both of these comments and complement you
on the clarity of your explanation of them.
john