--On Wednesday, 03 July, 2002 22:59 -0700 ned.freed@mrochek.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