|
| 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-isupportt` 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 followed by a |
| 36 | +`RPL_ENDOFISUPPORT` message. While `draft/extended-isupport` is enabled, the |
| 37 | +server MAY send updates to the key-value entries via subsequent `RPL_ISUPPORT` |
| 38 | +and `RPL_ENDOFISUPPORT` messages. |
| 39 | + |
| 40 | +The server MAY skip the `RPL_ISUPPORT` replies usually sent when connection |
| 41 | +registration completes, if it already sent all information. |
| 42 | + |
| 43 | +Before connection registration, the server MAY send only a subset of the full |
| 44 | +`RPL_ISUPPORT` list. In that case, the server MUST send a `RPL_ISUPPORT` list |
| 45 | +when connection registration completes with entries previously omitted. |
| 46 | + |
| 47 | +### `draft/isupport` batch |
| 48 | + |
| 49 | +If the [`batch`][] capability is enabled, the server MUST group all |
| 50 | +`RPL_ISUPPORT` messages inside a batch. |
| 51 | + |
| 52 | +### `RPL_ENDOFISUPPORT` numeric (370) |
| 53 | + |
| 54 | + :<server> 370 <client> :<info> |
| 55 | + |
| 56 | +This numeric is used to indicate the end of a `RPL_ISUPPORT` list. Servers MUST |
| 57 | +always end any `RPL_ISUPPORT` list with `RPL_ENDOFISUPPORT` when the |
| 58 | +`draft/extended-isupport` capability is enabled. |
| 59 | + |
| 60 | +## Examples |
| 61 | + |
| 62 | +Enabling the capability: |
| 63 | + |
| 64 | + C: CAP LS 302 |
| 65 | + S: :irc.example.org CAP * LS :multi-prefix sasl draft/extended-isupport |
| 66 | + C: CAP REQ draft/extended-isupport |
| 67 | + S: :irc.example.org CAP * ACK draft/extended-isupport |
| 68 | + S: :irc.example.org 005 * NETWORK=Example NICKLEN=30 |
| 69 | + S: :irc.example.org 370 * :End of ISUPPORT list |
| 70 | + |
| 71 | +Sending a change: |
| 72 | + |
| 73 | + S: :irc.example.org 005 * CHANNELLEN=64 -NETWORK |
| 74 | + S: :irc.example.org 370 * :End of ISUPPORT list |
0 commit comments