ietf-nntp Alternative HDR parameter proposal

Andrew Gierth andrew at erlenstar.demon.co.uk
Thu Apr 3 14:23:52 PST 2003


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

 >> - 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).

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

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

well, in my case the idea of rebuilding the overview is completely out
of the question.

What I ended up doing on the one occasion when I changed the set of
headers allowed for XHDR was to simply accept that the results would
be inconsistent for articles already on the spool. i.e. XHDR on a
newly-added header would return as though the header were absent on
the old articles even if it were actually present. This isn't a nice
clean solution, but it's pretty much inevitable in practice.

As I see it, I think there should be:

  - a way that the client can tell whether the server supports HDR on
    all headers (including ones the server has never heard of)

  - otherwise, a way that the client can tell which headers the server
    _intends_ for HDR to be supported for

I think the best solution is to ditch any relationship between HDR and
OVERVIEW.FMT and go with something along the lines of Ken's version
(using some sort of LIST subcommand to get the header list, don't try
and overload the HDR command itself). Perhaps say that the list of
headers available via HDR SHOULD include the standard overview headers.

 Russ> The problem with the set of headers that are available changing
 Russ> over time is one that we're going to have regardless of *how*
 Russ> we list what headers are available via HDR, so maybe we just
 Russ> document that and live with it.

yup.

-- 
Andrew.



More information about the ietf-nntp mailing list