ietf-nntp LIST EXTENSIONS caching

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> Okay, here's the text I now have. Can people please comment on it? I
> will change the SHOULDs to MUSTs iff Russ tells me to.

> [In 5.3.2]

>    An NNTP client MUST NOT rely on any cached results from this command,
>    either earlier in this session or in a previous session, remaining
>    correct. While some extensions are likely to be always available or
>    never available, others will "appear" and "disappear" depending on
>    other changes. Furthermore, a server SHOULD NOT use cached results in
>    relation to security, privacy, and authentication extensions. See
>    Section 11.6 for further discussion of this topic.

You can safely make that second SHOULD NOT a MUST NOT, I believe, based on
the argument I mentioned in my other message.

> [and then]

> 11.6 Caching of LIST EXTENSIONS results

Take a look at my proposed text here and see what you think.  For me, it
was somewhat clearer and stronger, but I'm not wedded to it.  I do think
that this paragraph:

>    Therefore a client sending private information, such as a cleartext
>    password, to a server SHOULD check the security state of the link and
>    the identity of the server immediately beforehand and SHOULD NOT rely
>    on the (cached) results of any previous check. How such a check is
>    done will, of course, depend on the particular facilities available
>    from the server.

is confusing, since LIST EXTENSIONS isn't how one does that and the
section is about LIST EXTENSIONS.  Insofar as we need to talk about
down-negotiation of the TLS encryption strength, I think that can be
safely deferred for the TLS draft.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>