From e1aea37a52ed99ad42cf707716d0827597ed52a1 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Fri, 24 May 2024 14:37:20 +0200 Subject: [PATCH 1/4] Add extended-isupport --- extensions/extended-isupport.md | 93 +++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 extensions/extended-isupport.md diff --git a/extensions/extended-isupport.md b/extensions/extended-isupport.md new file mode 100644 index 00000000..2146a598 --- /dev/null +++ b/extensions/extended-isupport.md @@ -0,0 +1,93 @@ +--- +title: "`extended-isupport` Extension" +layout: spec +copyrights: + - + name: "Simon Ser" + period: "2024" + email: "contact@emersion.fr" +--- + +## Notes for implementing work-in-progress version + +This is a work-in-progress specification. + +Software implementing this work-in-progress specification MUST NOT use the +unprefixed `extended-isupport` capability name. Instead, implementations SHOULD +use the `draft/extended-isupport` capability name to be interoperable with +other software implementing a compatible work-in-progress version. The final +version of the specification will use unprefixed capability names. + +## Introduction + +`RPL_ISUPPORT` is used to advertise metadata about the server as key-value +entries. However, `RPL_ISUPPORT` is only sent by servers after connection +registration. This undermines the usefulness of `RPL_ISUPPORT`: some of the +metadata would be useful to clients prior to connection registration. This +extension adds a mechanism to send `RPL_ISUPPORT` messages before connection +registration, as well as an end of `RPL_ISUPPORT` list indication. + +## Implementation + +### `draft/extended-isupport` capability + +When the `draft/extended-isupport` capability is enabled by the client, the +server MUST send one or more `RPL_ISUPPORT` messages (grouped inside a +`draft/isupport` batch if the `batch` capability is enabled). The capability +MAY be enabled by the client before connection registration completes (ie, +before the client sends `CAP END`, and before the server sends `RPL_WELCOME`). + +Before connection registration completes, while `draft/extended-isupport` is +enabled, the server MAY send updates to the key-value entries via subsequent +`RPL_ISUPPORT` messages (the same way it would after connection registration +completes without this extension). + +The server MAY skip the `RPL_ISUPPORT` replies usually sent when connection +registration completes, if it already sent all information. + +Before connection registration, the server MAY send only a subset of the full +`RPL_ISUPPORT` list. In that case, the server MUST send a `RPL_ISUPPORT` list +when connection registration completes with entries previously omitted. + +If the client enables `draft/extended-isupport` after connection registration, +the server MUST send one or more `RPL_ISUPPORT` messages. If the client +enables, disables and then enables again `draft/extended-isupport` at any time, +the server MUST send one or more `RPL_ISUPPORT` messages. If the client +requests the `draft/extended-isupport` capability while it's already enabled, +the server MUST NOT send any `RPL_ISUPPORT` messages in response. + +### `draft/isupport` batch + +The server MUST group all `RPL_ISUPPORT` messages inside a `draft/isupport` +batch when the [`batch`][] and `draft/extended-isupport` capabilities are +enabled. The server MUST NOT send any unbatched `RPL_ISUPPORT` message while +both of these capabilities are enabled. The order in which the capabilities are +enabled is not significant. + +The batch MUST only contain one or more `RPL_ISUPPORT` messages, it MUST NOT +contain any other message. + +As usual, servers can update or delete existing values by sending additional +`RPL_ISUPPORT` messages in a `draft/isupport` batch after the initial batch. + +## Examples + +Enabling the capability: + + C: CAP LS 302 + S: :irc.example.org CAP * LS :multi-prefix sasl batch draft/extended-isupport + C: CAP REQ batch draft/extended-isupport + S: :irc.example.org CAP * ACK :batch draft/extended-isupport + S: :irc.example.org BATCH +asdf draft/isupport + S: @batch=asdf :irc.example.org 005 * NETWORK=Example NICKLEN=30 FOO=bar + S: :irc.example.org BATCH -asdf + C: NICK emersion + C: USER emersion 0 * :Simon Ser + C: CAP END + S: 001 emersion :어서 오세요 + +Sending a change: + + S: :irc.example.org BATCH +asdf draft/isupport + S: @batch=asdf :irc.example.org 005 * CHANNELLEN=64 NICKLEN=42 -FOO + S: :irc.example.org BATCH -asdf From f46778c4f28a528c5b3a6fe0756c50713fcf2190 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Fri, 2 Aug 2024 18:29:32 +0200 Subject: [PATCH 2/4] fixup! Add extended-isupport --- extensions/extended-isupport.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/extensions/extended-isupport.md b/extensions/extended-isupport.md index 2146a598..60e60c8b 100644 --- a/extensions/extended-isupport.md +++ b/extensions/extended-isupport.md @@ -49,12 +49,11 @@ Before connection registration, the server MAY send only a subset of the full `RPL_ISUPPORT` list. In that case, the server MUST send a `RPL_ISUPPORT` list when connection registration completes with entries previously omitted. -If the client enables `draft/extended-isupport` after connection registration, -the server MUST send one or more `RPL_ISUPPORT` messages. If the client -enables, disables and then enables again `draft/extended-isupport` at any time, -the server MUST send one or more `RPL_ISUPPORT` messages. If the client -requests the `draft/extended-isupport` capability while it's already enabled, -the server MUST NOT send any `RPL_ISUPPORT` messages in response. +The server MUST send one or more `RPL_ISUPPORT` messages when the capability is +enabled, including after connection registration or if the client enables, +disables and then enables again the capability. If the client requests the +`draft/extended-isupport` capability while it's already enabled, the server +MUST NOT send any `RPL_ISUPPORT` messages in response. ### `draft/isupport` batch From cb22ea2271e8973fe561e1bf6539a312b19ae116 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Sun, 4 Aug 2024 15:51:50 +0200 Subject: [PATCH 3/4] fixup! Add extended-isupport --- extensions/extended-isupport.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/extensions/extended-isupport.md b/extensions/extended-isupport.md index 60e60c8b..c79a330f 100644 --- a/extensions/extended-isupport.md +++ b/extensions/extended-isupport.md @@ -50,10 +50,8 @@ Before connection registration, the server MAY send only a subset of the full when connection registration completes with entries previously omitted. The server MUST send one or more `RPL_ISUPPORT` messages when the capability is -enabled, including after connection registration or if the client enables, -disables and then enables again the capability. If the client requests the -`draft/extended-isupport` capability while it's already enabled, the server -MUST NOT send any `RPL_ISUPPORT` messages in response. +enabled, including after connection registration or if the disables then +re-enables the capability. ### `draft/isupport` batch From fe412a0d508a2c88aed111d33606b8d386ec753a Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Thu, 26 Sep 2024 22:38:27 +0200 Subject: [PATCH 4/4] fixup! Add extended-isupport --- extensions/extended-isupport.md | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/extensions/extended-isupport.md b/extensions/extended-isupport.md index c79a330f..3857eda5 100644 --- a/extensions/extended-isupport.md +++ b/extensions/extended-isupport.md @@ -25,17 +25,24 @@ entries. However, `RPL_ISUPPORT` is only sent by servers after connection registration. This undermines the usefulness of `RPL_ISUPPORT`: some of the metadata would be useful to clients prior to connection registration. This extension adds a mechanism to send `RPL_ISUPPORT` messages before connection -registration, as well as an end of `RPL_ISUPPORT` list indication. +registration, as well as a dedicated command to request the `ISUPPORT` list and +a batch for `RPL_ISUPPORT` messages. ## Implementation +### `ISUPPORT` command + +A new `ISUPPORT` command is introduced to request the full `RPL_ISUPPORT` list. +When receiving this command, the server MUST reply with one or more +`RPL_ISUPPORT` messages (grouped inside a `draft/isupport` batch if the `batch` +and `draft/extended-isupport` capabilities are enabled, see below). + ### `draft/extended-isupport` capability When the `draft/extended-isupport` capability is enabled by the client, the -server MUST send one or more `RPL_ISUPPORT` messages (grouped inside a -`draft/isupport` batch if the `batch` capability is enabled). The capability -MAY be enabled by the client before connection registration completes (ie, -before the client sends `CAP END`, and before the server sends `RPL_WELCOME`). +server MUST accept `ISUPPORT` commands before connection registration +completes (ie, before the client sends `CAP END`, and before the server sends +`RPL_WELCOME`). Before connection registration completes, while `draft/extended-isupport` is enabled, the server MAY send updates to the key-value entries via subsequent @@ -49,10 +56,6 @@ Before connection registration, the server MAY send only a subset of the full `RPL_ISUPPORT` list. In that case, the server MUST send a `RPL_ISUPPORT` list when connection registration completes with entries previously omitted. -The server MUST send one or more `RPL_ISUPPORT` messages when the capability is -enabled, including after connection registration or if the disables then -re-enables the capability. - ### `draft/isupport` batch The server MUST group all `RPL_ISUPPORT` messages inside a `draft/isupport` @@ -75,6 +78,7 @@ Enabling the capability: S: :irc.example.org CAP * LS :multi-prefix sasl batch draft/extended-isupport C: CAP REQ batch draft/extended-isupport S: :irc.example.org CAP * ACK :batch draft/extended-isupport + C: ISUPPORT S: :irc.example.org BATCH +asdf draft/isupport S: @batch=asdf :irc.example.org 005 * NETWORK=Example NICKLEN=30 FOO=bar S: :irc.example.org BATCH -asdf