Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

--On Friday, 05 July, 2002 23:01 -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.

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