Subject: [NNTP] LISTGROUP

From: Russ Allbery <[email-masked]>
Date: Sat, 16 Apr 2005 17:41:26 -0700

As promised, here's my proposed text for LISTGROUP that makes the command
a mandatory part of READER and adds a range argument.

This is presented for discussion to see if we can reach consensus that
this is a good idea.  I'm also copying this to news.software.nntp to get
more implementor eyes on it.  If this proposal goes into the draft, it
would mean that in order to claim NNTPv2 compliance, implementing
LISTGROUP with a range argument would be mandatory.

Please note that I think there's at least an even chance that the result
of this discussion will be to reject this idea as too late in the process
or too different from existing practice, but the idea achieved enough
support that I wanted to put together a whole proposal.

6.1.2  LISTGROUP

6.1.2.1  Usage

   Indicating capability: READER
   Syntax
      LISTGROUP [group [range]]
   Responses
      211 number low high group   Article numbers follow (multiline)
      411                         No such newsgroup
      412                         No newsgroup selected [1]
   Parameters
      group  = name of newsgroup
      range  = number(s) of articles
      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 is used to get a listing of some or 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 first 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.

   The second optional argument, range, 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
   If no range is specified, the range 1- is assumed.  If the name of the
   newsgroup is not specified, the range may not be specified.

   On success, the list of article numbers is returned as a multi-line
   response 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 whose numbers are within the given range.  This list may be
   empty if no articles in the group have numbers within the given range.

   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.

6.1.2.3  Examples

   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 3000239-
      [S] 211 2000 3000234 3002322 misc.test list follows
      [S] 3000239
      [S] 3002322
      [S] .

   Example of LISTGROUP with an empty list:
      [C] LISTGROUP misc.test 3002400-3002420
      [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

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Apr 2005 13:00:43 -0400

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

Shouldn't we add a 423 respone for the case where "No articles in that 
range"?

-- 
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, 18 Apr 2005 10:38:10 -0700

> Shouldn't we add a 423 respone for the case where "No articles in that

No, that's intentionally omitted in favor of just returning an empty list,
so as not to get into complexities around whether one's default group
changed when the command failed.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Apr 2005 16:03:56 -0700 (Pacific Daylight Time)

My comments:

I think that I've expressed my dismay at NNTP's abuse of 4xx codes before, 
and 411 and 412 are no exception.  412 in particular offends me; if this 
isn't properly a 5xx code I have a hard time thinking of what would be.

Can we get rid of that "estimated" from "estimated number of articles in 
the group"?  As far as I am concerned, an estimated value is worse than 
useless, and an NNTPv2 compliant server should be required to give an 
exact value.

What is a "reported" high and low water mark as opposed to a high and low 
water mark?

In a range, how is 5-1 interpreted?  Is it equivalent to 1-5?

Note that if 5-1 is equivalent to 1-5, then 5- is equivalent to 4-5 if 4 
is the highest article number (and you need to change that "all following" 
text).

If it is it an error, then there needs to be an error code.

Should lists of article numbers/ranges be allowed, e.g. 1-5,14-34,56- ?

Your first two examples have two extraneous spaces after the command.  Are 
these significant for some reason?

Your first example is really of a "never posted to group" instead of an 
"empty group".  You probably should have a separate empty group example.

Your second, third, and fourth examples show estimates for the number of 
articles, and back up my point about the overall uselessness of the 
estimates.  Please let's have exact values.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 18 Apr 2005 17:05:35 -0700

Mark Crispin <[email-masked]> writes:

> I think that I've expressed my dismay at NNTP's abuse of 4xx codes
> before, and 411 and 412 are no exception.  412 in particular offends me;
> if this isn't properly a 5xx code I have a hard time thinking of what
> would be.

So... I've tried to explain a few times that NNTP does not use the 400 and
500 conventions of other protocols like SMTP.  NNTP can't be abusing
something that it never followed and never even tried to follow in the
first place.  Are you not agreeing with my point, not understanding it,
not remembering it...?  I feel like I've tried to respond to this point on
multiple occasions now, with apparently no change in your perception that
NNTP thinks of 4xx as "temporary" and gets it wrong.  4xx has never meant
temporary, or 5xx permanent, in the history of the NNTP protocol.

If we were redoing the protocol from scratch, we'd use the same return
code conventions as everyone else, but since we're not and since changing
all the return codes obviously can't happen, I guess I don't see a lot of
utility in discussing it.

Anyway, LISTGROUP uses 411 and 412 in the way that every other command in
NNTP with those error conditions does.

> useless, and an NNTPv2 compliant server should be required to give an

An exact value at the time that the command is issued that may have
changed a second later doesn't strike me as much more useful than an
estimated value.  Anyway, no, we can't change this and stay within the
charter of the working group (even putting aside the question of whether
it's a feasible change to expect software to do).

> What is a "reported" high and low water mark as opposed to a high and
> low water mark?

Same thing.  I'm not sure why the word "reported" is there, but it's used
fairly consistently through the rest of the draft as well.

> is the highest article number (and you need to change that "all
> following" text).

> If it is it an error, then there needs to be an error code.

That's a very good question, and one that we also need to answer for OVER,
which has the same issue.  INN historically (all the way back to 1.0!) has
treated 5-1 as 5-, or in general n-m where m < n as equivalent to n-.  I
don't know if that's something we want to bless.  There is no error,
though.

> Should lists of article numbers/ranges be allowed, e.g. 1-5,14-34,56- ?

No, they're not allowed anywhere else that ranges are allowed.

> Your first two examples have two extraneous spaces after the command.
> Are these significant for some reason?

I think they were intended to be examples that whitespace doesn't matter
(they're in the existing LISTGROUP writeup).

> "empty group".  You probably should have a separate empty group example.

It could be either; see 6.1.1 where this is discussed.  One of those
places where we're documenting existing practice, and while we have some
leeway to revisit some of this given the NNTPv2 capability, this is really
not one that I want to reopen; we need to finalize and publish something
soon.

> estimates.  Please let's have exact values.

At least one of those should probably be changed to show an exact value; I
wasn't thinking about that when I copied and pasted the examples.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 18 Apr 2005 17:14:15 -0700

> it's a feasible change to expect software to do).

To which I should probably also add that adding the range parameter to
LISTGROUP is *also* stepping outside the charter of the group.  It's in a
way that I think is minor, and it seems so obviously useful and trivial to
implement that I'm giving it a shot, but taking off my proposer hat and
putting on my chair hat, that means that if consensus doesn't gell around
it right quick, I'm going to declare it out of scope and move on.

Basically, that means unless everyone loves the idea by the time we
finalize the i18n language, it's out.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Apr 2005 17:36:38 -0700 (Pacific Daylight Time)

On Mon, 18 Apr 2005, Russ Allbery wrote:
> not remembering it...?

I understood you the first time.  I disagree with the perpetuation of an 
arbitrary divergence from standard Internet protocol architecture which 
was clearly created by mistake rather than conscious decision.

The issue isn't that NNTP has its own schema of response code; the issue 
is that NNTP has its own schema that overlaps a well-established scheme.

> utility in discussing it.

NNTPv2 offers a means to correct this mistake.  Given that a CAPABILITY 
(or whatever you're calling it) command will be the first thing that an 
NNTPv2 client will issue, this also informs the server that the client is 
NNTPv2 compatible.  So if you have any worries about pre-NNTPv2 clients, 
you have a means to deal with it.

Eventually, we will have NNTPv2-only clients and servers which will 
disconnect if the other end isn't NNTPv2-compatible, and the old ways will 
be evil memories.

There is precedent for this in IMAP.

> estimated value.

"Changed a second later"?  Are you allowing announcement of new articles?

> Anyway, no, we can't change this and stay within the

Quality server software can do the right thing.  Protocols should not 
accomodate poorly-written server software.

And there is no charter reason why NNTPv2 can't require a quality 
implementation.

> fairly consistently through the rest of the draft as well.

If you can't justify it, it should be removed.

"Reported" means something totally meaningless that can be any arbitrary 
value or even a constant across all newsgroups.  According to the 
specification the way you have it written, a compliant server can respond 
with "211 4294967296 4294967296 0 <ngname>" for all newsgroups.

And yes, I mean an article count of "infinity", a "low water mark" of 
infinitity and a "high water mark" of zero.  After all, these are just 
"estimates" and "reported" values, so they can be anything.  Absurd?  Yes. 
Valid according to the specification?  Also yes.

But, but, doesn't 6.1.1.2 ban that?  No, because that's the GROUP command 
response.  This is a different command response.  If you want it to have 
the same semantics as GROUP then you must *say* that.

> don't know if that's something we want to bless.  There is no error,

Decide upon something, and specify it.  I don't care what is decided, as 
long as there's a decision and a specification of the decision.

> (they're in the existing LISTGROUP writeup).

In that case, the examples need to have a comment to that effect.

> It could be either; see 6.1.1 where this is discussed.

Nope.  That's the GROUP command, not the LISTGROUP command.  If you want 
the rules of 6.1.1.2 to apply, you have to have an explicit reference to 
those rules in the LISTGROUP description.

Otherwise, it is valid to claim that LISTGROUP works differently than 
GROUP.

> One of those

Given how incredibly late this specification is already, I don't think 
that "lack of time" is justification to avoid fixing a real problem. 
There is no reason why the three zeros response should be allowed in an 
NNTPv2 compliant server.

-- Mark --

---

From: Russ Allbery <[email-masked]>
Date: Mon, 18 Apr 2005 17:56:30 -0700

> was clearly created by mistake rather than conscious decision.

Okay.  It's good to know that at least we've both understood each other,
even if we don't agree.  :)

> NNTPv2 client will issue, this also informs the server that the client
> is NNTPv2 compatible.  So if you have any worries about pre-NNTPv2
> clients, you have a means to deal with it.

I'm not willing to support changing the NNTP return codes for this draft.

> "Changed a second later"?  Are you allowing announcement of new

No, I'm allowing articles to be withdrawn, which is the entire reason why
this is an estimate and not an exact number.  When articles are cancelled,
the number of available articles in the group decreases immediately; at
any point after the cancel, if a client attempts to read the message, it
will be told the message number is not valid.  This is true even if the
message number was previously returned by LISTGROUP, etc.

In practice, the estimate never errs on the low side, but does err on the
high side occasionally because it may or may not take into account all
cancels that have occurred in the group.  I don't see a lot of use in
requiring a guarantee that the number be accurate at the time of the GROUP
command when it may become inaccurate due to the arrival of a cancel
message an instant later.

> But, but, doesn't 6.1.1.2 ban that?  No, because that's the GROUP
> command response.  This is a different command response.  If you want it
> to have the same semantics as GROUP then you must *say* that.

So your feeling is that the statement:

is not adequate?  How does that fall short?  I'm happy to change the
wording to be more explicit; it is definitely my intention to defer to the
GROUP specification for all of these issues.

>> That's a very good question, and one that we also need to answer for
>> OVER, which has the same issue.  INN historically (all the way back to
>> 1.0!) has treated 5-1 as 5-, or in general n-m where m < n as
>> equivalent to n-.  I don't know if that's something we want to bless.
>> There is no error, though.

> long as there's a decision and a specification of the decision.

Okay.  We've been using the standard language:

   The range argument may be any of the following:

   o  an article number

to describe ranges.  I propose adding the following sentence after this
wording everywhere it occurs in our draft:

   Any range specified as n-m where m is less than n is defined to be
   equivalent to the range n-.

>> I think they were intended to be examples that whitespace doesn't
>> matter (they're in the existing LISTGROUP writeup).

> In that case, the examples need to have a comment to that effect.

Sure, that's fine with me.

> that "lack of time" is justification to avoid fixing a real
> problem. There is no reason why the three zeros response should be
> allowed in an NNTPv2 compliant server.

There's certainly merit to what you're saying (one particular method of
representing an empty group is already singled out with a SHOULD), but I'd
like to see slam-dunk working group consensus both around reopening this
and around promoting the SHOULD to a MUST now that we have NNTPv2.  I
don't want to get bogged down in discussing it.

We may very well have that.  If people have an opinion, please speak up.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Apr 2005 18:07:54 -0700 (Pacific Daylight Time)

On Mon, 18 Apr 2005, Russ Allbery wrote:
> this is an estimate and not an exact number.

That isn't what I've seen.  I've seen "estimates" that bear no 
relationship to the number of articles at any time.

> cancels that have occurred in the group.

I'm not sure, but I think that I have seen low-side estimates.  After some 
number of iterations, I ended up completely ignoring that value as being 
worse than useless.

> GROUP specification for all of these issues.

Something like "The LISTGROUP command responds with the same 211 response 
as a GROUP command (see section 6.1.1.2), and in addition returns..."

The fact that you describe this response separately for LISTGROUP implies 
that the semantics of the response are different.  You may feel that is 
silly (and it is), but 5 years from now some twit will argue that unless 
explicitly prohibited.

We're talking sad experience here.  I have wasted many hours of my life 
arguing such things with twits, and not even archives from the WG mailing 
list were enough to dissuade the twit from insisting that the RFC "really 
means" what he says it means.

>   equivalent to the range n-.

That's OK with me.

Alternatively, you could do:
    o  an article number followed by a dash followed by another, higher,
       article number

By the way, be careful about using the term "range".  I once wasted a long 
time arguing with a twit who insisted that IMAP ranges had the semantics 
of mathematical ranges (that is, 5:2 is the empty set) even though there 
was explicit text to the contrary, all because the word "range" was used.

-- Mark --

---

From: [email-masked] (Peter Robinson)
Date: Wed, 20 Apr 2005 23:19:33 +0100

> a mandatory part of READER and adds a range argument.

This (the range argument) would change LISTGROUP from a mere curiosity
into something clients might actually want to use.  That makes it a good
thing IMO.  The implementational burden this puts on servers is surely
trivial compared with CAPABILITIES, so that's not an issue for me, but I
think we should note somewhere that clients can't expect the range
parameter to work in old servers.

[...]

> If this proposal goes into the draft, it

Is the possibility of LISTGROUP [RANGE] as a(n optional) CAPABILITY
closed then?  (That's fine with me, I have no strong opinion on the
subject.)

>       LISTGROUP [group [range]]

Excellent.

>       number = estimated number of articles in the group

So 'number' is an estimate for the whole group, not just for articles in
the range.  That's fine, but I think it needs to be stated explicitly in
the text, since it's probably not what you'd expect unless you're used
to the old LISTGROUP.

>    selects the group in the same way as the GROUP command (see Section

I think we need to be clearer about what happens to the current article
pointer.  My reading of it is that by deferring to GROUP you're saying
that it's always the first article in the group that's selected, even if
it's not in the (non-empty) range, or if there are no articles in the
range.  I think this needs to be stated explicitly.

I also think we should say that the group is selected even if there are
no articles in the range.

[...]

>    newsgroup is not specified, the range may not be specified.
                                           ^^^^^^^
                                           MUST NOT?
Regards,

Peter

---

From: [email-masked] (Peter Robinson)
Date: Wed, 20 Apr 2005 23:19:34 +0100

Mark Crispin <[email-masked]> wrote:

> the group"?

AIUI, that would be far too hard for large servers.

> As far as I am concerned, an estimated value is worse than useless, and
> an NNTPv2 compliant server should be required to give an exact value.

It is usually pretty useless for a client.  But IMO it's not worth the
compatibility issues to get rid of it, and servers will just ignore us
if we say it must be accurate.

> What is a "reported" high and low water mark as opposed to a high and low

I assume that's because the values will often change before the next
command is issued, but that applies to most things so I'd be happy to
drop the word 'reported'.

> In a range, how is 5-1 interpreted?

Surely as the empty set.

> If it is it an error, then there needs to be an error code.

I don't think it should be an error.

> Should lists of article numbers/ranges be allowed, e.g. 1-5,14-34,56- ?

I don't think so.

Regards,

Peter

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Apr 2005 19:24:14 GMT

In <[email-masked]> Mark Crispin <[email-masked]> writes:

Pre-NNTPv2 clients will not be aware of the CAPABILITY command; therefore
they will not be issuing it. They will continue to issue the commands they
have always issued, and will continue to expect the responses they have
always received. By and large, the NNTPv2 draft delivers on that implied
promise, modulo a few tight corners and some places where existing
practice varies.

>> changed a second later doesn't strike me as much more useful than an

The estimate may change due to articles within the range which have been
cancelled or which have expired. The draft explicitly permits servers
simply to return the difference between the high and low water marks (as
"reported"), if they consider it too onerous to maintain a
second-by-second running total. Nobody cares if the number of articles
eventually returned is less than predicted - in practice the number is not
likely to be hugely less, unless some grand Hipcrime spew has recently
been cancelled.

BTW, I am happy to have a range parameter added to LISTGROUPS if that is
the consensus. Pre-NNTPv2 clients are unlikely to run into it
accidentally, and Post-NNTPv2 clients that try to use it on old servers
without checking CAPABILITIES first will get a dusty response.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Apr 2005 15:29:21 GMT

>range.  I think this needs to be stated explicitly.

But it would make more practical sense for it to be the first article in
the range. Surely this is easily arranged, given the need to do some
implementation work for this anyway.

BTW, I agree that a range 5-1 should be the empty set. You should be able
to get the high and low water marks from GROUP, and then say

LISTGROUPS groupname low-high

and get the same results as

LISTGROUPS groupname

(assuming no changes in availability of articles in the meantime). That
would agree with the rule that says high<low implies no articles.

---

From: [email-masked] (Peter Robinson)
Date: Thu, 21 Apr 2005 21:40:10 +0100

Charles Lindsey <[email-masked]> wrote:

> the range.

I agree.  Assuming servers have no trouble implementing it, I would much
prefer to do it that way.  But in that case, what should happen to the
current article pointer if there are articles in the group, but none in
the range?

> and get the same results as

IMO, that property is well worth having if at all possible.

Peter

---

From: Russ Allbery <[email-masked]>
Date: Thu, 21 Apr 2005 16:11:10 -0700

> IMO, that property is well worth having if at all possible.

Clive, when you have a chance, I think we have consensus that the current
INN behavior is wrong and that a range where the first digit is higher
than the second digit should not include any articles.  Could you make
that modification to the OVER and HDR specification when you have a
chance?

---

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

>current article pointer if there are articles in the group, but none in

The same thing as happens if you select the group with GROUP, and then ask
for ARTICLE with that number (whatever that behaviour is).

---

From: [email-masked] (Peter Robinson)
Date: Sat, 23 Apr 2005 12:39:17 +0100

> In <[email-masked]> [email-masked]

[LISTGROUP should select the first article in the range (not group)]

> for ARTICLE with that number (whatever that behaviour is).

It took me a while to understand what you're saying here.  By 'that
number', you must mean the leftmost number in the range parameter.  In
that case, the behaviour is to set the current article to the first
article in the group (which will be before or after the given range).  I
can live with that (or with selecting no article), but I think it needs
to be stated explicitly.

It's unhelpful to compare
 [C] LISTGROUP example.group 2-3
with 
 [C] GROUP example.group
 [C] ARTICLE 2
since they don't always leave the server in the same state (under this
proposal).  For example, the final article pointer will be different if
example.group has articles 1 and 3 only.

Regards,

Peter

---

From: Russ Allbery <[email-masked]>
Date: Sat, 23 Apr 2005 11:29:27 -0700

> implementation work for this anyway.

The worry that I have about doing this is that it makes it look like the
current article pointer should also stop at the end of the range, and
*that* is both unusual and possibly a pain to implement given that it's a
concept not previously found in the protocol.  Saying that it will be set
to the beginning of the range but won't stop at the end of the range is
awkward to explain.

It also requires some distinguished value for the article pointer that
means it's invalid even if there are articles in the group, something that
may not already be available, but that's probably a lesser problem.

I'm not particularly enamored of this idea.  Very little uses the current
article pointer in practice these days, and this adds some complexity to
the description without a lot of benefit.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 11:12:54 +0100

> that modification to the OVER and HDR specification when you have a

Done. In both cases:

    ... If the [second] argument is a range and no articles in that
    number range exist in the current selected newsgroup,
+   including the case where the second number is less than the first one,
    a 423 response MUST be returned.

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 11:42:14 +0100

> changed a second later doesn't strike me as much more useful than an

Furthermore, it may require significant resources to compute.

The specification of GROUP states:

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

I see no reason to change this (the case of an empty group is discussed in
the following paragraphs and is also, IMO, fine).

> fairly consistently through the rest of the draft as well.

"reported" is shorthand for "at the moment of selection":

    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"),

to prevent pedants claiming that these LWM and HWM mustn't change later
(because the response would become retroactively wrong).

[Range of 5-1]

> which has the same issue.

In OVER an empty range *is* an error (423) but in LISTGROUP it isn't.
So we do have a different situation here. I would suggest we have three
possible resolutions for an impossible range like 5-1:

    211 and an empty list
    501 (it's pretty obviously a syntax error)
    423 (consistency with OVER)

> (they're in the existing LISTGROUP writeup).

The pre-processor I use inserts them, partly to show that whitespace
doesn't matter and partly to more clearly separate command and arguments.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 11:47:59 +0100

Russ Allbery said:
> LISTGROUP is *also* stepping outside the charter of the group.

> finalize the i18n language, it's out.

I'm happy with the concept. I'd rather we hammered down the semantics and
then let me draft text rather than having to edit someone else's text so
as to preserve consistency of style. To that end, I *think* we've settled
on:

* Range is an optional second argument, only available if a group has
  been specified. It has the same form as with OVER.
* The *only* effect is to remove some entries from the list following a
  211 code; those entries that don't occur within the range.
* Consensus is to leave the current article number as if no range had been
  specified.
* Still undecided what to do if:
  - the range is valid but empty (e.g. 1-5 when the LWM is 10);
  - the range is inverted (e.g. 5-1).

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 11:50:28 +0100

Russ Allbery said:
> implement that I'm giving it a shot,

I've just remembered something else that falls into this category.

Can we make the parameter to GROUP be optional? The effect of omitting it
would be:
* If there is a currently selected group, the same as if it were specified.
* If there is no currently selected group, a 412 error.

The purpose is to allow the client to determine the currently selected
group. At present this can be done by using LISTGROUP with no arguments,
but that produces a list of indeterminate length that has to be thrown
away.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 11:56:05 +0100

[...]

These three-digit codes are *ARBITRARY*. While the structure might not be
what we would choose today, it's what we've got. There is *NO* benefit to
changing it, particularly using some baroque arrangement that returns
different codes to different clietns.

> the same semantics as GROUP then you must *say* that.

LISTGROUP currently says:

    (the arguments on the initial response line are the same as
    for the GROUP command)

and

That text will be staying.

> There is no reason why the three zeros response should be allowed in an 

There is no reason why it should not be allowed.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Apr 2005 13:20:17 GMT

>> >....  But in that case, what should happen to the

>example.group has articles 1 and 3 only.

But that case does not fall within your original question (see above).
Clearly, in this case the current poiter should be set to 3.

Put it another way. LISTGROUP returns you a list of article numbers, in
numeric order. The current article should be set to the first number
returned. Exceptionally, if the list returned is empty, it should be set
to the first article that exists in the group,

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Apr 2005 09:23:24 -0700 (PDT)

>  - the range is inverted (e.g. 5-1).

I'll argue, weakly, that 5-1 should be the same as 1-5.  However, this 
isn't as important in NNTP as it is in IMAP, since you don't have a "*" 
article number in NNTP.

I will, however, argue that if 5-1 is not the same as 1-5, then it should 
be a protocol syntax error and *not* equivalent to 5 or an empty range.

I understand that some servers treat 5-1 as equivalent to 5.  That 
behavior should *NOT* be required of future implementations.  We can 
declare it to be a syntax error without breaking those servers; since if 
it is a syntax error then it's the client's responsibility not to send it. 
The server's behavior then falls under the category of GIGO (garbage in, 
garbage out) and thus acceptable.

-- Mark --

---

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

Mark Crispin said:
> I'll argue, weakly, that 5-1 should be the same as 1-5.

I disagree.

> be a protocol syntax error and *not* equivalent to 5 or an empty range.

I'm agnostic.

> garbage out) and thus acceptable.

Wrong: if it's a syntax error, the server MUST return a 501 response.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Apr 2005 09:45:04 -0700 (PDT)

> different codes to different clietns.

The benefit is compliance with standard Internet protocol architecture.

I don't understand why the NNTP community is so determined to defy 
Internet standards and produce something which is similar, but different. 
I really hope that we are past the "news is news and mail is mail and 
ne'er the twain shall meet" attitude.

> That text will be staying.

That does not answer the objection.  The values (not "arguments" -- yet 
another thing that needs fixes) on the response line are documented 
independently in LISTGROUP and with subtly different wording.  That 
indicates that their semantics are different; and the difference is that 
the unique text in 6.1.1.2 does not apply.

The text
     (the arguments on the initial response line are the same as
     for the GROUP command)
clearly states that the values have the same syntax and names, not that 
their semantics are the same.  The text
     In all other aspects the LISTGROUP command behaves identically to the
     GROUP command.
doesn't apply because this isn't an "other respect"

Mr. Feather may have dictatoral power over the document now, but his 
dictatorship ends the instant the document is published as an RFC (or he 
is replaced as document editor).  Afterwards, his statements have *no* 
authority on the protocol.  If the document does not state what it means 
explicitly, then the protocol does not state it either.

You *must* make the document stand on its own.

> There is no reason why it should not be allowed.

The three zeros response implies that article numbers have been reset, and 
that the client should discard all knowledge of article numbers. 
However, NNTP lacks the UIDVALIDITY mechanism of IMAP, so there is a 
timing problem.  The client may or may not reset its record of article 
numbers depending upon whether it sees the three zeros response.

-- Mark --

---

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

> The benefit is compliance with standard Internet protocol architecture.

Meaning what? Just where is this "standard Internet protocol architecture"
documented?

> ne'er the twain shall meet" attitude.

"A foolish consistency is the hobgoblin of little minds." [Emerson]

Just what benefit does compliance with this "standard" produce? Client code
still needs to understand specific codes or simply say "it begins 4 or 5,
it failed, tough luck". This is *not* the same as mail where retrying later
can produce different results.

As I said, if we were starting from scratch I would agree with you, but it
is COMPLETELY AND UTTERLY POINTLESS trying to change things now. That would
be *foolish* consistency.

> another thing that needs fixes)

Wrong: they are "arguments"; it says so in 3.2.

> on the response line are documented 
> independently in LISTGROUP and with subtly different wording.

Where? As far as I can see, 6.1.2.1 uses the same wording as 6.1.1.1, and
6.1.2.2 just has the text you quote.

> That 
> indicates that their semantics are different;

I disagree. But I don't see the "subtly different wording" you do.

> their semantics are the same.

"the same" covers everything, not just some aspects.

> that the client should discard all knowledge of article numbers. 

No it does not. It indicates an empty group.

On the contrary, a three zeros response does NOT invalidate the requirement
that:

   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.

We deliberately decided not to provide a way for a server to reset article
numbers and start again at 1; it's too rare an event to clutter up the
protocol.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Apr 2005 10:01:05 -0700 (PDT)

>> I'll argue, weakly, that 5-1 should be the same as 1-5.

5-1 is a curiosity as long as there aren't extensions such as "*" for 
"highest assigned article number".  However, it becomes important when 
such extensions exist.

> Wrong: if it's a syntax error, the server MUST return a 501 response.

That is a silly argument.

It is impossible to test or certify for such a requirement, since the set 
of syntax errors is unbounded.  Therefore, it is a requirement without 
force.

Such a requirement would be widely disregarded.  It is doubtful that there 
is any server implementation of any non-trivial protocol which attempts to 
adhere to such a requirement, much less actually adheres to it.

Taken literally, such a requirement forbids future extension, since 
extensions are syntax errors in the unextended protocol.

NNTP is perhaps the sloppiest protocol in the entire messaging suite, so 
to pretend that there is rigor today is pointless.

The correct position to take is that a server returns a 501 response to a 
detected syntax error; however a client must not rely upon this behavior 
and must not send syntax errors.

-- Mark --

---

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

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

> I'm happy with the concept. I'd rather we hammered down the semantics
> and then let me draft text rather than having to edit someone else's
> text so as to preserve consistency of style. To that end, I *think*
> we've settled on:

> * Consensus is to leave the current article number as if no range had been

I agree with the above as a working group participant; as chair, I do want
to point out that there have been a couple of people who wanted to see the
current article number set to the beginning of the range.  I don't know if
my argument persuaded them?

>   - the range is inverted (e.g. 5-1).

I don't think we really were undecided about the first -- LISTGROUP
returns an empty multiline response and otherwise behaves just like GROUP.
I think we should do the same with the latter, since returning an error
would mean making a decision about whether the group was selected anyway,
and I think it's best to make it behave the same as the first.

Both of these are different than OVER and HDR, though, which is worth a
bit of nervousness.

---

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

> isn't as important in NNTP as it is in IMAP, since you don't have a "*"

Oh, for the current article number... I see why you might want that.
Alas, that's probably the only way of treating 5-1 that no existing NNTP
software implements.

There is something to be said for it.

> I will, however, argue that if 5-1 is not the same as 1-5, then it
> should be a protocol syntax error and *not* equivalent to 5 or an empty
> range.

Or 5-, which is what INN has always done.  I think that's more common than
treating it as equivalent to 5.

I think the real choices are:

 * Same as 1-5.
 * Empty range.
 * Syntax error.

Everything else makes little logical sense to me.  I'm still leaning
towards the second, treating it as an empty range, and that seemed the
prevailing opinion in news.software.nntp and what the software that
doesn't do what INN does mostly does with it.

---

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

> but that produces a list of indeterminate length that has to be thrown

This is feeling like we're falling down a slippery slope of last-minute
changes to me.  I was willing to pursue LISTGROUP because a few client
authors went "this, this I want to use" when the idea was raised.  Do we
have a similar feeling with this addition, or is it just in there for
cleanliness?  If the latter, I'd rather add it later if a real need shows
up (something that isn't too difficult to do, since right now this is a
syntax error).

My intuition says it would be very strange for a client to not know what
its current group is.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Apr 2005 11:13:37 -0700 (PDT)

> Meaning what? Just where is this "standard Internet protocol architecture"

It is not MY job to do YOUR research for you.  If you can not fufill your 
responsibilities as document editor, then please resign and allow someone 
who is more responsible to take over.

Ken Murchison would be a good choice.

> "A foolish consistency is the hobgoblin of little minds." [Emerson]

I'm afraid that you are the one who is being small-minded.  Time and time 
again, your response to any criticism is "will not change" or to put your 
fingers in your ears and scream "I'M NOT LISTENING!"

> it failed, tough luck".

Client response to a 4xx is different than to a 5xx; or rather it is in 
protocols that comply with the standard theory of response codes.

> This is *not* the same as mail where retrying later

Why?  Have you rigorously considered all instances in which mail returns a 
4xx code and determined that these can never apply to NNTP?

> be *foolish* consistency.

It is not pointless to free future implementors from the burden of the 
current non-standard ad-hoc system of response codes.

> Wrong: they are "arguments"; it says so in 3.2.

The text in 3.2 is not a definition; it's just more of the same misuse of 
the word "argument".

> 6.1.2.2 just has the text you quote.

The text in 8.3.1.2 describes the effect of LISTGROUP.  It goes into some 
detail in describing how LISTGROUP is similar to GROUP in various aspects 
but omits such text for other aspects.  That omission must be significant; 
so, for example, the text in the third paragraph of 6.1.1.2 doesn't apply.

You could rewrite 8.3.1.2 to say something like:
    The LISTGROUP command is an extended form of the GROUP command
    (see Section 6.1.1).  As such, it behaves and responds identically
    as the GROUP command, with the following extensions:

    The first extension is that the newsgroup argument is optional; if
    it is omitted, the currently selected newsgroup is used.  A 412
    response is returned if there is no currently selected newsgroup.

    The second extension is that, on success, a list of article numbers
    is returned as a multi-line response following the 211 response
    code (see Section 6.1.1.2 for the semantics of this code).  The
    list contains one number per line in ascending numerical order, and
    lists precisely those articles that exist in the newsgroup.

The above text is shorter, more precise, and lacks the ambiguity of what 
is currently there.

This reminds me of something else.  The entire document uses two different 
words, "group" and "newsgroup".  Although the author may have intended 
these terms to be interchangable, that isn't the effect.  The document 
clearly identifies "group" and "newsgroup" as being separate concepts, and 
thus there must be a difference.

Also, "current selected newsgroup" is a grammar error; it should be 
"currently selected newsgroup".  Even when a verb 
is used as an adjectival, the modifier of that verb must still be an 
adverb.

> I disagree. But I don't see the "subtly different wording" you do.

See above.  You have pieces of 6.1.1.2 in 8.3.1.2, but not the entirety of 
6.1.1.2.  That must mean that the omitted pieces do not apply.

Either copy all of 6.1.1.2 to 8.3.1.2, or have 8.3.1.2 reference 6.1.1.2 
and do not duplicate what is in 6.1.1.2.

> "the same" covers everything, not just some aspects.

Sorry, that is not the way that people reading the specification will 
interpret it.  They, not you, will ultimately determine the meaning.

True life example: IMAP once defined a range as "all values between the 
two given values inclusive."  That was not enough; someone insisted that 
this only applied to ascending ranges, and that "all" does not apply to 
descending ranges.

> No it does not. It indicates an empty group.

You may say that it does, but the fact that it exists as a separate 
response indicates otherwise.

> numbers and start again at 1; it's too rare an event to clutter up the

Yet you cluttered up the protocol with a pointless three zeros response 
for which there is no need since there are other responses which fufill 
the same requirements.

A server manager, having a need to reset article numbers (perhaps after a 
catastrophic failure), will see the three zeros response as being the 
means to indicate that, no matter what you say.

You always fall back on the same set of arguments.  On the one hand, you 
use "it would clutter up the protocol" to shoot down a remedy for a 
problem; on the other, you defend the maintenance of clutter on the ground 
that old servers (which aren't going to advertise NNTPv2) had the clutter.

If you choose to abuse your position as document editor to stymie any 
revision to the status quo, this entire working group is pointless and the 
document is a failure.

The document does not describe the deployed protocol.  It describes a 
revision to that protocol which will require considerable effort on the 
part of both client and server implementors to comply.  On the other hand, 
it does at best a half-hearted job in remedying problems in the deployed 
protocol which have repeatedly caused problems for client implementors.

Let's just abandon the whole thing.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Apr 2005 11:56:39 -0700 (PDT)

Before NNTP can be standardized, it must go through a great many rigorous 
steps, in which individual opinions are not going to count (and this 
includes the opinions of the document editor).

These are IETF requirements; the NNTP working group can not override them.

Among these requirements is an implementation report which shows multiple 
independent interoperable client and server implementations of every 
aspect of the protocol.  Those aspects of the Proposed Standard protocol 
which do not have multiple independent client and server implementations 
will be removed from the document that describes the Draft Standard.

The above needs to be kept in mind.  I disagree sharply with what the 
document editor considers to be "clutter"; but ultimately neither his 
razor nor mine matter -- the Draft Standard protocol will be cut with a 
much more aggressive razor.

Once again, I recommend that we split this document into two separate 
documents:

One document, to be published as Informational, will attempt to describe 
"what is"; that is, the NNTP protocol as is implemented by various client 
and server implementations that are deployed around the world.  The fact 
that an implementation does (or depends upon) such-and-such is sufficient 
to merit inclusion in this document.

The other document, to be published as a Proposed Standard, will attempt 
to describe "what should be"; that is, the NNTP protocol as disambiguated, 
and cleaned up.  It is expected that no current client or server will 
conform perfectly to this document; thus, there must be a way for a 
conformant client and server to identify each other.

It is not necessary for a non-conformant implementation to interoperate 
with a conformant implementation.  It is desirable for the short-term; and 
some effort should be made in producing an interoperability document 
focusing on how a conformant server can interoperate with an old client.

Nevertheless, the long-term will require conformance.  Old software, 
especially old servers, will eventually die.

-- Mark --

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Apr 2005 16:15:07 -0400

Mark Crispin wrote:

> It is not MY job to do YOUR research for you.  If you can not fufill 
> your responsibilities as document editor, then please resign and allow 
> someone who is more responsible to take over.
> 

Whoa!  I'm staying out of this.  I'm having a hard-enough time keeping 
up with my own documents, I'm not signing up for another (nor do I feel 
it needs to be reassigned).

---

From: [email-masked] (Peter Robinson)
Date: Mon, 25 Apr 2005 23:48:43 +0100

Russ Allbery <[email-masked]> wrote:

> > [...], I *think* we've settled on:

[when a range is given]

> [...]; as chair, I do want to point out that there have been a couple of
> people who wanted to see the current article number set to the beginning
> of the range.

At first glance it seems to be the most natural thing to do (especially
without explicit wording to the contrary).

> I don't know if my argument persuaded them?

I am persuaded that the difficulty of specifying the current article
pointer for a range that contains no articles in a non-empty group, and
the inconsistency it brings, far outweighs the attractions of using the
first article in the range as the current article pointer.  That was
part of your argument.

Regards,

Peter

---

From: [email-masked] (Peter Robinson)
Date: Mon, 25 Apr 2005 23:48:43 +0100

Russ Allbery <[email-masked]> wrote:

> > group.

Interesting!

[...]

> changes to me.

Yes.

> I was willing to pursue LISTGROUP because a few client authors went "this,
> this I want to use" when the idea was raised.  Do we have a similar
> feeling with this addition, or is it just in there for cleanliness?

My feeling is that it's a shame it's not always been available and it
fits snugly into the GROUP command, but that it's probably not worth
adding another subtle incompatibility now.  Having said that, if other
people want it, I won't argue against.

> My intuition says it would be very strange for a client to not know what

I agree.

Regards,

Peter

---

From: [email-masked] (Peter Robinson)
Date: Mon, 25 Apr 2005 23:48:45 +0100

> >> >....  But in that case, what should happen to the current article
> >> >pointer if there are articles in the group, but none in the range?
> >> 
> >> The same thing as happens if you select the group with GROUP, and then
> >> ask for ARTICLE with that number (whatever that behaviour is).
> 
> 

Quite so.  And your response (once I understood it) was a complete and
consistent answer to my question.  I was just confused as to why you
mentioned ARTICLE at all (as if it was illustrating a general principle)
rather than saying that the article pointer is set to the first article
in the group.

I was probably reading far too much into your wording.

> to the first article that exists in the group,

I would be perfectly happy with that, but the consensus seems to be
going another way.  All that's really important to me is that it's
specified clearly, rather than implicitly via the GROUP behaviour.

Regards,

Peter

---

From: [email-masked] (Peter Robinson)
Date: Mon, 25 Apr 2005 23:48:46 +0100

Russ Allbery <[email-masked]> wrote:

> current article pointer should also stop at the end of the range,

I don't share that particular worry.  In GROUP, the article pointer
doesn't 'stop at the end' of the reported high water mark if more
articles arrive.

> and *that* is both unusual and possibly a pain to implement given that
> it's a concept not previously found in the protocol.

I do share that concern.

[...]
 
> the description without a lot of benefit.

That (scrapping this idea) is fine with me as long as we're clear about
it in the spec.

Regards,

Peter

---

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

> doesn't 'stop at the end' of the reported high water mark if more

But, for example, should LAST be allowed to move before the start of the
range?

>> it's a concept not previously found in the protocol.

And I.

> That (scrapping this idea) is fine with me as long as we're clear about

We will be.

---

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

Russ Allbery said:
>> Can we make the parameter to GROUP be optional?

> This is feeling like we're falling down a slippery slope of last-minute

Did you look at my actual wording changes to see how it would be done?

> I was willing to pursue LISTGROUP because a few client

It's partly there for cleanliness, since LISTGROUP can do it the same way,
but it's partly there for a potential use. I feel it's like the range
stuff: easy to implement and useful if it can be written up simply.
[The range stuff is all new as well, isn't it? Nobody does it already do
they?]

> My intuition says it would be very strange for a client to not know what

That used to be my intuition on such things, but I discovered what a pain
it can be to track stuff across code broken into modules. As a slightly
contrived example, consider the case where a client has to do an exec() for
some reason.

---

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

> my argument persuaded them?

At the point I wrote that I thought it had been settled. Reading since I
see it hasn't. I will leave you to make the call (my vote is for what I've
written - range doesn't affect the current article number).

> returns an empty multiline response and otherwise behaves just like GROUP.

I flagged it as undecided because I'd only just raised the point that OVER
does it differently.

> and I think it's best to make it behave the same as the first.

Agreed. All instances of "empty range", including inverted ranges, should
be treated identically.

> Both of these are different than OVER and HDR, though, which is worth a

True, but thinking about it any change to the present behaviour is also
worth a bit of nervousness.

Your call, but I vote for making it an empty list in all those cases.

---

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

>my argument persuaded them?

I was one of those people. But above all, I want the following two
properties to hold:

A. Assuming 5-1 is not an error, then the effect of
   LISTGROUP groupname 5-1
MUST be identical to the effect of
   LISTGROUP groupname.

B. Given that the reported High and Low watermarks are known, then the
effect of
   LISTGROUP groupname Low-High
MUST be identical to the effect of
   LISTGROUP groupname
even when the group is empty, which implies that 5-1 means an emtpy range,
rather than an error.

Clive's latest text satisifies both these properties, but sets the
current_ly_ selected group to the first article regardless.

I would still prefer it to be set to the first article of the returned
list (if non-empty), but will defer to the majority view. BUT, if the
returned list is emtpy, then it would still have to select the firsrt
article in the group in order to preserve those two properties.

---

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

>It is not MY job to do YOUR research for you.

If you are asked a straight question, you should be giving a straight
answer.

>  If you can not fufill your 

This is no time to be thinking of changing editors. For the record, may I
say that I have complete confidence in Clive Feather's capabilities as an
editor.

>current non-standard ad-hoc system of response codes.

And it is worse than pointless to impose a change that is not backwards
compatible with existing practice. It would also be in breach of our
charter.

>is used as an adjectival, the modifier of that verb must still be an 

Yes, I would agree with you there.

>for which there is no need since there are other responses which fufill 

Kindly refrain from blaming the current editor ("you") for a feature which
long predated his appointment as editor, and which presumably had the
consensus of the WG at the time it was introduced.

It is there for backwards compatibility. Some existing servers produce it.
The draft deprecates it for new software, but it is not going to go away;
clients still have to understand it.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Apr 2005 09:43:17 -0400

>>up (something that isn't too difficult to do, since right now this is a

If its useful, I'd say add it.  We might as well get the functionality 
that we need/want now and not have to worry about it later.

---

From: "Andrew - Supernews" <[email-masked]>
Date: Tue, 26 Apr 2005 16:48:14 +0100

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

 Clive> Can we make the parameter to GROUP be optional?

No.

 Clive> The purpose is to allow the client to determine the currently
 Clive> selected group. At present this can be done by using LISTGROUP
 Clive> with no arguments,

"At present" meaning in the spec, or in existing implementations?

Did someone sneak in a change to the LISTGROUP result text while I
wasn't looking? LISTGROUP traditionally does _NOT_ return the same
output as GROUP does; that may be a wart, but it's worth noting that
there is _no other place_ in the protocol that requires the server
to remember the name of the current group.

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Apr 2005 12:29:49 -0400

>  Clive> Can we make the parameter to GROUP be optional?

I assume this is because you're afraid that a NNTPv2 client will try to 
send this to a legacy server?

> to remember the name of the current group.

AFAICT, the initial response line for LISTGROUP was changed to match 
GROUP way back in draft 16 (Clive's first).

---

From: Russ Allbery <[email-masked]>
Date: Tue, 26 Apr 2005 11:39:48 -0700

> Did you look at my actual wording changes to see how it would be done?

Yeah, I know, the wording is trivial; I'm just really nervous about
changes that don't follow what people have already done in practice.
Okay, I'm not going to stand in its way, beyond expressing a lot of
nervousness.

I want to go to a general last call as soon as we get the i18n language
taken care of.  I *really* hope it won't be longer than the middle of
May.  All this work we've done isn't really helping anyone until we
publish it.  So if this sparks any controversy, I'd rather drop it than
spend time discussing it.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 26 Apr 2005 11:42:15 -0700

> MUST be identical to the effect of

Er.  That's a completely different behavior than anyone has noted in
practice or asked for before.  Did you mean GROUP groupname in your second
example there?

> even when the group is empty, which implies that 5-1 means an emtpy range,

Saying that 5-1 is the empty range contradicts what you said in A above,
unless you meant GROUP.

Assuming you mean GROUP, I agree with both of what you say.

> article in the group in order to preserve those two properties.

Right.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 26 Apr 2005 11:44:21 -0700

> to remember the name of the current group.

Yeah, this was changed quite a while back and is what INN currently does.
At least year or two, I think, and there was a fair bit of discussion
about it at the time.  I don't recall any concerns being raised at the
time; do you feel that this is going to cause problems?

---

From: "Andrew - Supernews" <[email-masked]>
Date: Tue, 26 Apr 2005 19:59:57 +0100

>>>>> "Russ" == Russ Allbery <[email-masked]> writes:

 >> to remember the name of the current group.

 Russ> Yeah, this was changed quite a while back and is what INN
 Russ> currently does.  At least year or two, I think, and there was a
 Russ> fair bit of discussion about it at the time.  I don't recall
 Russ> any concerns being raised at the time; do you feel that this is
 Russ> going to cause problems?

It certainly will for me, because I never store the group name
anywhere in reader code, and in a lot of places I use only
md5(groupname) as an internal equivalent.

I must have missed it before, or didn't catch the implications... I'll
have to go back and look.

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

---

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

Andrew - Supernews said:
> wasn't looking?

It would seem so.

> LISTGROUP traditionally does _NOT_ return the same
> output as GROUP does;

In draft 17 (the first one I edited) we had:

   The optional parameter ggg is the name of the newsgroup to be
   selected (e.g.  "news.software.misc").  A list of valid newsgroups
   may be obtained from the LIST ACTIVE command.  If no group is
   specified, the current selected newsgroup is used.

   OUTSTANDING ISSUE
      
      On at least some servers the 211 response line is the same as with
      GROUP.  Should this be a requirement?

   The list of article numbers is returned as a multi-line response
   following the 211 response code.  It contains one number per line, is
   in numerical order, and lists precisely those articles that exist in
   the group.

In draft 18 the 211 response was changed to look the same as that of the
GROUP command, so it looks like we agreed it in March or April 2003. You'll
have to dig into the archives to see what the discussion was.

The parameter is shown as optional, with the default being the current
group, all the way back to draft 00. Checking further, RFC 2980 has this as
well.

> that may be a wart, but it's worth noting that

And so no other way for the client to find it again.

If LISTGROUP is mandatory and the first argument is optional, then making
GROUP have the same property is trivial.

If we decide to change either property of LISTGROUP then, I accept, we may
want to re-think GROUP with no argument.

---

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

> GROUP way back in draft 16 (Clive's first).

See other message.

[16 was the first one I was editor for, but it was simply a re-issue of 15
with no changes.]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 07:42:03 +0100

> MUST be identical to the effect of

Um, that says that 5-1 means "list all articles".

> even when the group is empty, which implies that 5-1 means an emtpy range,

Having it not be an error is fine, but you're saying 5-1 now means "empty".
You can't have both those properties be true.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 10:00:04 +0100

> It is not MY job to do YOUR research for you.

On the contrary, *you* made the assertion so it is up to *you* to provide
the evidence. I believe that there is no such "standard architecture"; I
explicitly note that Appendix E of RFC 821 is nothing of the sort.

> fingers in your ears and scream "I'M NOT LISTENING!"

I have made plenty of changes in response to criticism, the last less than
5 minutes ago.

However, I am *not* going to put in gratuitous incompatibilities with
existing practice contrary to our charter without the full agreement of the
working group including its Chair. Something that I don't think you have
the slightest chance of getting.

> Client response to a 4xx is different than to a 5xx;

In what way?

> or rather it is in 

"standard theory" or "standard architecture"?

> 4xx code and determined that these can never apply to NNTP?

The only circumstances in NNTP where a retry *without other client action*
is likely to succeed is the 436 response code.

> The text in 3.2 is not a definition; it's just more of the same misuse of 

They are arguments of the response and it's a valid use of the term.

[LISTGROUP v GROUP]

I disagree with your view and note that nobody else seems to agree with
you. Therefore I see no reason to change my current text (which, for
reference, is *not* draft 25).

> thus there must be a difference.

That is mostly a valid criticism. The document does *not* clearly identify
them as being separate concepts, and those familiar with the topic will
know that they are not. However, I have added a note to make it clear that
the terms are interchangeable and, in a few cases, used the longer term
where the shorter was present. I do not, however, believe that it is
worthwhile changing every single use.

The one other use of "group" - a set of commands identified by a single
capability label - has been replaced by "bundle".

Oh, there are two uses of "working group" in the acknowledgements; I see no
reason why any sane person should be confused by this.

[...]

There is a proverb about arguing with pigs. I'm beginning to think it's
appropriate.

> means to indicate that, no matter what you say.

But as soon as an article arrives subsequently that information is lost.
Dealing with these issues is one of the reasons we chose not to go that
way.

Note that a newsgroup seeing an arrival rate of 10 articles per second will
take over 13 years to exhaust the article number range. That makes this
a non-issue.

> problem;

"Mark Crispin thinks this should be changed" is not the same as "there is a
problem". Where a problem has been identified *and agreed* by the group, I
have been ready to modify the document and/or protocol appropriately, even
when the decision opposed my own view.

> on the other, you defend the maintenance of clutter on the ground 

To do otherwise breaks our charter.

> revision to the status quo, this entire working group is pointless and the 

Kindly withdraw that remark immediately.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Apr 2005 10:10:37 GMT

>practice or asked for before.  Did you mean GROUP groupname in your second

Oops! That was obviously wrong. Forget it. Property B gives the important
requirement.

>Right.

OK, so include that feature or not as people wish.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Apr 2005 08:19:27 -0700 (PDT)

> Kindly withdraw that remark immediately.

I do not withdraw it.  I stand by it.  Your latest tirade has convinced me 
that it is a complete waste of my time to continue any conversation with 
you or this WG.

-- Mark --

---

From: Russ Allbery <[email-masked]>
Date: Wed, 27 Apr 2005 10:49:35 -0700

Mark Crispin <[email-masked]> writes:

> I do not withdraw it.  I stand by it.  Your latest tirade has convinced
> me that it is a complete waste of my time to continue any conversation
> with you or this WG.

Well, you're pushing very hard a change that no one else thinks is
warranted or useful and it's gotten more and more heated over time.  It's
kind of painful to watch.

However, even if you don't provide us any more input, I really appreciate
your input into the capabilities handling and several other things.  I
think our final document will be stronger and more useful due to your
input.

---

From: [email-masked] (Peter Robinson)
Date: Wed, 27 Apr 2005 23:18:22 +0100

> But, for example, should LAST be allowed to move before the start of the

I don's see why not, but it's academic now and that's fine with me.

> > That (scrapping this idea) is fine with me as long as we're clear about

Yes, your new wording is much clearer.

Regards,

Peter

---

From: [email-masked] (Kai Henningsen)
Date: 30 Apr 2005 14:50:00 +0200

[email-masked] (Mark Crispin)  wrote on 27.04.05 in <[email-masked]>:

> >> revision to the status quo, this entire working group is pointless and
> >> the document is a failure.

Well, well, well. The one person throwing one tantrum after another (using  
entirely spurious arguments) accuses other people of a tirade. Why am I  
not surprised?

I agree with the "waste of time" assessment, though I suspect our  
reasoning for that has no overlap.

Good bye.

MfG Kai