--On Friday, 05 July, 2002 23:01 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)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