Skip to content
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

Explicitly allow CAP NEW to update existing caps #480

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion extensions/capability-negotiation.md
Original file line number Diff line number Diff line change
Expand Up @@ -368,6 +368,8 @@ The NEW subcommand signals that the server supports one or more new capabilities
sent at any time. Clients that support `CAP NEW` messages SHOULD respond with a `CAP REQ`
message if they wish to enable one or more of the newly-offered capabilities.

The NEW subcommand can also update the value of an existing capability.

The format of a `CAP NEW` message is:

CAP <nick> NEW :<extension 1> [<extension 2> ... [<extension n>]]
Expand All @@ -386,6 +388,11 @@ Example with following `REQ`:
Client: CAP REQ :extended-join away-notify
Server: :irc.example.com CAP tester ACK :extended-join away-notify

Example updating an existing capability:

Server: :irc.example.com CAP modernclient NEW :sasl=PLAIN
Server: :irc.example.com CAP modernclient NEW :sasl=PLAIN,EXTERNAL

### The CAP DEL subcommand

The DEL subcommand MUST ONLY be sent to clients that have negotiated CAP version `302` or
Expand Down Expand Up @@ -542,4 +549,7 @@ appropriate features.
Previous versions of this spec did not mention how servers handle clients attempting to downgrade
their CAP LS version. It has been clarified that clients MAY NOT downgrade this.

Clarify that multiline LS and LIST replies must only be used for CAP 302
Clarify that multiline LS and LIST replies must only be used for CAP 302.

Previous versions of this spec didn't explicitly state that `CAP NEW` can update existing
capabilities. This has been clarified and an example has been added.