ietf-nntp Alternative HDR parameter proposal

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

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

Hm.  That's somewhat less than ideal, just because it's kind of opaque to
a human, but I can't really think of anything better.  (:* looks like a
metadata name instead, although I guess it's a possibility.)

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

[...]

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

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.

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).  Otherwise, we reintroduce the overview
mess and I think we've gotten the best solution to that one that we're
going to get.

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