[NNTP] Capability modifiers

[Ken Murchison]

Clive D.W. Feather wrote:

> Okay, this remains the one contentious issue. I'd like us to get it closed
> off because we'd all like to see the draft out.
> 
> I initially proposed them so that we wouldn't get stuck if we ever need to
> extend the syntax of capabilities. The minimal requirements are:
> * servers: none.
> * clients: MAY completely ignore lines with modifiers completely,
>            MUST NOT crash.
> 
> I then proposed the modifiers beginning with dash to mean "not available
> for reason X":
> 
>   --      cannot be re-enabled
>   -480    requires authentication
>   -483    requires privacy protection
>   -label  requires something related to the capability with that label
> 
> Other people suggested some wording and concept cleanups; in particular,
> two modifiers on a line is an "and" while multiple lines is an "or".
> 
> -MODE-READER is seeing actual use elsewhere in the draft; specifically
>     -MODE-READER READER
> indicates that reader commands will be available after MODE READER.
> 
> Russ sees little or no point in the concept and, more specifically, the
> -480 and -483 cases. If I'm understanding his point, he's saying that
> authentication or privacy setup might fail anyway (e.g. wrong credentials
> for the desired operation) and so these provide little or no information
> except in edge cases.
> 
> I'm not sure where we go from here.
> 
> If we remove modifiers entirely, we still want to say *something* about
> extensibility of the CAPABILITIES syntax, and we still need something to
> replace the -MODE-READER modifier in particular.

I don't see why either of these are required.  If we need to extend the 
CAPABILTIES response syntax in the future, this can be done with a new 
VERSION 3 response.  As far as -MODE-READER, I don't see its value.  A 
mode-switching server will be advertising MODE-READER and the client 
will know that its required before it can use any reader commands.


> So, some questions for people:
> 
> * Is the modifier *concept* worth retaining as a hook for syntax extension?

I've never been in favor of it, but won't fight it as long as its 
complexity doesn't hinder implementation and/or deployment.

I realize that I've been pushing hard for a client to gleen everything 
possible from CAPABILITIES, but not at the expense of additional 
syntactic sugar.  I think we're at that 80/20 place where the current 
CAPABILITIES gives us 80% of what a client needs.  The modifiers *may* 
get us the remaining 20%, but adds more complexity to the client to sift 
through what the server is telling it.


> If not, how do we address that?

Still not convinced that a mechanism for extending the syntax is required.


> * Is the -- modifier useful as a documentation technique?

I really don't see its value.  It really only applies to STARTTLS after 
TLS/auth, to AUTHINFO after auth and to reader commands after MODE 
READER, all of which is documented behavior.  What's the point of 
telling the client something that it should already know?


> * Is the -label modifier useful for interrelated capabilities?

Possibly.


> * Are the -480 and -483 modifiers useful for indicating what is and
> isn't available with and without security and privacy?

Possibly.


> * If we remove modifiers, what do we do about -MODE-READER?

Not convinced we need a replacement.

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