Caching capability information

At 11:01 PM 7/5/02 -0700, [email protected] wrote:
>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.

It's not relevant to the current draft under discussion, but I'd like to 
flag that the (UA-driven) content negotiation approach (awaiting RFC 
publication) overcomes these caching concerns.  Indeed the design presumes 
caching to achieve 1-round-trip performance, but can correct itself (using 
a second R-T) if the cached information turns out to be incorrect.

#g


-------------------
Graham Klyne
<[email protected]>