ietf-nntp OVER and HDR parameter comments

[Matthias Andree]

Russ Allbery <rra at stanford.edu> writes:

>> Similarly, its seems as if the HDR parameter proposal is a way of
>> linking HDR back to the OVER implementation (or some other
>> implementation decision).
>
> No, it's an attempt to document a very widespread implementation choice.
> Servers have found a need in practice to restrict the use of HDR to
> particular headers that are already indexed.  I don't want to second-guess
> that decision; there's a great deal of operational experience behind
> it.

My past experience with leafnode and Perl scripts that partially pull those
"control.cancel" newsgroups in reader mode say that INN at some time
seemed to be much faster when XHDR requested headers that were in LIST
OVERVIEW.FMT, and slower for headers outside the overview. (I was
sending XHDR Newsgroups: to only download from control.cancel the
cancels that applied to the newsgroups I subscribed.)

Please skip this paragraph if the current draft already provides this
info: 1. as long as the return code for "the administrator prohibits you
to use HDR for this header" is distinct from "HDR not implemented",
that's fine with me. 2. I'd also appreciate if there was a clear note on
whether the canonical syntax is HDR Message-ID <range> or HDR
Message-ID: <range> (mind the trailing colon).

> The server does not necessarily have the article.  It's increasingly
> common to have a collection of reader servers with full feeds of overview
> information and a local article cache, which don't retrieve the actual
> article from an upstream server until a client requests it.  It's
> potentially very slow to open the article and parse it.

It would be logical if these caches then requested the HDR info from
their upstreams -- if possible, that is.

-- 
Matthias Andree