Re: ietf-nntp Issue: empty groups

USENET news manager <newsmaster@ucs.cam.ac.uk> Tue, 31 December 1996 22:10 UTC

Received: from cnri by ietf.org id aa25733; 31 Dec 96 17:10 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa19440; 31 Dec 96 17:10 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id QAA07006 for ietf-nntp-outgoing; Tue, 31 Dec 1996 16:06:08 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id QAA07001 for <ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 31 Dec 1996 16:06:06 -0600 (CST)
Received: from lyra.csx.cam.ac.uk (news@lyra.csx.cam.ac.uk [131.111.8.36]) by academ.com (8.8.4/8.7.1) with SMTP id QAA05900 for <ietf-nntp@academ.com>; Tue, 31 Dec 1996 16:06:04 -0600 (CST)
Received: by lyra.csx.cam.ac.uk (SMI-8.6/MDTG-V1.1.8@lyra.csx.cam.ac.uk) id WAA24475; Tue, 31 Dec 1996 22:05:58 GMT
Message-Id: <199612312205.WAA24475@lyra.csx.cam.ac.uk>
Subject: Re: ietf-nntp Issue: empty groups
To: Jack De Winter <jack@wildbear.on.ca>
Date: Tue, 31 Dec 1996 22:05:58 +0000 (GMT)
Cc: ietf-nntp@academ.com
In-Reply-To: <3.0.32.19961231155531.00d4e1dc@lacroix> from "Jack De Winter" at Dec 31, 96 03:55:32 pm
From: USENET news manager <newsmaster@ucs.cam.ac.uk>
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

Jack De Winter wrote:
>[comments on some of my comments about GROUP responses and empty groups;
>snipped here and below solely to avoid ever-growing messages, since I don't
need to comment on much of it!]

[with reference to Clive Feather's summary of possible response types]
>>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.

Until you mentioned this as a concern, I wasn't aware anyone was worried
by that aspect. Why does the distinction matter to a client? (Note that
a client could always use LIST [ACTIVE] if it really wanted to know what
numbers the server was using.)

[It might use the extra information conveyed by a valid, non-zero last article
number but that's not in any way critical - and a client would have to cope
with existing servers that use all zeroes for empty groups of whatever type.]

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

With the first = last value presumably being the highest article number
assigned so far? (Anything else could cause trouble for a client which 
made use of any non-zero last article number that it received with count=0.)

>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. ;-)

Well, a client which looks at the article numbers and ignores the count (if
there are any such; since the count's only an estimate, ignoring it entirely
could have been seen as a valid decision), it would waste time trying to
retrieve the single article which a first=last range with non-zero values 
would imply. Since far more time is likely to be wasted looking for articles
(or information about articles) which have been cancelled, or skipping
gaps where some articles have long expiry and many later ones have expired,
that's not really a problem, though.

I suppose the main factor favouring first=last+1 is that clients which can
use NNTP or access the server's active file direct will see the same thing
either way, rather than having to handle them differently (and such a client
might well ignore the count from the GROUP command, since there's no equivalent
when using the active file!). [Implementors of dual-mode clients may be
reluctant to use the figures from the GROUP response in preference to LIST
[ACTIVE], which came up in discussion recently, for the same reason - more
logical to use the active file data regardless of mode!]

>>[my suggested description of the situation]
>
>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.

Thanks! 

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