Clarify that the WHOX reply RPL_WHOSPCRPL may contain multiple prefixes even without the multi-prefix capability#546
Conversation
…es even without the multi-prefix capability
|
Perhaps it should say that clients SHOULD handle this but servers SHOULD NOT emit it? |
| server doesn't support op levels, for instance `n/a`. | ||
|
|
||
| Servers MAY return multiple or all applicable prefixes in the `[flags]` (`f`) | ||
| field, regardless of whether [`multi-prefix`](multi-prefix.html) is enabled. |
There was a problem hiding this comment.
this should link to multi-prefix.md and the site generator will rewrite it
There was a problem hiding this comment.
Hmm, this would be the only .md link in the repository. I based this link on what I found in other documents, which all use .html, e.g. in extensions/echo-message.md or extensions/extended-monitor.md.
|
@SadieCat I'm not sure about that. Both the ircd that invented WHOX (ircu) and at least one modern ircd (Solanum) do emit them – and have been doing so for over 23 years in the case of ircu. I'm sure a significant number of clients (including older or obscure ones without |
|
I agree that this is a gap in documentation that would be beneficial to document- I don't think we at Eggdrop are fully handling multiple flags being sent because of our perhaps outdated assumptions and a lack of explicit definition telling us otherwise. I defer to others to agree how WHOX should perform, but my personal opinion is that "WHOX flags are sent the same way WHO flags are sent" makes sense, which allows the negotiation of multi-prefix to dictate whether those WHO flags are sent in full or in part. |
For historical context: ircu first introduced WHOX in version 2.10.01 and appears to have originally only returned the highest prefix like regular WHO (verified in version 2.10.08.01). UndernetIRC/ircu2@7ec4144 introduced returning all prefixes and was first released in version 2.10.11. Charybdis adopted this behaviour from the first version that implemented WHOX support (3.1, commits charybdis-ircd/charybdis@48957a4 and charybdis-ircd/charybdis@02eca3f). I haven't inspected other ircds. Since both behaviours exist in released ircds, the wording is intentionally vague.