ietf-nntp Issue: empty groups

Jack De Winter jack at wildbear.on.ca
Tue Dec 31 12:55:32 PST 1996


>>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!

We are supposed to be documenting existing implementations and fixing
things that are seriously broken.  Seeing as this behaviour was not
documented in 977, it needs to be documented.

There is nothing that says we cannot say that whatever we decide is
what should be used from the draft forwards, but to please note that
older implementations did the following (and oh, by the way, here
is a list of them, and what they meant in the majority of cases).

If something is broken and we leave it broken, then we have not
accomplished the goals of the charter, and the draft may not get
passed through.

>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

My big problem with this is how do you distinguish a 100% empty (never
had any articles) as opposed to a 'no more messages' group?  I think
that is what is being objected to more than anything else.

Keeping in mind that we want that distinction while preserving a good
concept of the article numbering, the two options that seem to be
left are B & E.  Both have the number of articles set to 0, but E
would also have first = last instead of first = last + 1.

If you can convince me of a good reason to set first = last = count = 0
when a group is empty but has had articles in it before, I am sure I
would listen. ;-)

>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.]

I think this is a good start, assuming that we decide (B) is the best
choice.  If so, I think it is fairly worded, and gives meaning to the
existing cases, and documents common behaviour.

regards,
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.



More information about the ietf-nntp mailing list