|
| 1 | +--- |
| 2 | +title: "`extended-isupport` Extension" |
| 3 | +layout: spec |
| 4 | +copyrights: |
| 5 | + - |
| 6 | + name: "Simon Ser" |
| 7 | + period: "2024" |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## Notes for implementing work-in-progress version |
| 12 | + |
| 13 | +This is a work-in-progress specification. |
| 14 | + |
| 15 | +Software implementing this work-in-progress specification MUST NOT use the |
| 16 | +unprefixed `extended-isupport` capability name. Instead, implementations SHOULD |
| 17 | +use the `draft/extended-isupport` capability name to be interoperable with |
| 18 | +other software implementing a compatible work-in-progress version. The final |
| 19 | +version of the specification will use unprefixed capability names. |
| 20 | + |
| 21 | +## Introduction |
| 22 | + |
| 23 | +`RPL_ISUPPORT` is used to advertise metadata about the server as key-value |
| 24 | +entries. However, `RPL_ISUPPORT` is only sent by servers after connection |
| 25 | +registration. This undermines the usefulness of `RPL_ISUPPORT`: some of the |
| 26 | +metadata would be useful to clients prior to connection registration. This |
| 27 | +extension adds a mechanism to send `RPL_ISUPPORT` messages before connection |
| 28 | +registration, as well as an end of `RPL_ISUPPORT` list indication. |
| 29 | + |
| 30 | +## Implementation |
| 31 | + |
| 32 | +### `draft/extended-isupport` capability |
| 33 | + |
| 34 | +When the `draft/extended-isupport` capability is enabled by the client, the |
| 35 | +server MUST send one or more `RPL_ISUPPORT` messages (grouped inside a |
| 36 | +`draft/isupport` batch if the `batch` capability is enabled). The capability |
| 37 | +MAY be enabled by the client before connection registration completes (ie, |
| 38 | +before the client sends `CAP END`, and before the server sends `RPL_WELCOME`). |
| 39 | + |
| 40 | +Before connection registration completes, while `draft/extended-isupport` is |
| 41 | +enabled, the server MAY send updates to the key-value entries via subsequent |
| 42 | +`RPL_ISUPPORT` messages (the same way it would after connection registration |
| 43 | +completes without this extension). |
| 44 | + |
| 45 | +The server MAY skip the `RPL_ISUPPORT` replies usually sent when connection |
| 46 | +registration completes, if it already sent all information. |
| 47 | + |
| 48 | +Before connection registration, the server MAY send only a subset of the full |
| 49 | +`RPL_ISUPPORT` list. In that case, the server MUST send a `RPL_ISUPPORT` list |
| 50 | +when connection registration completes with entries previously omitted. |
| 51 | + |
| 52 | +If the client enables `draft/extended-isupport` after connection registration, |
| 53 | +the server MUST send one or more `RPL_ISUPPORT` messages. If the client |
| 54 | +enables, disables and then enables again `draft/extended-isupport` at any time, |
| 55 | +the server MUST send one or more `RPL_ISUPPORT` messages. If the client |
| 56 | +requests the `draft/extended-isupport` capability while it's already enabled, |
| 57 | +the server MUST NOT send any `RPL_ISUPPORT` messages in response. |
| 58 | + |
| 59 | +### `draft/isupport` batch |
| 60 | + |
| 61 | +The server MUST group all `RPL_ISUPPORT` messages inside a `draft/isupport` |
| 62 | +batch when the [`batch`][] and `draft/extended-isupport` capabilities are |
| 63 | +enabled. The server MUST NOT send any unbatched `RPL_ISUPPORT` message while |
| 64 | +both of these capabilities are enabled. The order in which the capabilities are |
| 65 | +enabled is not significant. |
| 66 | + |
| 67 | +The batch MUST only contain one or more `RPL_ISUPPORT` messages, it MUST NOT |
| 68 | +contain any other message. |
| 69 | + |
| 70 | +As usual, servers can update or delete existing values by sending additional |
| 71 | +`RPL_ISUPPORT` messages in a `draft/isupport` batch after the initial batch. |
| 72 | + |
| 73 | +## Examples |
| 74 | + |
| 75 | +Enabling the capability: |
| 76 | + |
| 77 | + C: CAP LS 302 |
| 78 | + S: :irc.example.org CAP * LS :multi-prefix sasl batch draft/extended-isupport |
| 79 | + C: CAP REQ batch draft/extended-isupport |
| 80 | + S: :irc.example.org CAP * ACK :batch draft/extended-isupport |
| 81 | + S: :irc.example.org BATCH +asdf draft/isupport |
| 82 | + S: @batch=asdf :irc.example.org 005 * NETWORK=Example NICKLEN=30 FOO=bar |
| 83 | + S: :irc.example.org BATCH -asdf |
| 84 | + C: NICK emersion |
| 85 | + C: USER emersion 0 * :Simon Ser |
| 86 | + C: CAP END |
| 87 | + S: 001 emersion :어서 오세요 |
| 88 | + |
| 89 | +Sending a change: |
| 90 | + |
| 91 | + S: :irc.example.org BATCH +asdf draft/isupport |
| 92 | + S: @batch=asdf :irc.example.org 005 * CHANNELLEN=64 NICKLEN=42 -FOO |
| 93 | + S: :irc.example.org BATCH -asdf |
0 commit comments