ietf-nntp HDR

Andrew Gierth andrew at erlenstar.demon.co.uk
Sat Jan 5 07:01:54 PST 2002


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

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

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

The only application I can think for that is to do client-side
filtering based on incorrect Lines: headers.

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

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

the text for "Bytes" should not say "accurate" (for the same reason that
overview bytecounts aren't guaranteed)

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

 Russ>     OVER <range> Lines

this is getting very close to the original HEADERS proposal....

-- 
Andrew.



More information about the ietf-nntp mailing list