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

Russ Allbery rra at stanford.edu
Tue Nov 30 20:27:51 PST 2004


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.

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

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list