ietf-nntp LIST HEADERS inconsistency issue

Clive D.W. Feather clive at demon.net
Wed Oct 8 01:17:40 PDT 2003


This one is still in my mailbox and so should have been in the issues list:

The handling of inconsistent overview databases is inconsistent
between LIST HEADERS and LIST OVERVIEW.FMT.

We agreed the following text for LIST OVERVIEW.FMT:
| Suppose the sysadmin decides to change the overview database collection
| so as to stop collecting X-Old-Info and start collecting X-New-Info. She
| doesn't rebuild the database, but just lets the change happen gradually.
| To implement the above, she must:
| (1) Remove X-Old-Info from the overview.fmt file.
| (2) Change the overview collection rules.
| (3) Wait until all pre-change articles have expired (say 1 month).
| (4) Add X-New-Info to the overview.fmt file.

but LIST HEADERS has:
| the response should indicate the situation for a newly-arrived article

I asked:
>> So do we change LIST HEADERS to match the above (that is, HDR MAY work
>> for headers not listed by LIST HEADERS), or do we change both LIST
>> OVERVIEW.FMT and LIST HEADERS to provide some way of saying "some
>> articles have this but not all"?

and Russ replied:
> LIST HEADERS and HDR are a slightly different case from overview because
> HDR has an unambiguous return code indicating "this header isn't in the
> database" that can't be mistaken for "this article doesn't have that
> header."  However, if someone goes HDR content-type 1- and some of those
> articles have the Content-Type header in their database and some don't,
> I'm not sure how to respond to that.  I think the server would have to
> reject the command.  So maybe that resolves to the same issue.

I think that rejection would need to be explicit in the specification; it's
not the obvious thing to do.

> My immediately inclination would be to say that you can't advertise things
> in LIST HEADERS until they work for all articles, which would be the first
> of your two options (although I don't think we need to say that HDR MAY
> work for headers not listed by LIST HEADERS -- I'm not sure what would be
> served by saying that explicitly).

I think it makes it clear.

> Otherwise, we reintroduce the overview
> mess and I think we've gotten the best solution to that one that we're
> going to get.

Indeed, which also has the benefit of consistency with LIST OVERVIEW.FMT.

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



More information about the ietf-nntp mailing list