[NNTP] Snapshot 6

[Peter Robinson]

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

> Peter Robinson said:

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

What I'm saying is that, for each capability, whether it defines a
-label capability modifier, and how to activate it, should be explicitly
stated in the specification for that capability.  And that the wording
about the -label wildcard should be for guidance on how such modifiers
should be defined, and should not define any capability modifiers in
itself.

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

So it does.  I had assumed -AUTHINFO was a bug not a feature.  Are you
expecting clients that do auth via AUTHINFO alone to understand the
-AUTHINFO modifier as commonly as they would -480 from reading this
specification?  And that it's perfectly normal for a server to use
-AUTHINFO not -480?  But I suppose that's a job for the authinfo
document, not this one.

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

If so, I'd say this needs to be stated in the specification for the
READER capability.

> > -HDR XNEWCOMMAND       [Must the client send HDR or LIST HEADERS?]
> 
> See the specification of HDR.

?

Do you mean the single sentence from 3.3.2 defining the commands
provided by the HDR capability, or the definition of the HDR command in
8.5, or somewhere else?  I don't know this document as well as you, so I
may be missing it, but I don't see the answer to that question anywhere.

> > -IMPLEMENTATION READER [!?]
> 
> Hmm.

[...]

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

I didn't imagine that you actually wanted a -label modifier for
essentially every capability!

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

I'm happy with that text.  Does that mean that -MODE-READER is now the
only capability-derived modifier defined by this document?

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

Excellent.

[...]

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

To clarify what I meant:  the document says elsewhere in the text that
it MUST NOT be pipelined, but in that case it's supposed to say so in
the Usage section for the 'command'.

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

OK.

Peter