[NNTP] Snapshot 6

Clive D.W. Feather clive at demon.net
Tue Jan 11 02:42:12 PST 2005


Peter Robinson said:
> | always including one or new commands.
> 'one or more commands'?
> 'one or more new commands'?

The latter. Good catch.

> | 3.3.5 Initial IANA register
> 
> The initial registry includes an entry for the generic modifier, -label.

That's right. Registration of a capability label automatically defines the
modifier as well.

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

It might do. For example, a "named article" extension could add "name"
to the syntax for article-ref and range-ref, but not add any new commands.
Okay, I can't see why some other feature might be conditional on using
named commands, but there's no reason to rule it out a priori.

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

It *permits* all sorts of oddness, but the client is ALWAYS allowed to
ignore it.

> VERSION 2
> -AUTHINFO READER       [Should be -480 READER.]

Actually there is a subtle difference: -480 is more inclusive than -AUTHINFO.

> -READER OVER           [Which READER command must client send first?]

Any of them?

> -HDR XNEWCOMMAND       [Must the client send HDR or LIST HEADERS?]

See the specification of HDR.

> -IMPLEMENTATION READER [!?]

Hmm.

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

You've convinced me that there's a problem, but I'm not convinced you've
provided the right fix. In particular, I don't want to have to have
everything registered twice.

Okay, the text has been changed to:

    -label   the capability can be enabled by use of the facility with
             this capability label; the server MUST NOT use this modifier
             except as specified by the definition of the latter
             capability.

and the -MODE-READER wording taken to a separate paragraph.

Similar wording change made to the 401 response code, which has the same
issue.

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

MODE-READER *is* a label.

> | 5.1.1 [Initial Connection] Usage
> 
> Shouldn't this say that it MUST NOT be pipelined?

I suppose it wouldn't hurt.

> What was the consensus on whether to make POST, OVER and HDR arguments
> to READER or separate capabilities in their own right?

It was decided to make POST and LISTGROUP arguments to READER, but leave
OVER and HDR separate.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list