[NNTP] Snapshot 6

Peter Robinson pmrobinson at gmx.net
Sun Jan 9 13:58:15 PST 2005


Clive D.W. Feather <clive at demon.net> wrote:

> Okay, snapshot 6 is available in the usual place

I've not looked at this draft for a while, and I must say I'm very
enthusiastic about the recent work.  A few comments though...

| 3.3.4 Extensions
[...]
| An extension is a package of associated facilities, often but not
| always including one or new commands.

'one or more commands'?
'one or more new commands'?


| 3.3.5 Initial IANA register

The initial registry includes an entry for the generic modifier, -label.
That, combined with 3.3.3, attempts to define a modifier for *every*
capability label, whether it makes sense or not.  [And 'use of the
facility with this capability label' doesn't make sense e.g. for a
capability that doesn't add new commands.]

[in 3.3.3:]
| -label
|   the capability can be enabled by use of the facility with this
|   capability label; in particular, -MODE-READER indicates that the
|   server is a mode-switching server and the capability can be enabled
|   by use of the MODE READER command.

If -label is left in the initial registry as it is, surely that mandates
the server returning all sorts of oddness, and requires a client to make
some kind of sense of it.  E.g.:

VERSION 2
-AUTHINFO READER       [Should be -480 READER.]
-READER OVER           [Which READER command must client send first?]
-HDR XNEWCOMMAND       [Must the client send HDR or LIST HEADERS?]
-IMPLEMENTATION READER [!?]
etc.

I'd take -label out of the initial registry, but keep the wording from
3.3.3 defining what it should mean in general terms, as long as it's
made clear that it's not actually defining any modifiers on it own.

Also, there should probably also be an explicit -MODE-READER entry in
the list in 3.3.3 since it says

| The following such modifiers are defined by this specification:

but includes only -label and not -MODE-READER.


| 5.1.1 [Initial Connection] Usage

Shouldn't this say that it MUST NOT be pipelined?


What was the consensus on whether to make POST, OVER and HDR arguments
to READER or separate capabilities in their own right?  FWIW, I'd rather
make them each independent capabilites, and also require the server to
include the corresponding arguments with the LIST capability as
appropriate.

Peter



More information about the ietf-nntp mailing list