> --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.
Writing it down would be fine with me, although to be honest this struck me as
the obvious way to do it. OTOH, there certainly have been cases in the past
when I refrained from documenting what I thought was obvious in one of my own
drafts, only to find it was nothing of the sort.
> (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.
I think the differences between this and wks far outweigh the similarities.
Specifically, the major problem with wks records was that the authority
over/responsibility for wks records and authority over/responsibility for the
aspects of systems wks describes tended to be disjoint. Back in the days when I
maintained a reasonably heftly DNS zone I never had enough time to keep wks
records up to date with all the changes the various sysadmins kept making, and
after a while I stopped trying. And of course the sysadmins didn't have the
means to maintain this information in the DNS themselves.
The situation with an LDAP directory used for messaging is quite different.
Such directories often already maintain a bunch of user-settable information
(e.g., filtering rules, personal address book) and typically provide the means
(e.g., a web interface) for users to maintain and modify that information
themselves.
Of course having such a capability doesn't mean users will actually take the
time to use it. I suspect that's going to be very dependent on both need and
the quality of the user interface; presenting raw media feature sets definitely
isn't the way to go ;-)
> > 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.
Thanks!
I had a couple of other thoughts about this over the past couple of days:
(0) There are/will be additional ways to obtain conneg information: In
DSNs or MDNs, through LDAP queries, via RESCAP, or through direct
database queries within a single mail system. The database/directory
mechanism can be used to advantage in all of these cases.
(1) Caching of conneg information is certainly possible and may even
be desireable. Indeed, conneg information returned in DSNs or MDNs will
have to be cached in order to be useful. This document doesn't discuss
caching, and while caching isn't required in the ESMTP context some
discussion of it nevertheless makes sense.
(2) The use of caches really opens the door to conneg in the context
of relays in ways that nothing else does. For example, imagine a relay
that doesn't do any content transformation of its own but does do forward
conneg requests to populate a cache. It then offers the information it
has in that cache when it acts as a server. This may sound kind of cool
at first glance, but as the cache comes and goes it would tend to
violate the least astonishment principle in fairly major ways.
Issues also arise if multiple relays are used, each with a separate
cache. Care is needed here to preserve the ability to "rack and stack"
mail relays without undue consequences.
This isn't a typical cache since the goal isn't to minimize the number
of forward queries that are done. The intent here is to provide the
information from those queries in a completely different context.
The variability problems here can be solved by going to either
extreme: Ban caches of this sort entirely or insist that components
that actually perform content transformations cache conneg information
for a fairly long period. (It should be obvious that having intermediates
cache information is risky and doesn't solve the problem.) At first I
thought the right answer was to ban this stuff, but on reflection I think
the use of DSNs and MDNs to return conneg information argue for a
mandatory cache in the transformation agent.
Ned