ietf-nntp Alternative HDR parameter proposal

[Clive D.W. Feather]

Russ Allbery said:
>>> C> LIST HEADERS
>>> S> 215 headers follow:
>>> S> *                   <= means all headers
>>> S> :lines
>>> S> :bytes
>>> S> .

> I like using * better than a different response code.  It's more obvious
> to a human what's going on even if they're not staring at a standard.

Okay, I've now written it up. Two remaining issues:

(1) It turns out that * is a valid header name! That is, an article in our
specification or a message in RFC 2822 can contain a header line:

    *: this is a valid header
    !!!!!: for the matter, so is this.

I've therefore used a lone colon for this purpose.

(2) The handling of inconsistent overview databases is inconsistent between
this and LIST OVERVIEW.FMT. Let me explain:

When we were looking at the problem back in April, I made the following
suggestions:

    OVER output MAY, but SHOULD NOT, contain headers not listed by LIST
    OVERVIEW.FMT (that provides one path for servers to upgrade the database;
    modify the overview.fmt file only after they know the database is
    consistent once again).

    If the command returns "Header:full", then absence of that header
    from OVER output means that the article does not contain that header,
    guaranteed.

    If it returns "Header:full ?", then the absence of that header from
    OVER output does not guarantee its absence from the article (another
    way of indicating possible inconsistency).

Russ said to go with the first two of these but not the last.

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.

This is consistent in itself, but it's inconsistent with the text I have
for LIST HEADERS:

    the response should indicate the situation for a newly-arrived article

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

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