Add document for Unicode casemapping

documentation/rfc7700.md

@@ -0,0 +1,151 @@
+---
+title: rfc7700 IRC Casemapping
+layout: spec
+copyrights:
+  -
+    name: "Daniel Oaks"
+    period: "2016"
+    email: "daniel@danieloaks.net"
+---
+This document describes a unicode-aware casemapping for IRC, based on the recommendations in [RFC 7700](https://tools.ietf.org/html/rfc7700).
+
+Client and channel names in languages other than English is a much-desired feature. This casemapping allows for an extended set of characters while minimising the risks around allowing these characters, and avoiding the technical limitations of prior solutions to this problem.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119](http://tools.ietf.org/html/rfc2119).
+
+
+## Casemapping
+
+The server indicates that this casemapping is in use by advertising the `"CASEMAPPING"` `RPL_ISUPPORT` parameter with the value `"rfc7700"`. An example of this is shown below:
+
+    :irc.example.com 005 dan CASEMAPPING=rfc7700 :are supported by this server"
+
+When the `rfc7700` casemapping is in use, names (and other messages from the IRCd where possible) MUST be sent using the [UTF-8](https://tools.ietf.org/html/rfc3629) encoding.
+
+The `rfc7700` casemapping uses the PRECIS [Nickname profile](https://tools.ietf.org/html/rfc7700#section-2) as defined in [Section 2 of RFC 7700](https://tools.ietf.org/html/rfc7700#section-2).
+
+
+### Order of Operations
+
+Names being prepared MUST apply the following rules in the order shown:
+
+1. Preperation using the PRECIS [Nickname profile](https://tools.ietf.org/html/rfc7700#section-2).
+2. Check for restricted characters.
+
+These steps MUST happen in the order shown, or else the restricted characters check may miss characters that should be legitimately restricted.
+
+If a name does contain a restricted character (whether disallowed by the [Nickname profile](https://tools.ietf.org/html/rfc7700#section-2.2) or this document), it MUST be rejected by the server and MUST NOT be propogated to other clients. This is done through the appropriate numeric for the command which tried to set or use the invalid name such as `ERR_ERRONEUSNICKNAME`, `ERR_NOSUCHCHANNEL`, or whichever numeric is most appropriate.
+
+
+### Comparisons
+
+When comparing user names or channel names to check for equivalency, both strings are casemapped with the above process. After this, they are compared with a standard bit-for-bit comparison.
+
+
+## Restricted Characters
+
+Certain characters mean special things to the protocol. This section details characters that are not allowed in specific name types.
+
+
+### All Names
+
+Nicknames, usernames, hostnames and channel names cannot contain the following characters:
+
+* `(' ', 0x20)` - Separates parameters.
+* `(':', 0x3A)` - Separates trailing parameter.
+* `(',', 0x2C)` - Used as a separator.
+* `('*', 0x2A)` - Used in mask matching.
+* `('?', 0x3F)` - Used in mask matching.
+
+To be clear, these characters will also be repeated below.
+
+#### Protocol Framing
+
+These characters are disallowed either by the protocol itself or because of how they are used in protocol framing. These won't be repeated below, as sane implementations either break the message on or disallow the character in streams:
+
+* `('\0', 0x00)` - Disallowed by the protocol.
+* `('\n', 0x0A)` - Used in message framing.
+* `('\r', 0x0D)` - Used in message framing.
+
+
+### Nicknames
+
+Nicknames cannot contain the following characters:
+
+* `(' ', 0x20)` - Separates parameters.
+* `(':', 0x3A)` - Separates trailing parameter.
+* `(',', 0x2C)` - Used as a separator.
+* `('*', 0x2A)` - Used in mask matching.
+* `('?', 0x3F)` - Used in mask matching.
+* `('.', 0x2E)` - Denotes a server name.
+* `('!', 0x21)` - Separates username from hostname.
+* `('@', 0x40)` - Separates username from hostname.
+
+In addition to the above restrictions, the first character of a nickname cannot be:
+
+* `('-', 0x2D)` - Disallowed.
+* `('0', 0x30)` - Disallowed.
+* `('1', 0x31)` - Disallowed.
+* `('2', 0x32)` - Disallowed.
+* `('3', 0x33)` - Disallowed.
+* `('4', 0x34)` - Disallowed.
+* `('5', 0x35)` - Disallowed.
+* `('6', 0x36)` - Disallowed.
+* `('7', 0x37)` - Disallowed.
+* `('8', 0x38)` - Disallowed.
+* `('9', 0x39)` - Disallowed.
+* Channel membership prefixes as defined in the `PREFIX` parameter of `RPL_ISUPPORT` - Protocol conflicts.
+* Channel prefixes as defined in the `CHANTYPES` parameter of `RPL_ISUPPORT` - Protocol conflicts.
+
+
+### Usernames
+
+Usernames cannot contain the following characters:
+
+* `(' ', 0x20)` - Separates parameters.
+* `(':', 0x3A)` - Separates trailing parameter.
+* `(',', 0x2C)` - Used as a separator.
+* `('*', 0x2A)` - Used in mask matching.
+* `('?', 0x3F)` - Used in mask matching.
+* `('!', 0x21)` - Separates username from hostname.
+* `('@', 0x40)` - Separates username from hostname.
+
+
+### Hostnames
+
+Hostnames cannot contain the following charactes:
+
+* `(' ', 0x20)` - Separates parameters.
+* `(':', 0x3A)` - Separates trailing parameter.
+* `(',', 0x2C)` - Used as a separator.
+* `('*', 0x2A)` - Used in mask matching.
+* `('?', 0x3F)` - Used in mask matching.
+* `('!', 0x21)` - Separates username from hostname.
+* `('@', 0x40)` - Separates username from hostname.
+
+Hostnames that are looked up on client connection should also be checked with the traditional hostname rules to ensure it is valid.
+
+
+### Channel Names
+
+Channel names must start with a channel prefix as defined in the `CHANTYPES` parameter of `RPL_ISUPPORT` (005).
+
+Channel names cannot contain the following characters:
+
+* `(' ', 0x20)` - Separates parameters.
+* `(',', 0x2C)` - Used as a separator.
+* `('*', 0x2A)` - Used in mask matching.
+* `('?', 0x3F)` - Used in mask matching.
+
+
+## Security Considerations
+
+New unicode-capable casemappings have a considerable security impact.
+
+With the large numbers of new characters allowed comes the risk of introducing confusion for users. The PRECIS framework (much like the earlier framework [stringprep](https://tools.ietf.org/html/rfc3454)) aims to avoid this through mapping confusable characters to a single base character, and by allowing specific known-good characters.
+
+The PRECIS framework represents the most modern standardized solution today for doing this sort of mapping and handling of internationalized names, and should mitigate most of the issues around this.
+
+Another issue with allowing such a wide range of characters is the ability for those new characters to break the protocol. The section in this document regarding Restricted Characters aims to prevent this from being an issue.
+
+Legacy clients may have issues working correctly with unicode names. It is acknowledged that issues may exist around this, and in particular it is very difficult to understand how clients may react to unicode names given the very vast base of clients out there today. I do not attempt to address this concern within this document.