ietf-nntp Issue: empty groups

[Jack De Winter]

>Here's the possibilities.
>
>(A) first=last=count=0. This is set by INN; my draft forbids it.
>
>(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.

Um, actually, I said the (b) case.  I said at a minimum, we should
allow (C) (but first>=last+1) and disallow (a)

>(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 ?

My problem with the 'just do what INN does' approach is that
that presupposes that INN is not broken in any way.  There
is also a problem of clients and servers that are implementing
any of the above that we forbid.

Basically, I would like to see a clear indication that a group
is empty.  I thought that the article count could do this, but
people were saying that there were weird cases that would not
allow us to set an empty group to 0 articles.

Thus, fall back to using the first and last article numbers.  This
means that we need some clear way of specifying using either/both
methods.  Setting first = last + 1 (or at a minimum first is some
value greater than last) and the number of articles to 0 is the
most unambiguous way I can think of.  Setting first = last is
really confusing.

regards, IMHO of course,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.