irctest.server_tests.cap

Test CAP LIST and removal of caps via CAP REQ :-tagname.

“If no capabilities are active, an empty parameter must be sent.”

-- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-list-subcommand>

“If no capabilities are active, an empty parameter must be sent.”

-- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-list-subcommand>

Current version:

"The LS subcommand is used to list the capabilities supported by the server. The client should send an LS subcommand with no other arguments to solicit a list of all capabilities."

"If a client has not indicated support for CAP LS 302 features, the server MUST NOT send these new features to the client." -- <https://ircv3.net/specs/core/capability-negotiation.html>

Before the v3.1 / v3.2 merge:

IRCv3.1: “The LS subcommand is used to list the capabilities supported by the server. The client should send an LS subcommand with no other arguments to solicit a list of all capabilities.” -- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-ls-subcommand>

IRCv3.2: “Servers MUST NOT send messages described by this document if the client only supports version 3.1.” -- <http://ircv3.net/specs/core/capability-negotiation-3.2.html#version-in-cap-ls>

“The argument of the NAK subcommand MUST consist of at least the

first 100 characters of the capability list in the REQ subcommand which triggered the NAK.” -- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-nak-subcommand>

“The capability identifier set must be accepted as a whole, or

rejected entirely.” -- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-req-subcommand>

Current version: "If the client supports CAP version 302, the server MAY send multiple lines in response to CAP LS and CAP LIST." This should be read as disallowing multiline responses to pre-302 clients. -- <https://ircv3.net/specs/extensions/capability-negotiation#multiline-replies-to-cap-ls-and-cap-list>

Test the server handles gracefully clients which do not send

REQs.

“Clients that support capabilities but do not wish to enter negotiation SHOULD send CAP END upon connection to the server.” -- <http://ircv3.net/specs/core/capability-negotiation-3.1.html#the-cap-end-subcommand>

Tests requesting a single capability

Tests requesting two capabilities in different messages

Tests requesting more capabilities after CAP END

Tests requesting two capabilities at once

Test the server handles gracefully clients which request

capabilities that are not available. <http://ircv3.net/specs/core/capability-negotiation-3.1.html>