[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