[NNTP] [2505] CAPABILITIES indication of features not currently available

[Ken Murchison]

Clive D.W. Feather wrote:

> Ken Murchison said:
> 
>>>>In particular, the present SASL stuff is an abomination - advertising a
>>>>capability as available with the secret understanding that that means it
>>>>*isn't* available - and goes directly against a MUST in the core
>>>>specification.
> 
> 
>>In all honesty, the current way that we're handling this *is* kind of 
>>ugly.  I would prefer to go back to listing the SASL mechs on a separate 
>>capability line (like in the original drafts), so that we don't give the 
>>impression that AUTHINFO is still a valid command after authentication. 
> 
> 
> Okay, I've been thinking about this some more.
> 
> Back when it was called LIST EXTENSIONS, there was plenty of reason to say
> "one extension, one line". However, now that it's CAPABILITIES it's
> possible to make a mental shift. Suppose I rewrite the description to say
> that its purpose is to describe capabilities, and these are done one per
> line (see below for more on this). In most cases an extension would be a
> single capability, but in exceptional situations it can have more than one.
> 
> Now the AUTHINFO extension becomes such an exceptional situation: it
> defines *two* capabilities:
> 
> (1) The AUTHINFO capability says which AUTHINFO commands are allowed at the
> moment. If none are (including when authentication is complete), then this
> capability isn't listed.
> 
> (2) The SASL capability says which SASL mechanisms are understood by the
> server. This is listed at all times, even if AUTHINFO currently isn't.

Yes.  The is exactly what the AUTHINFO document used to have.


> Thus your example would become:
> 
>     [C] CAPABILITIES                         <=== spelling fixed

Or possibly "LIST CAPABILITIES".


>     [S] 101 Here's what I can do:
>     <other entries omitted>
>     [S] AUTHINFO SASL                        <=== NOTE SASL

The SASL argument to AUTHINFO is redundant given the SASL capability, 
but I won't fight it.


>     [S] SASL DIGEST-MD5 GSSAPI
>     [S] STARTTLS
>     [S] .
>     [C] STARTTLS
>     <TLS negotiation here>
>     [C] CAPABILITIES
>     [S] 101 Here's what I can do after TLS:
>     <other entries omitted>
>     [S] AUTHINFO SASL USER                   <=== NOTE SASL
>     [S] SASL DIGEST-MD5 GSSAPI PLAIN
>     [S] .
>     [C] AUTHINFO PLAIN xxxxx                 <=== AUTHINFO SASL PLAIN surely?

Yup.  My mistake.


>     [S] 281 Authentication successful
>     [C] CAPABILITIES
>     [S] 101 Here's what I can do after auth:
>     <other entries omitted>
>     [S] SASL DIGEST-MD5 GSSAPI PLAIN         <=== AUTHINFO now omitted

Correct.


>     [S] .
> 
> The same output would be produced if AUTHINFO USER had been used instead;
> you still list the SASL capability.
> 
> If you are happy with this, then let's go that way.

Yes, I'm fine with this.  I'll resurrect the old text.


> I would like you to think about SASL methods that are unavailable before
> encryption. Consider a client that can only do SASL PLAIN (or some other
> method that requires TLS in place). At present, it has no way to find out
> whether or not it's worth going through the effort of doing TLS; the only
> way to see whether PLAIN is going to appear is to actually try it.

Since NNTP *requires* PLAIN to be protected by some type of privacy 
layer, any client will know that if it wants to use it, it probably 
needs to do STARTTLS (or XENCRYPT or whatever) before it will be 
available.  The same is true for AUTHINFO USER.


> Now
> we're trying to get *away* from the suck-it-and-see school of protocol
> design.  So I would suggest that the SASL capability should indicate what
> will be available once a privacy layer is in place. This could be via
> specific flags:
> 
>     [C] CAPABILITIES
>     [S] 101 Here's what I can do:
>     <other entries omitted>
>     [S] AUTHINFO SASL
>     [S] SASL DIGEST-MD5 GSSAPI -PLAIN
>     [S] STARTTLS
>     [S] .
> 
> or it could use my generic facility:
> 
>     [C] CAPABILITIES
>     [S] 101 Here's what I can do:
>     <other entries omitted>
>     [S] AUTHINFO SASL
>     [S] SASL DIGEST-MD5 GSSAPI
>     [S] - SASL PLAIN
>     [S] STARTTLS
>     [S] .
> 
> But I suggest it goes against our own principles not to provide the
> information at all.

I agree in principle, but I think in this case its unneeded, as the link 
between PLAIN and TLS is clear.


> I was very careful when writing the proposal to set the bar low. Using the
> wording I proposed in 25.pre-4:
> 
> * A server DOES NOT HAVE TO DO ANYTHING WHATSOEVER to conform. I wrote
>   "A server MAY provide an indication ...". Note that keyword: MAY.
> 
> * A client has to do exactly one thing to conform: it has to NOT barf when
>   it sees a capability line beginning with a hyphen. Instead, it needs to
>   ignore it, just like it has to ignore one that begins with a keyword that
>   it doesn't recognise. Is this really a hard thing to implement?
> 
> Under this proposal, a server that wants to be helpful to clients *MAY*
> provide this extra information. And a client that wants to be more
> efficient *MAY* parse these extra lines. But this doesn't put a burden on
> those who don't want to.
> 
> 
> Having got that off my chest a bit, let me try to explain my vision for the
> CAPABILITIES command. What I'm suggesting is that each line of the response
> consists of:
> 
>     [flags ...] name [arguments ...]
> 
> and the general rules are:
> 
> * The name tells us which capability we're talking about. It's the primary
>   key for interpreting the line.
> * All capability names begin with a letter. So if it doesn't begin with a
>   letter, it's a flag.
> * Arguments are capability-specific.
> * Flags have a global meaning; once a version of the NNTP specification
>   defines a flag, it applies to all capabilities.
> * If a client doesn't understand a flag, it MUST ignore any line
>   beginning with that flag.
> 
> This gives us a structure for future expansion without having to worry
> about compatibility. The only imposition it makes is the last bullet point:
> if a client doesn't understand a flag, it MUST ignore it (just like it
> MUST ignore any extension it doesn't understand).
> 
> The "not available now, but could be" thing is then just one such flag.

I'm not opposed to your proposal in principle, I just don't think its 
necessary right now.  We're already having enough trouble getting what 
we have out the door, and I don't think we need to spend more time 
figuring out what might be needed down the road.  As long as we don't 
paint ourselved into a corner with the current draft, this facility can 
always be added at a later time, when a more compelling need is discovered.

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