[NNTP] Snapshot 4
Ken Murchison
ken at oceana.com
Fri Nov 26 12:33:33 PST 2004
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
More information about the ietf-nntp
mailing list