Subject: Re: [NNTP] Snapshot 2 and straw poll

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 18 Nov 2004 08:47:17 +0000

Russ Allbery said:
>> In
>> the meantime, I'd like opinions and so am calling a straw poll:
>> [A]  I prefer this approach in 25.pre-2.
>> [B]  I prefer the LIST extension approach in 25.pre-1.
>> [C]  I prefer the optional command approach of draft 24.
>> [D]  They're all bad, here's my suggestion:
> 
> I like the pre-2 version the best, I think.

This has to be one of the least successful straw polls ever! After a week,
I get exactly one vote.

Since Russ has the good sense to agree with me, that's the approach that
will be retained.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Nov 2004 14:30:01 GMT

>This has to be one of the least successful straw polls ever! After a week,

OK, I'll buy [A] (though I have not studied every fine nuance of the
dre-draft).

Likewise, I will buy the MORE READER stuff.

A few detailed comments follow:

7.6.1  LIST ACTIVE
 
You _could_ say:

      LIST [ACTIVE [wildmat]]

In fact, you DO say that in 9.1.

7.6.3  Other variants of the LIST command

I am not too happy that LIST ACTIVE and LIST NEWSGROUPS are not treated as
just special cases of the 'LIST keyword' command. The only difference that
I can see is that they are mandatory, and that they do not get listed in
LIST EXTENSIONS. The normal user is not going to appreciate this subtlety,
and will be surprised not to see

      [C] LIST EXTENSIONS
      [S] 202 Extensions supported:
      [S] _LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA

Far simpler to say that they MUST be reported after _LIST.

Also, I hope that when CAPABILITIES happens that stupid underscore in
'_LIST' will be abandoned.

It is slightly surprising that the LISTGROUPS command is not "LIST
GROUPS", but I suppose that is history.

3.3  Reading and Transit Servers

   ... Since the hosts doing this transfer tend to be
   peers in a network that transmit articles among one another, rather
   than end-user system, this process is called "peering" or "transit".

"Peering" has a connotation of equality. But even in a connection between
"peers", one of them is acting as the server and one as the client at any
one time. I think the wording should be clarified here to reflect that.

   o  A transit-only server MUST fully implement all transit commands,
      but fails to implement all or some reader commands.
   o  A reader-only server MUST fully implement all reader commands, but
      fails to implement all or some transit commands.

s/but fails to/but MAY fail to/ (twice)
It is ungrammatical as you have it. There may be other fixes.

   OUTSTANDING ISSUE
      The above permits a transit-only or reader-only server to
      implement more than the relevant minimal set of commands.  Is this
      a good idea or should the server be required NOT to implement
      them? For example, should a transit-only server be allowed to
      implement NEWNEWS? It could be a useful way for a client to
      determine which articles don't need to be sent in the absence of
      CHECK.  What about GROUP? If so, what happens to the
      currently-selected group after MODE READER?

I am happy to allow non-x servers to offer a few of the x-facilities. Suck
feeds often use the NEWNEWS command (that's what I do, and it goes
straight into my main news database long before any user agent becomes
involved). So I am happy if someone wants to implement a server specially
tailored to support suck feeds of this kind.

... Servers SHOULD NOT be mode-switching.

RFC 2119 language seems a but too strong there. Perhaps some weaker
word like "deprecated" would be better (we might "deprecate" INN, but it
is not going to go away anytime soon, and I would not like to burden it
with violating a "SHOULD").

-- 
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: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 19:52:10 -0800

> GROUPS", but I suppose that is history.

No, it's because it doesn't fit the requirements of a LIST command.  In
particular, it changes the server state by changing the selected group,
something that LIST commands are not permitted to do.

> I am happy to allow non-x servers to offer a few of the
> x-facilities. Suck feeds often use the NEWNEWS command (that's what I
> do, and it goes straight into my main news database long before any user
> agent becomes involved). So I am happy if someone wants to implement a
> server specially tailored to support suck feeds of this kind.

I don't see any reason to prevent servers from implementing commands from
both sets, but note that we don't have any way of advertising just what
commands from the other set the server implements, and I don't think we
want to create a capability for every possible command.  So it's going to
be of rather limited usefulness.

> RFC 2119 language seems a but too strong there. Perhaps some weaker word
> like "deprecated" would be better (we might "deprecate" INN, but it is
> not going to go away anytime soon, and I would not like to burden it

I'm happy with having the configuration of INN that requires MODE READER
be in violation of a SHOULD.

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