[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