Re: ietf-nntp New wording on article numbers

[USENET news manager <[e-mail]>]

Jon Ribbens wrote:
>
>USENET news manager wrote:
>> with (incomplete, see further comments below)
>> 
>>     If no articles are available in the group, the estimated count SHOULD be
>>     zero. In that case, the first and last article numbers MUST either 
>>     both be zero, or ...
>> 
>> where the right text for "..." is not entirely clear since I'm not sure what
>> servers other than INN do. 
>
>I don't think the above will work, because the estimated count being
>zero is the only way of detecting that the group is empty, by
>the sounds of it. 

No, the other way is for GROUP to return a non-empty range and appropriate
non-zero count, and for the client then to find that none of the articles
exist. Just as if all the articles in the group were ancient, and were deleted
by an expiry run between the GROUP command and the client attempting to retriev 
the articles.

>I would prefer:
>
>    If no articles are available in the group, the estimated count MUST be
>    zero. In addition, the first and last article numbers MUST either be
>    equal, or the first article number must be greater than the last article
>    number. If articles are available in the group, the estimated count MUST
>    NOT be zero, and SHOULD equal the number of articles available.
>
>with perhaps a note saying which of the options is preferred for people
>writing new servers (I would prefer first>last, as I said before).

I'd be reluctant to say that the estimated count for a non-empty group 
SHOULD equal the number of articles available. It is potentially a lot more
overhead for the server to give an exact figure (e.g. scanning a directory 
to check which articles actually exist - maybe several thousand articles in 
high-volume groups), and it may in any case be rendered incorrect (by
cancels or expiry)  while the client is accessing the group. Requiring it to
be no greater than (last article - first article + 1) would make a lot of
sense, though, lest someone decides the easy option is always to return
999999999 or other "larger than could ever be in the group" number, with
dire consequences for clients allocating correspondingly-sized arrays to
store per-article information.

>> If so, it would be beneficial to document that. Clients could then use the
>> high article number (if non-zero) to tidy .newsrc (marking all articles up to
>> and including it as read, for example, reducing a possibly-long list of read
>> articles to a single range).
>
>This is not necessary. If the group is empty, the client may mark
>all articles between 1 and the highest article number it has seen
>previously as unavailable, no matter what the first and last
>article numbers in the GROUP response are.

True, but the last high article number seen in the group may be a lot lower 
than the server's current highest-allocated number, if the group hasn't been 
read by the user for months. Not a particularly important detail, though.

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)