Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve client nickname syntax description #208

Merged
merged 2 commits into from
Nov 25, 2023

Conversation

tommyrot
Copy link
Contributor

@tommyrot tommyrot commented Mar 28, 2023

Align the text with RFC2812 which has a slightly more relaxed nickname syntax as RFC1459 and is the most commonly used one. I'm unsure why the modern documentation tries to be so loose and unspecific about this syntax considering it already clearly states "Servers MAY have additional implementation-specific nickname restrictions.".

List channel membership prefixes in the nickname as prohibited, and advise server implementations to avoid possible detrimental ambiguity.

Should solve #203

@emersion
Copy link
Contributor

I disagree. This forbids servers and bridges from using some characters which don't cause any issues in clients.

@DanielOaks
Copy link
Member

iirc when I was putting these restrictions together originally I was wary of bridges that allow lots of weird characters and some server impls like plexus that are less restrictive and may also allow weird chars.

A big inspiration for the denied chars here was the... rfc7700? doc submitted to IRCv3, I think it was. That doc that was focused on unicode nicknames and using PRECIS.

- They MUST NOT start with a character listed as a [channel type](#channel-types) prefix.
- They SHOULD NOT contain any dot character `('.', 0x2E)`.
- They MUST NOT start with a character listed as a [channel membership prefix](#channel-membership-prefixes), or prefix listed in the IRCv3 [`multi-prefix` Extension](https://ircv3.net/specs/extensions/multi-prefix).

Servers MAY have additional implementation-specific nickname restrictions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This effectively makes all of the MUST NOT above moot, and allows servers to completely break the protocol.

…dvise server implementations to avoid possible detrimental ambiguity.

Should solve ircdocs#203
@@ -55,9 +55,10 @@ Nicknames are non-empty strings with the following restrictions:
- They MUST NOT contain any of the following characters: space `(' ', 0x20)`, comma `(',', 0x2C)`, asterisk `('*', 0x2A)`, question mark `('?', 0x3F)`, exclamation mark `('!', 0x21)`, at sign `('@', 0x40)`.
- They MUST NOT start with any of the following characters: dollar `('$', 0x24)`, colon `(':', 0x3A)`.
- They MUST NOT start with a character listed as a [channel type](#channel-types) prefix.
- They MUST NOT start with a character listed as a [channel membership prefix](#channel-membership-prefixes), or prefix listed in the IRCv3 [`multi-prefix` Extension](https://ircv3.net/specs/extensions/multi-prefix).
- They SHOULD NOT contain any dot character `('.', 0x2E)`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line should probably be merged into "They MUST NOT contain any of the following characters..."

@progval progval merged commit 00cbf72 into ircdocs:master Nov 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants