Unicode names have been wanted for a while, and used in experimental implementations as well in certain bouncers integrating with other messaging systems.

This document outlines a method based on RFC 7700 which should represent a reasonable, modern solution for those projects that wish to allow unicode characters and casemap them appropriately.

There's previous discussion around this in #259.

This casemapping does not specify any sort of backwards-compatibility measures. Being compatible with clients and servers that cannot correctly handle unicode has been brought up many times during discussions about unicode casemappings. Below outlines some of the most reasonable suggestions, and why I haven't included them in this specification:

Encoding names so non-rfc7700 servers can accept them

This suggestion revolves around the client encoding nicknames and channel names into currently IRC-friendly characters before it sends them to the server (allowing them to be used on every server out there today). When receiving these encoded names, other unicode-aware clients will decode them to their proper unicode counterpart before displaying them.

Pros

• Unicode nicknames and channel names can be used on servers that don't natively support unicode.
• Non-unicode-aware clients can connect to servers that are unicode-aware.

Cons

• Non-unicode-aware servers will allow nicknames nicknames that look like duplicates, due to the encoding required and the server not being able to enforce the name preperation described above.
• Possible duplication of names by encoding names that contain only irc-friendly characters (or otherwise, strict client-side checking that is likely to be misinterpreted or misimplemented).

Because of the security implications this would bring up, I think this is an extremely bad idea.

Encoding names so that non-unicode-aware clients can accept them

This suggestion revolves around the server encoding nicknames and channel names into currently IRC-friendly characters before it sends them to the client (allowing them to be accepted by every client out there). When receiving these encoded names, unicode-aware clients will decode them into their proper unicode counterpart before displaying them.

Pros

• We can be assured that any client, including ones that can't do unicode, will be able to accept the names.

Cons

• Due to the encoding, these encoded nicknames are not going to be easily readable by non-unicode-aware clients, and are going to appear as a blob of unreadable text.
• Even if we only encode names that contain special characters, that complicates message sending in ways that's likely going to irritate server authors into not implementing this.
• The decoding/encoding required by this (particularly if only certain names are encoded) complicates client programming in ways that is likely to be misimplemented.

I don't think this is required because getting this casemapping widely implemented will take time. By the time this casemapping gets into large enough use to warrant worrying about legacy clients, I think a large majority of the clients currently in use will support unicode names without issues. As well, a number of clients already successfully accept unicode names.

Because of the complexity this process adds and how much I see it as a non-issue at this point this is implemented, I don't think this should happen and believe it's more effort than it's worth I think this measure would just cause more problems than it would solve.