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

[Clive D.W. Feather]

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.

Thus your example would become:

    [C] CAPABILITIES                         <=== spelling fixed
    [S] 101 Here's what I can do:
    <other entries omitted>
    [S] AUTHINFO SASL                        <=== NOTE SASL
    [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?
    [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
    [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.

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

>>> But what is
>>> wrong with the basic principle of having a consistent way of saying
>>> "extension X wishes to tell you that capability Y isn't currently
>>> available"?
>> This is a pure complexity versus expressiveness tradeoff.  I'm again
>> inclined to go for less complexity and less expressiveness because other
>> protocols do not have this and have not apparently needed it.  I can see
>> the cases where this might be helpful, but in practice I just don't think
>> they're going to be all that useful or important.
> Agreed.  This would add complexity which the most similar protocols 
> don't have and haven't longed for (especially SMTP which also is 
> frequently used unauthenticated), and would possibly inhibit 
> implementation and adoption.  I won't repeat the entire discussion which 
> took place in the other thread, but the arguments still apply.  FWIW, 
> Mark Crispin as a client author is still opposed to this proposal 
> (offline rant omitted).

I'm afraid that both he and you aren't thinking it through. In particular,
the "inhibit implementation and adoption" is nonsense.

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 need to run to catch a train. I hope this has at least made you think a
bit.]

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