[NNTP] Snapshot 2 and straw poll

[Charles Lindsey]

In <20041118084717.GB17337 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:

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

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: chl at clerew.man.ac.uk      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