6.1.1 says, "When the KRS method has been specified by the sender, the
first step for the recipient is to consult its local cache of key
authorizations, if any." Later, 6.1.4 says, "Time to live. Responses
SHOULD be cached by the verifier."
I read the 'if any' and SHOULD as indicating that caching is optional.
Sounds to me like you convinced at some point in the past that caching
should be optional.
miles
--- Michael Thomas <mike(_at_)mtcc(_dot_)com> wrote:
There's nothing optional about the KRS cache in the IIM
code. I'm not sure what sort of argument somebody could
offer up to change my mind on making it optional. I'm not
sure why another implementation would come to a different
conclusion given the manifest performance improvement for
almost no effort (the caching logic is less than a page of
code.)
> If you want to ensure deployment of caches, you'll need to make
the interface
> such that no other option is viable.
Keeping mail in MTA memory for significantly longer periods
of time for no good reason is a self-healing problem: those
that do it will be Darwin-awarded.
> A better analogy is to compare the deployment of web caches -
which is spotty
> at best and primarily done by a subset of ISPs to save money.
Web caches help in the same way that upstream resolver
caches help. However the analogy is imperfect because the
likely deployment model is to verify at edge MTA's that
handle large amount of email, vs. individual web
browsers which only see their very narrow view of the
world. A cache on a large scale MTA is very much more
akin to an edge caching resolver than an individual
web browser's cache.
Mike