ietf-nntp HDR

[Russ Allbery]

Andrew Gierth <andrew at erlenstar.demon.co.uk> writes:
>>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

>>> what about servers that don't have an overview? (I don't think diablo
>>> does, as I recall it stores the actual headers of the article in its
>>> index). These would have to work around the issue by "fixing" the
>>> Lines: header so that it showed the correct value.

>  Russ> They could return 503 for HDR requests for those headers.

> that's not nice, because it means that clients can't rely on "HDR Lines"
> working (which it should).

> Actually, I think that making OVER work right in such cases involves
> fixing the Lines: header too.

Well, making it work right either involves changing the articles to have
accurate Lines headers and then returning that value or returning the
Lines data out of overview.  Yes?  Does anyone think that the command
should return the contents of the Lines header of the article when that
data is inaccurate?

If the answer to that last question is no, then we can step neatly through
the problem of various internal implementations by not mentioning overview
at all.  Instead, we simply say:

    HDR requests for the header "Lines" SHOULD return accurate line counts
    for the articles, regardless of the contents of the Lines: header of
    the article.  Similarly HDR requests for the header "Bytes" SHOULD
    return accurate byte counts for the articles.

If the server fixes the Lines header to be accurate, then returning the
value of that header from the article will amount to the same thing as
getting it from the overview.

> I'm just wary of special-case kludges like this.

Yeah, me too.

The leading colon feels like a special-case rule in the parser, though,
which feels to me like just moving it around.

Hm.  Another possible approach would be to add an optional additional
argument to the OVER command to limit its returns to a single piece of
data, and then people who want the accurate line counts can use:

    OVER <range> Lines

and HDR could avoid having any special cases.

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