--On Friday, 05 July, 2002 23:01 -0700 ned.freed@mrochek.com 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. Ned, Again, the more of these sorts of things get written down, even as experimental alternatives for further explanation, the happier I would get about the whole picture. Beyond a fairly short list of specific problems (which I think are being addressed), my most significant concern about this proposal is that, as it stands, it appears to be a piece of isolated protocol work that gets injected into an [E]SMTP environment that we know to be a little bit fragile. Anything that can be done to limit that fragility or its impact -- restrictions to fax, retrictions of the relay case(s), explanations of plausible ways to apply the protocol in a safe way, etc. -- would, it seems to me, help a great deal. Which of those are chosen seems to me to be less important. But the current document, without any of it, seems to be an invitation to low-quality implementations that conform to creative readings of a syntax and somewhat underspecfied semantics and thereby get the mail environment into trouble. john