Re: ietf-nntp Issue: empty groups

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

Clive D.W. Feather wrote:
>
>I didn't intent to open a can of worms here, honest.

It needed opening, else the worms would be crawling all over the place in
future...

>Suppose that a group contained articles 222 to 234. Thus the response to
>GROUP would be first=222, last=234, count=13. Now suppose that all the
>articles are expired, making the group empty. What can GROUP now legally
>return ? [We all agree, I hope, that the next article to arrive would be
>235, setting the reply to first=last=235, count=1.]
>
>Here's the possibilities.
>
>(A) first=last=count=0. This is set by INN; my draft forbids it.

Also done, we've been told, by the current NNTP reference implementation...

>(B) first=last+1, count=0. My draft allows this. I see no reason why first
>couldn't be 235 (allowing the client to know the articles have expired
>permanently).
>
>(C) first>last+1, count=0. My draft sort of forbids this by omission; Jack
>De Winter would like it to be explicit.
>
>(D) first>last, count>0. My draft forbids this.
>
>(E) first<=last, count=0. My draft allows this.
>
>(F) first<=last, count>0. My draft allows this by implication - is there
>any way we can in fact forbid it ?
>
>
>My inclination is to tune the wording to have:
>    Forbid A, C, D.
>    Allow E and F.
>    SHOULD do B.
>
>Any dissent ?

Yes, on the grounds that what I'd assume to be the bulk of deployed NNTP
servers (i.e. those running the NNTP reference implementation and INN (plus
presumably derivates such as Netscape's news server?) use A, and we're
supposed to be documenting reality and providing better guidance for the
future, not rendering existing widespread usage invalid!

A is a subset of E, which you allow, except for the article numbers being
zero which is not normally allowed. However, both your option B and LIST 
[ACTIVE] will expose the first=1, last=0 combination, so zero already needs

In the absence (as yet) of any explanation from e.g. the implementors who've
chosen A as to why it was preferable (maybe safer in some situations?) to B,
I would view B as the more informative response. I would therefore say we
should allow A, B, E, F and recommend B as the preferred behaviour. With B,
E, F the first/last values used should be "real" ones, of course, not
arbitrary dummy values.

This could be documented something like:

=====
An empty group (one which currently contains no articles) SHOULD result in
an estimated article count of zero with the last article number set to the
last article number assigned in the group, and the first article number set
to one greater than the last article (i.e. the next article number which
will be assigned). Note that for a newly created group, this may return zero
as the last article number, even though zero is not a valid number for an
existing article.

A number of other valid, but deprecated, styles of response currently exist 
and MUST be accepted by clients:

 * It is very common for all three values to be zero, in which case the
   first and last article numbers are simply placeholders and should be 
   ignored.

 * First and last article numbers may be set as normal (first less than or
   equal to last, last article number being the highest assigned in the group).
   The estimated article count may be be zero, or a valid non-zero estimate of
   the number of articles in the group. The latter case is simply a normal
   response which provides no hint that the group is empty (just as if all 
   articles had been cancelled or expired after the GROUP response).

A client SHOULD rely primarily on a zero estimated article count to identify
an empty group. If the article count is zero but the last article number is
not zero, then the last article number is the highest so far assigned in the
group and may, for example, be used it to mark all articles up to that
number as read.
=====

[One point we need to remember, and sometimes appear to overlook in 
discussion, is that client implementors may need guidance on how to handle
server responses, as well as server implementors needing guidance on what
responses they should send.]

Note that testing first > last is not mentioned, since it will detect only
one of the cases, whereas count=0 will detect all except for the "server 
didn't notice group was empty" case, which does not need special handling 
anyway (though inefficient).

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