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

[Peter Robinson]

 Russ Allbery <rra at stanford.edu> wrote:

> Peter Robinson <pmrobinson at gmx.net> writes:
> 
> > Yes.  When it comes to security/privacy, I agree wholeheartedly.  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.
> 
> Usually NNTP connections are long-lived, and LIST EXTENSIONS is about as
> fast of a command as one can issue since the results are normally
> hard-coded into the server.

Fast from the server's point of view, but since it can't be pipelined
even with base commands, it takes at least a whole round-trip time as
far as the user is concerned.  If you're geographically distant from the
server (e.g. news.individual.net; admittedly not what I was talking
about above) or if you have a high latency connection, then all the
round-trips at the start of a session can add up to a significant time
(I mean significant to a human).  But...

> I'm not sure why anyone would bother caching;
> that smells of premature optimization to me.

<g>  You're probably right.  The reason that I'm tempted is that I'm
already storing it (+ the HELP response etc.) for informational purposes
only.  Given that (and the obility to parse the LIST EXTENSIONS
response, which I obviously need anyway), it's very easy (and hence
tempting!) to reuse it.

> I suppose that other people have pointed out in the past that the setup
> time for NNTP connections already isn't great, but NNTP connections were
> really intended to live for the life of the news reading session.

True.  This is not possible for an offline reader, although in that case
the client will normally be fetching a relatively large number of
articles etc., dwarfing the setup costs.

Peter