ietf-nntp Alternative HDR parameter proposal

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> - The label for the HDR extension can take one of the following two
> forms:

> 	HDR
> 	HDR ALL

> - In the first form, the set of headers that may be retrieved from the
> server is limited and must be discovered by the client.  I propose that
> this can be done by using either the HDR command with _no_ arguments or
> a new LIST HEADERS command (I have no preference, this can be determined
> by the WG).  In either case, the output of the command is a list of
> available headers/metadata (identical to OVERVIEW.FMT without the
> suffixes).

This is an interesting proposal, and I think I like it at first glance.
However, it does have the problem that Charles mentions, namely that what
headers are available can change over time and that it's difficult to
manage software in a way that avoids this.  (It's easy enough for someone
to say that the databases should be rebuilt if you change what headers
you're indexing, but that's an operation that can literally take days on a
server with a full newsfeed and decent retention.)

I'd be curious to hear Andrew's reaction to this.

The problem with the set of headers that are available changing over time
is one that we're going to have regardless of *how* we list what headers
are available via HDR, so maybe we just document that and live with it.
It should be an infrequent operation.  The results that I'm getting from
my question about LIST OVERVIEW.FMT so far seem to indicate that client
authors do find such information useful as a hint even if it's not
completely reliable.

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