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

[Ken Murchison]

Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> 
> 
>>Issue: do we provide a way for CAPABILITIES to advertise features that
>>aren't available right now but could be, or have been.
> 
> 
>>Ken Murchison said:
>>
>>>2505:  I thought we had already decided that all of this "negative 
>>>capability" business was too much.  I'm opposed to this proposal.
> 
> 
>>It came back again in at least one of Russ's messages.
> 
> 
>>The reason for proposing it is that it addresses a number of issues:
>>* advertising "can only authenticate after TLS", "can do more SASL options
>>  with TLS", "can only authenticate after MODE READER", and so on;
>>* indicating the authentication methods that were available after
>>  successful SASL;
>>* indicating that the server is mode-switching;
>>and so on. Now we can come up with ad-hoc solutions for each of those, but
>>isn't it better to have a framework for it?
> 
> 
>>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.
> 
> 
> I'm not particularly worried about the SASL case because this is what
> everyone else does too.  To me, that makes it not an abomination; no
> matter what else one might think about it, it has the significant
> advantage of cross-protocol consistency, and a lot of implementors write
> multi-protocol clients.

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. 
  For example:

[C] CAPABILTIES
[S] 101 Here's what I can do:
[S] NNTPv2
[S] TRANSIT
[S] AUTHINFO
[S] SASL DIGEST-MD5 GSSAPI
[S] STARTTLS
[S] .
[C] STARTTLS
<TLS negotiation here>
[C] CAPABILTIES
[S] 101 Here's what I can do after TLS:
[S] NNTPv2
[S] TRANSIT
[S] AUTHINFO USER
[S] SASL DIGEST-MD5 GSSAPI PLAIN
[S] .
[C] AUTHINFO PLAIN xxxxx
[S] 281 Authentication successful
[C] CAPABILTIES
[S] 101 Here's what I can do after auth:
[S] NNTPv2
[S] TRANSIT
[S] READER
[S] OVER
[S] HDR
[S] SASL DIGEST-MD5 GSSAPI PLAIN
[S] .


> 
> 
>>What is the objection to this? If it's the detail of the "-", "--",
>>"-480" stuff, then I'm happy to amend or drop that part. 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).

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