Re: ietf-nntp New wording on article numbers

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

Jack De Winter wrote:
>...  At the very least, I would like the wording to explicitly
>state what an empty group looks like, what a group with one article,
>and what one with many articles look like.  This would ease implementation
>for people unfamiliar with the specs.

I would have placed the emphasis slightly differently, replacing the last
sentence with "This would ease implementation for people unfamiliar with the
history and folklore of past and present NNTP implementations."

If they're implementing NNTP, they should have read and re-read the current
spec until they understand what it requires. The problem for many years has
been that doing that has been only a small part of what was needed to
achieve a useful/working/efficient server or client implementation, as so many
important details were known only from comments in discussion on newsgroups,
observing the behaviour and reading the source code of existing
implementations, etc. Removing such uncertainty and ambiguity is an important
goal of the current revision, subject to not rendering existing implementations 
non-conforming gratuitously - which implies the revised spec should not
rule out the de facto "0 0 0" response given by INN for an empty group. 

How about replacing Clive's 

    The last article number MIGHT be less than the first article number. In
    this case, there are no articles in the group and the estimated count
    MUST be zero.

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. 

In the active file, INN sets the high article number in the active file to
the highest number allocated, and the low article number to one greater - if
the group happened to be empty when it updated the low numbers in the active
file (typically daily). If it was to return non-zero values, those would be
the obvious values to return. Are those the values returned by other
implementations which return non-zero low/high numbers?

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). If the meaning of non-zero lo/hi values varies
between implementations, that should be clearly stated so client authors 
don't rely on the behaviour they see with their local server. I.e. replace
"..." above with either

"the last article number should be the highest allocated in the group, and
the first article number should be one greater."

or

"the last article number should be one less than the last article number, 
representing an empty range, but no particular meaning should be attributed 
to the numbers."

Related to this - a quick check with INN confirms that for a newly created
group it sets the low and high article numbers in the active file to 1 and 0
respectively (returning the usual "0 0 0" response for a GROUP command in 
that state). Would servers that return "actual" numbers return 0 for the
high article (one less than low, the usual convention) in that situation,
contradicting Clive's wording that 

    Article numbers MUST lie between 1 and 999999999 inclusive ...

?

This also prompts the thought that the revised description of LIST [ACTIVE]
makes no comment about the nature of the low and high numbers returned
(numeric, but could be zero, negative, non-integer... not precluded 
by the brief comments in section 4.1) and presumably ought to be brought
into line with what's decided for GROUP, to the extent that the same points
are relevant and the same interpretation applies. The possibility of seeing 
a zero in the active file data should at least be mentioned - either noting 
that a newly-created group may have the last article number as zero and
the low article number as 1 (or perhaps alternatively as zero in some 
implementations?).

Finally ... what lo/hi values are returned by servers which return a
non-zero article count for empty groups (if there are any)? Assuming it's
(for all known implementations...) simply a snapshot of the "last known" low
and high values (presumably taken from the active file), it would be helpful
to document that as the acceptable but deprecated alternative behaviour
(noting it may result in clients wasting client and server resources
requesting non-existent articles).

For the same reason, it should presumably be recommended (in the LIST [ACTIVE]
description and also under GROUP) that even if the client has done
a LIST ACTIVE (e.g. so it can highlight subscribed groups with new articles,
and offer the chance to subscribe to new groups) it should use low/high 
article numbers from a GROUP command when it enters a group, rather than 
simply noting that GROUP worked and using the article range from the active
file.

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