ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?

[Clive D.W. Feather]

Peter Robinson said:
> But I
> am thinking of the case of a user using the news server of their
> connectivity provider (IP-based authentication) and posting to Usenet
> (i.e. in public).  If the client only wants to use LIST EXTENSIONS to
> determine whether it can use OVER or HDR, it seems reasonable to cache
> the LIST EXTENSIONS response (for a day or a week maybe) which is
> neither sensitive nor likely to change frequently.  Of course the client
> must be able to cope with those commands failing unexpectedly.

Having thought about it, I agree with this.

Proposed change: current text (this has recently changed for other
reasons):

    An NNTP client MUST NOT cache (for use in another session) any
    information returned if the LIST EXTENSIONS command succeeds.
    That is, an NNTP client is only able to get the current and correct
    information concerning available extensions at any point during a
    session by issuing a LIST EXTENSIONS command at that point of that
    session and processing the response, and the server MUST ensure that
    those extensions currently listed in the returned information are
    available.
    [...]

becomes:

    An NNTP client is only able to get the current and correct
    information concerning available extensions at any point during a
    session by issuing a LIST EXTENSIONS command at that point of that
    session and processing the response, and the server MUST ensure that
    those extensions currently listed in the returned information are
    available.
    [...]
    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.

I will also craft some Security Considerations text.

> No it is not.  If the client is using LIST EXTENSIONS to decide whether
> and how to provide security (privacy or authentication) then it becomes
> much more important.  

And if it does it in a broken way, it's broken.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646