[NNTP] Snapshot 4

[Ken Murchison]

Clive D.W. Feather wrote:
> Okay, a fourth snapshot is in the usual place:
>     <http://www.davros.org/nntp-texts/draft25.pre-4.txt>
>     <http://www.davros.org/nntp-texts/draft25.pre-4.html>
> 
> This is the one that has the CAPABILITIES command, version numbers, and so
> on. It is, I hope, the last major organisational change to the document.
> 
> There are a number of outstanding issues; when commenting, please quote the
> reference number [2501] [2502] etc.

General comments:

- I still don't understand the reasoning for the '_' used in the core 
capability tokens.  It makes things look ugly and I don't see any 
technical benefit.  I guess I can live with it except for LIST (see below).


Outstanding issues:

2501:  I personally don't care if an implementation supports more than 
the relevant minimal commands.  However, if this does occur, then we're 
back to a situation of not knowing what commands a server supports. 
Perhaps if a transit-only server also supports NEWNEWS, then it 
advertises "_TRANSIT NEWNEWS".  Likewise if a reader-only server also 
supports IHAVE, then it advertises "_READER IHAVE".

2502:  Per 3.2.1 paragraph 2, it would seem that 500 is the correct 
response for "fails to implement.  I definitely don't think we want to 
use 502 since it has permanent failure connotations (i.e. the closing of 
the connection business).  I'd be happy with 503 however.

2504:  I think 401 is a cleaner solution regardless of other issues.

2505:  I thought we had already decided that all of this "negative 
capability" business was too much.  I'm opposed to this proposal.

2506:  I don't see the point of a new 6xx response.  How would a client 
ever find itself in such a situation?   All existing commands have well 
defined responses, so the client MUST know when to expect a multi-line 
response.  If the client gets an unexpected multi-line response, then it 
probably issued a command that it doesn't support, and gets what it 
deserves.  I'm in favor or removing Appendix A from the draft.


CAPABILTIES:

- Why the specific order?  I can see a possible reason for _VERSION 
being first (in fact _VERSION could almost go in the initial line of the 
response), but I don't see where the order of the others really matters.

- May I suggest 'IMPLEMENTATION' instead of '_SERVER'.  POP3 uses the 
former and seems to be a more descriptive name.

- I disagree with the statement that the _LIST capability "MUST NOT 
include variants defined by extensions".  I discuss this more below.


LIST:

Like Charles, I'd like to see LIST defined in general terms and all of 
the variants (whether mandatory, optional or extension) described within 
this framework.  More specifically, I think the discussion of LIST 
should start with most of the text from 7.6.4.  Perhaps it should be 
defined as more generally as 'LIST [ keyword *( WSP argument ) ]'.  This 
would allow LIST HEADERS and LIST OVERVIEW.FMT to be compliant with the 
syntax.

Then the mandatory variants (ACTIVE and NEWSGROUPS) can be discussed 
within this framework followed by the optional variants (ACTIVE.TIMES 
and DISTRIB.PATS).  Charles suggested that *all* LIST variants should be 
advertised by the _LIST (or hopefully LIST) capability.  I'm open to 
this or continuing to have only the optional and extension variants 
advertised.  I'm fine with either choice.

Regardless, I'd like to see the optional and extension variants use the 
same _LIST (or LIST) capability.  They are all defined under the same 
framework anyways, so having two different capabilities doesn't seem to 
make any sense to me.  If it makes it easier to make the optional 
variants an extension, then I guess I'm in favor of that.


LIST EXTENSIONS:

- So is LIST EXTENSIONS supposed to list *all* extensions or just legacy 
extensions?  How many clients currently use LIST EXTENSIONS, and which 
servers advertise which extensions?

- I don't see any point in LIST EXTENSIONS advertising new extensions, 
especially those defined in this draft (e.g. OVER or HDR).  If a client 
is aware of OVER or HDR as defined in this draft, then they damn well be 
aware of CAPABILITIES.

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