Subject: [NNTP] LISTGROUP wording

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 17:46:58 +0100

I've edited my master copy to add ranges to LISTGROUP and make the group
argument to GROUP optional. Here's a set of diffs (I've included the
entiretly of 6.1.1 and 6.1.2, then there are two consequental changes
(syntax and summary of response codes).

@@@@@@@@@@@@@@@@@@@@
 6.1.1  GROUP

 6.1.1.1  Usage

    Indicating capability: READER

    Syntax
-      GROUP group
+      GROUP [group]

    Responses
       211 number low high group   Group successfully selected
       411                      No such newsgroup
+      412                      No newsgroup selected [1]

    Parameters
       group  = name of newsgroup
       number = estimated number of articles in the group
       low    = reported low water mark
       high   = reported high water mark

+   [1] The 412 response can only occur if no group has been specified.
+

 6.1.1.2  Description

-   The required argument is the name of the newsgroup to be selected
-   (e.g. "news.software.b").  A list of valid newsgroups may be obtained
-   by using the LIST ACTIVE command (see Section 7.6.3).
+   The GROUP command selects a newsgroup as the current selected
+   newsgroup and returns summary information about it.
+
+   The optional argument is the name of the newsgroup to be selected
+   (e.g. "news.software.b").  If no group is specified, the current
+   selected newsgroup is used.  A list of valid newsgroups may be
+   obtained by using the LIST ACTIVE command (see Section 7.6.3).

    The successful selection response will return the article numbers of
    the first and last articles in the group at the moment of selection
    (these numbers are referred to as the "reported low water mark" and
    the "reported high water mark"), and an estimate of the number of
    articles in the group currently available.

    If the group is not empty, the estimate MUST be at least the actual
    number of articles available, and MUST be no greater than one more
    than the difference between the reported low and high water marks.
    (Some implementations will actually count the number of articles
    currently stored.  Others will just subtract the low water mark from
    the high water mark and add one to get an estimate.)

    If the group is empty, one of the following three situations will
    occur.  Clients MUST accept all three cases; servers MUST NOT
    represent an empty group in any other way.

    o  The high water mark will be one less than the low water mark, and
       the estimated article count will be zero.  Servers SHOULD use this
       method to show an empty group.  This is the only time that the
       high water mark can be less than the low water mark.

    o  All three numbers will be zero.

    o  The high water mark is greater than or equal to the low water
       mark.  The estimated article count might be zero or non-zero; if
       non-zero, the same requirements apply as for a non-empty group.

    The set of articles in a group may change after the GROUP command is
    carried out.  That is:

    o  articles may be removed from the group

    o  articles may be reinstated in the group with the same article
       number, but those articles MUST have numbers no less than the
       reported low water mark (note that this is a reinstatement of the
       previous article, not a new article reusing the number)

    o  new articles may be added with article numbers greater than the
       reported high water mark (if an article that was the one with the
       highest number has been removed and the high water mark adjusted
       accordingly, the next new article will not have the number one
       greater than the reported high water mark)

    Except when the group is empty and all three numbers are zero,
    whenever a subsequent GROUP command for the same newsgroup is issued,
    either by the same client or a different client, the reported low
    water mark in the response MUST be no less than that in any previous
    response for that newsgroup in any session, and SHOULD be no less
    than that in any previous response for that newsgroup ever sent to
    any client.  Any failure to meet the latter condition SHOULD be
    transient only.  The client may make use of the low water mark to
    remove all remembered information about articles with lower numbers,
    as these will never recur.  This includes the situation when the high
    water mark is one less than the low water mark.  No similar
    assumption can be made about the high water mark, as this can
    decrease if an article is removed, and then increase again if it is
    reinstated or if new articles arrive.

    When a valid group is selected by means of this command, the current
    selected newsgroup MUST be set to that group and the current article
-   number MUST be set to the first article in the group.  If an empty
-   newsgroup is selected, the current article pointer is made invalid.
-   If an invalid group is specified, the current selected newsgroup and
-   current article number MUST NOT be changed.
+   number MUST be set to the first article in the group (this applies
+   even if the group is already the current selected newsgroup).  If an
+   empty newsgroup is selected, the current article pointer is made
+   invalid.  If an invalid group is specified, the current selected
+   newsgroup and current article number MUST NOT be changed.

    The GROUP or LISTGROUP command (see Section 6.1.2) MUST be used by a
    client and a successful response received before any other command is
    used that depends on the value of the current selected newsgroup or
    current article number.

    If the group specified is not available on the server, a 411 response
-   MUST be returned.
+   MUST be returned.  If no group is specified and the current selected
+   newsgroup is invalid, a 412 response MUST be returned.

+   Note that the ability to omit the group name is a new feature in this
+   specification and servers that do not support CAPABILITIES (and
+   therefore do not conform to this specification) are unlikely to
+   support it.

 6.1.1.3  Examples

    Example for a group known to the server:
 
       [C] GROUP   misc.test
       [S] 211 1234 3000234 3002322 misc.test

       [C] GROUP   misc.test
       [S] 211 1234 3000234 3002322 misc.test

    Example for a group unknown to the server:

       [C] GROUP   example.is.sob.bradner.or.barber
       [S] 411 example.is.sob.bradner.or.barber is unknown

    Example of an empty group using the preferred response:

       [C] GROUP   example.currently.empty.newsgroup
       [S] 211 0 4000 3999 example.currently.empty.newsgroup

    Example of an empty group using an alternative response:

       [C] GROUP   example.currently.empty.newsgroup
       [S] 211 0 0 0 example.currently.empty.newsgroup

    Example of an empty group using a different alternative response:

       [C] GROUP   example.currently.empty.newsgroup
       [S] 211 0 4000 4321 example.currently.empty.newsgroup
+
+   Example reselecting the current selected newsgroup:
+
+      [C] GROUP   misc.test
+      [S] 211 1234 234 567 misc.test
+      [C] STAT   444
+      [S] 223 444 <[email-masked]> retrieved
+      [C] GROUP
+      [S] 211 1234 234 567 misc.test
+      [C] STAT
+      [S] 223 234 <[email-masked]> retrieved
+
+   Example of GROUP failing because no group has been selected:
+
+      [Assumes current selected newsgroup is invalid.]
+      [C] GROUP
+      [S] 412 no current group
+      [C] GROUP   example.is.sob.bradner.or.barber
+      [S] 411 no such group
+      [C] GROUP
+      [S] 412 no current group

 6.1.2  LISTGROUP

 6.1.2.1  Usage

    Indicating capability: READER with argument LISTGROUP

    Syntax
-      LISTGROUP [group]
+      LISTGROUP [group [range]]

    Responses
       211 number low high group   Article numbers follow (multi-line)
       411                      No such newsgroup
       412                      No newsgroup selected [1]

    Parameters
       group  = name of newsgroup
+      range  = range of articles to report
       number = estimated number of articles in the group
       low    = reported low water mark
       high   = reported high water mark

    [1] The 412 response can only occur if no group has been specified.

 6.1.2.2  Description

+   The LISTGROUP command selects a newsgroup in the same manner as the
+   the GROUP command (see Section 6.1.1) but also provides a list of
+   article numbers in the newsgroup.  Except for the range argument and
+   that the 211 response code is multi-line, its behaviour is identical
+   to the GROUP command.
+
+   On success, a list of article numbers is returned as a multi-line
+   data block following the 211 response code (the arguments on the
+   initial response line are the same as for the GROUP command).  The
+   list contains one number per line and is in numerical order.  It
+   lists precisely those articles that exist in the group at the moment
+   of selection (therefore an empty group produces an empty list); if
+   the optional range argument is specified, only those articles that
+   are within the range are included in the list (therefore the list MAY
+   be empty even if the group is not).
+
+   The range argument may be any of the following:
+
+   o  an article number
+
+   o  an article number followed by a dash to indicate all following
+
+   o  an article number followed by a dash followed by another article
+      number
+
+   In the last case, if the second number is less than the first number
+   then the range contains no articles.  Omitting the range is
+   equivalent to the range 1- being specified.
+
-   The LISTGROUP command is used to get a listing of all the article
-   numbers in a particular newsgroup.  As a side effect, it also selects
-   the group in the same way as the GROUP command (see Section 6.1.1).
-
-   The optional argument is the name of the newsgroup to be selected
-   (e.g. "news.software.misc").  If no group is specified, the current
-   selected newsgroup is used.
-
-   On success, the list of article numbers is returned as a multi-line
-   data block following the 211 response code (the arguments on the
-   initial response line are the same as for the GROUP command).  The
-   list contains one number per line, is in numerical order, and lists
-   precisely those articles that exist in the group at the moment of
-   selection (therefore an empty group produces an empty list).
-
-   If the group specified is not available on the server, a 411 response
-   MUST be returned.  If no group is specified and the current selected
-   newsgroup is invalid, a 412 response MUST be returned.
-
    In all other aspects the LISTGROUP command behaves identically to the
-   GROUP command.
+   GROUP command.  In particular, when successful, the command sets the
+   current article number to the first article in the group, if any,
+   even if this is not within the range specified by the second
+   argument.
+
+   Note that the range argument (but not, unlike GROUP, the ability to
+   omit the group name) is a new feature in this specification and
+   servers that do not support CAPABILITIES (and therefore do not
+   conform to this specification) are unlikely to support it.

 6.1.2.3  Examples

+   Example of LISTGROUP being used to select a group:
+
+      [C] LISTGROUP   misc.test
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] 3000234
+      [S] 3000237
+      [S] 3000238
+      [S] 3000239
+      [S] 3002322
+      [S] .
+
    Example of LISTGROUP on an empty group:

       [C] LISTGROUP   example.empty.newsgroup
       [S] 211 0 0 0 example.empty.newsgroup list follows
       [S] .

    Example of LISTGROUP on a valid current selected newsgroup:

       [C] GROUP   misc.test
       [S] 211 2000 3000234 3002322 misc.test
       [C] LISTGROUP
       [S] 211 2000 3000234 3002322 misc.test list follows
       [S] 3000234
       [S] 3000237
       [S] 3000238
       [S] 3000239
       [S] 3002322
       [S] .

+   Example of LISTGROUP with a range:
+
+      [C] LISTGROUP   misc.test 3000238-3000248
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] 3000238
+      [S] 3000239
+      [S] .
+
+   Example of LISTGROUP with an empty range:
+
+      [C] LISTGROUP   misc.test 12345678-
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] .
+
+   Example of LISTGROUP with an invalid range:
+
+      [C] LISTGROUP   misc.test 9999-111
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] .
+
-   Example of LISTGROUP failing because no group has been selected:
-
-      [Assumes current selected newsgroup is invalid.]
-      [C] LISTGROUP
-      [S] 412 no current group
-      [C] GROUP   example.is.sob.bradner.or.barber
-      [S] 411 no such group
-      [C] LISTGROUP
-      [S] 412 no current group
@@@@@@@@@@@@@@@@@@@@
      body-command = "BODY" [WS article-ref]
      capabilities-command = "CAPABILITIES" [WS keyword]
      date-command = "DATE"
-     group-command = "GROUP" WS newsgroup-name
+     group-command = "GROUP" [WS newsgroup-name]
      hdr-command = "HDR" WS header-meta-name [WS range-ref]
      head-command = "HEAD" [WS article-ref]
      help-command = "HELP"
      ihave-command = "IHAVE" WS message-id
      last-command = "LAST"
      list-command = "LIST" [WS list-arguments]
-     listgroup-command = "LISTGROUP" [WS newsgroup-name]
+     listgroup-command = "LISTGROUP" [WS newsgroup-name [WS range]]
      mode-reader-command = "MODE" WS "READER"
      newgroups-command = "NEWGROUPS" WS date-time
      newnews-command = "NEWNEWS" WS wildmat WS date-time
@@@@@@@@@@@@@@@@@@@@
 
    Response code 412
-      Generated by: ARTICLE, BODY, HDR, HEAD, LAST, LISTGROUP, NEXT,
-      OVER, STAT
+      Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP,
+      NEXT, OVER, STAT
       Meaning: no newsgroup selected.
 
@@@@@@@@@@@@@@@@@@@@

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Apr 2005 13:03:06 -0400

>     Indicating capability: READER with argument LISTGROUP

Have we decided if LISTGROUP is going to be mandatory to implement if 
READER is advertised?  If so, then the indicating capability is simply 
"READER".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Mon, 25 Apr 2005 10:22:07 -0700

> READER is advertised?  If so, then the indicating capability is simply

I have, so far, not heard any objections to making it mandatory in the
latest round of discussion.  If anyone feels that's the wrong choice,
please speak up.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 26 Apr 2005 08:15:16 +0100

> latest round of discussion.  If anyone feels that's the wrong choice,

I'm happy: if I see nothing before the next time I edit my sources, I'll
make the change.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 26 Apr 2005 10:38:19 GMT

>+   The GROUP command selects a newsgroup as the current selected
                                                  ^^^^^^^
						  currently
>+   obtained by using the LIST ACTIVE command (see Section 7.6.3).

Actually, "news.software.b" must be the deadest group on Usenet. I have
been subscribed to it for many years, and have yet to see an article. May
I suggest "news.software.nntp".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 09:15:14 +0100

Russ Allbery said:
> latest round of discussion.

Do Andrew's comments count as an objection? If so, what happens next?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 09:22:41 +0100

> >+   The GROUP command selects a newsgroup as the current selected

I had memories of this being discussed in the past and the present phrase
having been picked for some reason, but a trawl through the archives
doesn't show anything. So I've changed all occurrences.

> been subscribed to it for many years, and have yet to see an article.

Sic transit gloria mundi.

> May

Changed.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Apr 2005 09:39:37 -0400

> Do Andrew's comments count as an objection? If so, what happens next?

Obviously, I'm not going to speak for Andrew, but I took his comments as 
a possible objection to the LISTGROUP initial response line changing 
format, not an objection to making LISTGROUP mandatory.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 14:45:53 +0100

Ken Murchison said:
>>>>READER is advertised?

> format, not an objection to making LISTGROUP mandatory.

He pointed out that he wasn't storing the group name anywhere. I assumed
that made LISTGROUP (no arguments) hard to implement.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Apr 2005 10:18:30 -0400

> that made LISTGROUP (no arguments) hard to implement.

True.  Can we just make the group name required for both GROUP and 
LISTGROUP?  As we stated before, its hard to believe that the client 
doesn't know what group is currently selected, so using [LIST]GROUP with 
no argument seems like unnecessary functionality.  Furthermore, since 
LISTGROUP selects the group in the same way as GROUP, it doesn't make 
any sense to me that a client would waste a roundtrip and/or bandwidth 
by sending "GROUP <group>" followed by "LISTGROUP" (whether pipelined or 
not).

I supposed we'd have to solicit client authors to see if anybody 
actually uses LISTGROUP with no argument in practice.

---

From: Ade Lovett <[email-masked]>
Date: Wed, 27 Apr 2005 21:41:16 -0700

> that made LISTGROUP (no arguments) hard to implement.

Since the client is already painfully aware of which group it's in, why
does the server need to have to remind it?

I really don't see the need for GROUP being allowed to have no arguments
either.  In fact, about the only possible reason I could see it being
(ab?)used for is a client polling to see if high watermarks have
changed, indicating new article arrivals.

On the larger news farms, this is unlikely to have the desired affect,
since groups do not tend to be re-scanned at the whim of a client
(trivial to destroy server performance that way), rather this data will
be updated on a regular basis by a helper and clients will read from
this generated cache.

I'd therefore push for both LISTGROUP and GROUP to have a mandatory
group name argument -- though this is orthogonal to the issue of whether
LISTGROUP should become mandatory -- I humbly suggest that that
particular question should be aimed more a client-side authors than
server-side; actual implementation, as it stands now (and as it would
stand with a required argument) is straightforward enough.

-aDe

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 28 Apr 2005 06:58:01 +0100

> does the server need to have to remind it?

Because it isn't always "painfully aware".

It's a programming philosophy thing that I've run into in several places
in the past. While it seems "obvious" that the client should be aware,
it sometimes turns out to be harder than it looks, requiring the
maintenance of global state across several modules.

It's hard to come up with short, snappy, examples because it's the sort of
problem that only emerges in large complicated systems.

The other piece of state associated with a connection - the current article
number - can be determined by just going "STAT".

> changed, indicating new article arrivals.

Those are orthogonal: allowing GROUP or LISTGROUP without the group name is
*only* beneficial to obtain the group name. You can do that polling with
GROUP already.

> LISTGROUP should become mandatory --

Hmm.

> I humbly suggest that that
> server-side;

I agree with this last bit: we need to hear from the potential
beneficiaries.

---

From: Ade Lovett <[email-masked]>
Date: Thu, 28 Apr 2005 00:00:56 -0700

> maintenance of global state across several modules.

In such a case, where a client starts losing touch with itself, normal
programming practice would then be to fall back to first principles, and
explicitly send the necessary sequence of commands in order to get that
module back into a known state.

In addition, such maintenance of global state across several modules can
 equally, if not moreso, be ascribed to the server side given that there
are considerably less servers than clients, and thus servers have to
handle more state.

This probably isn't the time to be discussing implementation aspects
though :)

> number - can be determined by just going "STAT".

That's completely different.  We already have a multitude of commands
where the current article number is REQUIRED for correct server-side
operation, so that is maintained.  What's being proposed here would
require the server to additionally maintain a *human-readable* version
of a variable-length piece of data, for no apparent gain.

After all, being a paranoid programmer, if I were to issue a GROUP
command (with or without an argument), I'd want to check the group name
returned by the server against what I had, just to make sure the server
hadn't somehow lost its touch on reality.

Of the (admittedly few) Windows (XP) and Mac (OSX) newsreaders I took a
quick peek at, Forte's Agent was the one that really stood out as being
a consumer of LISTGROUP - it seems to use it to cover against
backfilling (heh..)

If change is somehow mandated for LISTGROUP, my personal preference
would be for it to be tagged as deprecated.  As a potential client
author, LISTGROUP doesn't really buy me anything over, say:

	GROUP foo
	XHDR Message-ID 0-99999999999

which, with the range argument, gives me considerably more flexibility,
particularly in high-traffic newsgroups, as well as more useful
information than output that could quite simply be (and almost certainly
is, in some cases):

	for (n=lo; n<=hi; n++)
	{
		printf("%ld\n", n);
	}

Before anyone gets too excited with deprecation though, having thought
about it some more, my preference would be to leave GROUP and LISTGROUP
as they are now.

-aDe

---

From: "Andrew - Supernews" <[email-masked]>
Date: Thu, 28 Apr 2005 12:14:36 +0100

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

 Clive> Because it isn't always "painfully aware".

 Clive> It's a programming philosophy thing that I've run into in
 Clive> several places in the past. While it seems "obvious" that the
 Clive> client should be aware, it sometimes turns out to be harder
 Clive> than it looks, requiring the maintenance of global state
 Clive> across several modules.

Well, the existing protocol (the one that all the existing clients are
happily using) has no way to tell the client what group it's in, and
the clients seem to cope with that. The protocol also has no way to
return any of the other items of session state either, such as the
username or current article pointer (see below). Clients seem to have
no problem with this; the stuff they commonly get wrong is far more
basic and fundamental, like trying to issue commands from multiple
non-cooperating threads.

 Clive> The other piece of state associated with a connection - the
 Clive> current article number - can be determined by just going
 Clive> "STAT".

STAT with no parameter will fail if the previously-current article was
removed in the mean time.

Note also that use of the current article pointer by clients is
extremely rare.

 Clive> Those are orthogonal: allowing GROUP or LISTGROUP without the
 Clive> group name is *only* beneficial to obtain the group name. You
 Clive> can do that polling with GROUP already.

Allowing LISTGROUP without the group name is beneficial _because a
bunch of existing clients use it that way_, not because they want to
know the group name but because they want the LISTGROUP output. It's
common enough that we had to introduce a special cache for it to avoid
having to do an overview index scan to find the available articles (a
significant hit in large groups).

Just to make absolutely clear - my earlier comment was only about the
response to LISTGROUP, I didn't intend to suggest that LISTGROUP's
argument should be made mandatory.

So to sum up:

1) LISTGROUP with no arguments should be allowed on the basis of
substantial existing usage.

2) Requiring that the 211 response to LISTGROUP-with-no-arguments be
in the same format as for GROUP is a change to existing practice.
Clients currently do not (can not) assume anything about that
response.  (I have no problem going along with the change if it's
considered necessary, but it needs to be clearly understood that it
_is_ a change.)

3) allowing GROUP-with-no-arguments is just feature creep; adding it
at this late stage is pointless since it gains nothing. (Adding a
range parameter to LISTGROUP is something of real value to clients,
though, which is the only reason to even consider it.)

-- 
Andrew, Supernews
http://www.supernews.com

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Apr 2005 09:32:37 GMT

>that made LISTGROUP (no arguments) hard to implement.

I find it hard to see how he manages to implement commands such as ARTICLE
and NEXT if he does not keep some state variable pointing to something
representing the current group. If so, it hardly seems rocket science to
attach the group name to that "something".

---

From: "Andrew - Supernews" <[email-masked]>
Date: Thu, 28 Apr 2005 12:38:19 +0100

>>>>> "Charles" == Charles Lindsey <[email-masked]> writes:

 >> He pointed out that he wasn't storing the group name anywhere. I
 >> assumed that made LISTGROUP (no arguments) hard to implement.

No. It makes it hard to return the group name as part of the response.

 Charles> I find it hard to see how he manages to implement commands
 Charles> such as ARTICLE and NEXT if he does not keep some state
 Charles> variable pointing to something representing the current
 Charles> group.

Yup, but internally it suffices (or has sufficed) to keep an internal
identifier for the currently-open group.

 Charles> If so, it hardly seems rocket science to attach the group
 Charles> name to that "something".

Sure, it's a SMOP, but it's one that I wasn't expecting since there is
no other place where the group name is needed.

-- 
Andrew, Supernews
http://www.supernews.com

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 29 Apr 2005 06:39:25 +0100

> removed in the mean time.

Good point.

> common enough that we had to introduce a special cache for it

That's a useful data point, thanks.

> substantial existing usage.

Okay, there seems to be no dissent to this.

> in the same format as for GROUP is a change to existing practice.

True.

> considered necessary, but it needs to be clearly understood that it

A change which has been in the text for a while.

> at this late stage is pointless since it gains nothing.

In your opinion. I agree that it gains little, but it also requires very
little effort to implement.

I'm going to make this my final word on these issues.

Russ: I'll leave you to determine the consensus on GROUP and LISTGROUP.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2005 11:57:23 GMT

>a consumer of LISTGROUP - it seems to use it to cover against

I would have thought a major use of LISTGROUP would be a s a quick way to
synchonize the client's and server's views of what articles remained in
the group.

<rant>
Opera is particularly bad in this respect. If you have finished with an
article, then you have to both mark it as read, and then 'delete' it.
Otherwise it continues to be presented as 'available' even though you will
be told it is no longer there if you try to read it.

Yes, they admit it is a shambles, but have not got enough Round Tuits to
fix it. It is an excellent mail reader (I use it), but they have just no
concept of the essential differences between mail and news. I doubt they
are even aware of the overview :-( .

</rant>