Subject: [NNTP] Draft 26 pre-2

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 3 May 2005 10:24:42 +0100

Now in the usual place:

<http://www.davros.org/nntp-texts/draft26.pre-2.txt>
<http://www.davros.org/nntp-texts/draft26.pre-2.html>

Still some known formatting problems, but apart from that there are no
further changes waiting to be done.

Areas altered (in most cases the changes are very minor):

* 3.1.
* 3.1.1
* 3.2.1.1
* 3.3.2
* 3.3.4
* 5.2.3
* 5.3.3
* 7.4.1
* 8.1.1
* 9 (added 9.1, renumbered existing subsections)
* 9.3 (was 9.2)
* 9.4.1 (was 9.3.1)
* 9.4.2 (was 9.3.2)
* 9.4.3 (was 9.3.3)
* 9.5 (was 9.4)
* 9.6 (was 9.5)
* 9.9 (was 9.8)
* 10.1
* 10.2
* 10.3
* 12.6 (example only)
* 14.1
* Appendix B

-- 
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: Tue, 03 May 2005 11:17:27 -0400

> further changes waiting to be done.

I thought the consensus was to make LISTGROUP a mandatory part of the 
READER "bundle"?

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 3 May 2005 16:37:02 +0100

> I thought the consensus was to make LISTGROUP a mandatory part of the 

Was it (I've lost track)? Russ, is that your understanding of the consensus?
If so, I'll make the change.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 03 May 2005 08:39:46 -0700

> I thought the consensus was to make LISTGROUP a mandatory part of the

I think it was still a bit up in the air, but that does seem to be the way
that the wind is blowing, so I'm going to declare that consensus and see
if anyone objects.

So, does anyone object?  :)

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 03 May 2005 11:39:35 -0400

> If so, I'll make the change.

Actually, from rereading the thread, it looks like we are supposed to 
get feedback from client authors.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 03 May 2005 08:46:05 -0700

> get feedback from client authors.

I posted to news.software.nntp about this and didn't really hear much.  A
few people seemed to think it was a good idea, and no one screamed.  I can
try another message, I suppose.

---

From: Matthias Andree <[email-masked]>
Date: Tue, 03 May 2005 18:12:23 +0200

> So, does anyone object?  :)

For what it's worth, leafnode already supports LISTGROUP (RFC-2980
style), I don't mind it being made mandatory.

I'd vote yes just to reduce diversion and foster consistency across
implementations.

-- 
Matthias Andree

---

From: Ade Lovett <[email-masked]>
Date: Tue, 03 May 2005 11:58:06 -0700

> So, does anyone object?  :)

Do it already :)  At least then we can strike that bit off and then
concentrate a few cycles on the whole GROUP/LISTGROUP arguments issue.

-aDe

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 4 May 2005 08:41:34 +0100

> that the wind is blowing, so I'm going to declare that consensus and see

Done.

The diffs, for anyone who cares:

* Several examples have READER LISTGROUP changed to READER in the
capabilities list.
* In the definition of the READER capability in 3.3.2, delete the sentence:
    If and only if the LISTGROUP command is implemented,
    there MUST be an argument LISTGROUP.
* Change 6.1.2.1 from "READER with argument LISTGROUP" to "READER".
* In 6.1.2.2:

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

[...]

-   In all other aspects the LISTGROUP command behaves identically to the
+   Except for the range argument and the multi-line data block following
+   the 211 response code, the LISTGROUP command is identical to the
    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.

[The two bits of text sort of duplicated each other, so I rationalized them
into one.]

* In 9.5, remove [WS "LISTGROUP"] from <reader-capability>.
* In Appendix B, change "READER LISTGROUP" to "READER" and, in the second
  table, move LISTGROUP to after LAST. Delete the sentence:

     Where two keywords are given in the capability column, the second is
     an argument to the first.

---

From: "Andrew - Supernews" <[email-masked]>
Date: Sat, 07 May 2005 17:54:58 +0100

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

 Clive> Now in the usual place:
 Clive> <http://www.davros.org/nntp-texts/draft26.pre-2.txt>
 Clive> <http://www.davros.org/nntp-texts/draft26.pre-2.html>

 Clive> Still some known formatting problems, but apart from that
 Clive> there are no further changes waiting to be done.

I reiterate my objection to messing with the GROUP command at this
extremely late stage.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 10 May 2005 07:14:01 +0100

> I reiterate my objection to messing with the GROUP command at this

What about the response to LISTGROUP? That also requires the group name to
be stored.

---

From: Ade Lovett <[email-masked]>
Date: Tue, 10 May 2005 09:02:17 -0700

> What about the response to LISTGROUP? That also requires the group  

If you've changed that, too, (I've lost track of the drafts, diffs,  
cut-n-pastes etc) then that's an issue as well.

As it stands right now, LISTGROUP most definitely does not need the  
*human-readable* version of the group name to be stored.

 >>> listgroup
<<< 412 no newsgroup has been selected
 >>> group supernews.test
<<< 211 225 48045 48269 supernews.test group selected
 >>> listgroup
<<< 211 article list follows
<<< 48045
     [...]
<<< .

Since there is a reasonable amount number of objections here, please  
revert both GROUP and LISTGROUP to the original wording corresponding  
to how things are right now.

Thanks,
     -aDe

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 11 May 2005 08:54:30 +0100

> cut-n-pastes etc) then that's an issue as well.

A *long* time ago the 211 response to LISTGROUP was changed to be the same

> *human-readable* version of the group name to be stored.

It has for some time (it's been there for about a year; it was in draft 23).

> <<< 211 article list follows

  <<< 211 225 48045 48269 supernews.test article list follows

> to how things are right now.

The LISTGROUP change has been through at least one Last Call, so I'm loath
to change it back without debate and certainly not without Russ's input.

The GROUP change is, I believe, secondary to that. If the 211 response to
LISTGROUP is changed back then I accept the GROUP change is unsupportable.
Contrariwise, the only objection I've seen to GROUP is that it requires
storing the name, which LISTGROUP currently also requires.

---

From: Ade Lovett <[email-masked]>
Date: Wed, 11 May 2005 09:33:21 -0700

On May 11, 2005, at 00:54 , Clive D.W. Feather wrote:
> as the 211 response to GROUP.

If LISTGROUP had a single required argument, as with GROUP, then that  
would make sense -- you could argue that both commands are different  
ways to enter a group, setting the current article pointer to the  
first available in that group, the only difference being that  
LISTGROUP had a further multiline response dumping out the list of  
"available" article numbers.

That's not the case, however.  Current use of both GROUP and, more  
importantly, LISTGROUP, is well-defined (I've spoken with people  
involved in one of the more popular Windows-based newsreaders), and  
certainly any text after the relevant 211 response line is simply  
thrown away.

Indeed, with the output of GROUP being a notable, and unfortunate  
exception, I grew up with clients that merely parsed the three-digit  
response code and threw away the rest of the initial response line.

The proposed changes do nothing to improve the usability of LISTGROUP  
in the wild, whilst placing considerable constraints on those server  
authors that have to deal with a *LARGE* number of simultaneous  
client connections.  In such cases, seemingly harmless changes to  
output can generate *HUGE* implementation headaches, for essentially  
no gain.

> to change it back without debate and certainly not without Russ's  

I so request such debate.

-aDe

---

From: Ken Murchison <[email-masked]>
Date: Fri, 13 May 2005 12:46:30 -0400

> <http://www.davros.org/nntp-texts/draft26.pre-2.html>

The wording in paragraph 4 of section 1 seems a little awkward, possibly 
because it was based on the fact that we used to have commands like OVER 
described as extensions, where now they are just optional.  At the very 
least, I think the phrase "... a mechanism to discover what new 
functionality is available ..." should be changed to "... a mechanism to 
discover what new or optional functionality is available ..."

---

From: "Andrew - Supernews" <[email-masked]>
Date: Fri, 13 May 2005 21:44:50 +0100

>> I reiterate my objection to messing with the GROUP command at this

 Clive> What about the response to LISTGROUP? That also requires the
 Clive> group name to be stored.

I don't care about that either way (as I said before).

I'm not objecting to changing GROUP because of implementation
considerations. I'm objecting to making trivial pointless changes to
one of the most important commands in the specification in a draft
which should have been long since finished. We SHOULD NOT BE PISSING
ABOUT WITH STUFF WITHOUT CAUSE this late in the proceedings.

The arguments in favour of changing GROUP amount to little more than
"because we can". Nothing of real advantage to anyone is being
proposed (unlike the LISTGROUP range argument, which has the potential
to be hugely useful to clients and servers).

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