ietf-nntp HDR parameter proposal

Russ Allbery rra at stanford.edu
Wed Mar 19 10:39:27 PST 2003


I've thought about this some more and reviewed some of the earlier
discussion since I was forgetting much of that, and I think I'm coming to
the conclusion that Charles is right.  I apologize for my earlier somewhat
knee-jerk reaction; I should have taken more time to think first.

I do want to propose a slightly modified form of the idea, though, based
on the following assumptions:

 * Most sites do not add additional headers to overview due to increases
   in bandwidth cost, and the time frame for another header becoming
   common in overview is along the same timeframe as how long it would
   take to release a new version of this standard.

 * Much of the addition of new headers to overview is at small sites that
   are probably also running software that will allow HDR on any header,
   since they care more about usability than speed.

Accordingly, here's the proposal:

The HDR extension is indicated by one of the following extension strings:

    HDR
    HDR BASE
    HDR BASE EXTRA
    HDR ALL

HDR BASE indicates that HDR is supported for the base overview headers
Subject, From, Date, Message-ID, and References and the metadata items
:bytes and :lines.  HDR ALL indicates that HDR is supported for all
headers.  HDR BASE EXTRA indicates that HDR is supported for all of the
headers included in HDR BASE plus some additional headers (not specified),
but not for all headers.

If neither BASE nor ALL are given, HDR is supported on some other set of
headers, and the exact set of headers isn't specified.

Clients are expected to use the parameters to the HDR extension as a hint
on what techniques to use.  For HDR ALL or HDR BASE EXTRA, clients can try
HDR first when searching on arbitrary headers; HDR BASE EXTRA will
generally mean that the server is including "useful" headers so there's a
reasonable chance that the try will succeed.  Servers like Typhoon can
just advertise HDR BASE.

One problem is that HDR BASE indicates that Xref is *not* in the HDR
database, when it's nearly universally included in overview and therefore
probably is.  On the other hand, HDR BASE EXTRA just because one is
including Xref may not be a good idea.  We could just add Xref to the base
HDR headers, but I kind of hate to do that when it's not part of the base
OVER headers.

(I'm not particularly wedded to any of the exact terms, just the general
concept.)

I think this would provide slightly better capture of the situation than
Charles's proposal without the dependency on LIST OVERVIEW.FMT; it's only
not as precise for sites that add various additional headers to overview.

What do people think about this idea?

(Charles, apologies for not having thought this through better and for not
reading your proposal closely.  Thank you very much for bringing it
forward again.)

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



More information about the ietf-nntp mailing list