New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate and eventually phase out CAP CLEAR #134

Closed
Elizafox opened this Issue Apr 2, 2015 · 4 comments

Comments

Projects
None yet
5 participants
@Elizafox

Elizafox commented Apr 2, 2015

Hello,

CAP CLEAR is of dubious utility to client authors and of very dubious utility to users. It is not desirable that features be able to be turned off (just do not request CAPs you do not want), and may in fact harm user experience by being in the spec - it just screams "don't push this button" to anyone who comes across reading it. It also is limited in utilty by sticky caps, which cannot be removed once requested.

The only use case that even came up in discussion in #ircv3 was for bouncers - but servers cannot even send CAP CLEAR, making it useless for even this purpose. A well-written bouncer should be able to translate caps, anyway, or mandate them if needs be.

Anecdotally, the only reason I can find that it's even in the spec was apparently because in the past, it was desirable to demonstrate that everything was optional and could be turned off at any time for political reasons. Such political reasons have long since passed, as CAP is now a thing of the present and implemented by most major clients - sans CAP CLEAR in any of them known to me :).

@kaniini

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Apr 2, 2015

Contributor

👍 i have yet to find any client which legitimately sends CAP CLEAR, and of course /quote CAP CLEAR is just begging for trouble.

Contributor

kaniini commented Apr 2, 2015

👍 i have yet to find any client which legitimately sends CAP CLEAR, and of course /quote CAP CLEAR is just begging for trouble.

@SaberUK

This comment has been minimized.

Show comment
Hide comment
@SaberUK

SaberUK Apr 2, 2015

Contributor

👍

Contributor

SaberUK commented Apr 2, 2015

👍

@grawity grawity added the Accepted label Apr 2, 2015

@kaniini

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Apr 25, 2015

Contributor

Lets do this as an errata update against the 3.1 spec. I'll submit a PR in a moment.

Contributor

kaniini commented Apr 25, 2015

Lets do this as an errata update against the 3.1 spec. I'll submit a PR in a moment.

kaniini added a commit to kaniini/ircv3-specifications that referenced this issue Apr 25, 2015

@grawity grawity closed this in #139 Apr 25, 2015

grawity added a commit that referenced this issue Apr 25, 2015

Merge pull request #139 from kaniini/cap-issue-134
core/capability-negotiation-3.1: remove CAP CLEAR text per #134
@janicez

This comment has been minimized.

Show comment
Hide comment
@janicez

janicez May 28, 2017

I'm going to posthumously oppose this motion, as what if something breaks in a non-sticky cap and the user has to turn all of them off to try a process of elimination? CAP CLEAR would save a few bytes.

janicez commented May 28, 2017

I'm going to posthumously oppose this motion, as what if something breaks in a non-sticky cap and the user has to turn all of them off to try a process of elimination? CAP CLEAR would save a few bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment