ietf-nntp Fwd: HDR/OVER LIST OVERVIEW.FMT thoughts

[Russ Allbery]

(Note for other folks -- the spam control measures on this list are
implemented via a second list that you have to join to post.  If you have
trouble posting, also subscribe to ietf-nntp-post at academ.com.)

Forwarded with permission.


Date: Thu, 3 Apr 2003 19:50:15 -0500
To: Russ Allbery <rra at stanford.edu>
From: Jim Calvin <jim at jced.org>
Subject: HDR/OVER LIST OVERVIEW.FMT thoughts

>I have re-read the discussions, and believe that I have a firmer grasp
>of why HDR is sometimes limited and/or coupled to OVER.  However, I
>still don't like coupling the two in the actual protocol, and I don't
>like designing a mechanism where clients have to guess what is
>supported.  Given this, and the fact that OVERVIEW.FMT is still being
>discussed, I propose the following:

<snip>

I've been following along this discussion and have almost replied a 
couple of times.  I'll wade in this time - hopefully not too far 
afield.

Seems to me there are two things tied up in the discussion:

1. what should be possible via the NNTP protocol
2. how a server tells a client what's an efficient way to retrieve 
header data from this particular server implementation.

What's possible should be neutral to any implementation - possible 
but it's usage might make some server admin unhappy. As an example, 
there may be implementations for which getting to the OVERVIEW 
database is no better than parsing the article (unlikely perhaps, but 
possible).

Perhaps LIST EXTENSIONS should have a means to say explicitly which 
header fields are "efficient" for the server. In part that's what 
LIST OVERVIEW.FMT probably did at one time. But at this point, it 
seems a little too tied to a particular implementation.

At the same time, an administrator may want to deny access via HDR to 
things that are not efficient for her server to access. Perhaps then,

LIST OVERVIEW.FMT provides just the format for OVER

LIST HDR.AVAIL provides what is accessible via HDR in the form of

header1~
header2~
header3~
ALL

Where "~" (or some other token) indicates "this is efficient for this 
server to retrieve." The ALL token says the server will retrieve any 
header that can be found. The example above says that the server will 
retrieve any header, but header1-header3 are efficient.

An efficiency minded server might return the same list of headers for 
the two LIST commands.