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