Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
obsoleted by
- rfc-8266 — Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
Extracted elements (21)
NFKC is chosen over other normalization forms because it is more aggressive—performing both canonical and compatibility decomposition—thereby increasing the number of character sequences that match and reducing user confusion (e.g., Roman numeral IV matching 'IV').
No directionality rule (such as the Bidi Rule from RFC 5893) is applied to nicknames, because it is acceptable for a nickname to render differently in right-to-left versus left-to-right layout systems, provided presentation is consistent within any given layout system.
No width-mapping rule is defined because width mapping is subsumed by the NFKC normalization step; an explicit separate rule would be redundant.
The Case Mapping Rule is applied during comparison but not during enforcement alone, allowing applications to store nicknames in their original case while still enabling case-insensitive matching when comparing.
Application protocols may layer additional rules atop this profile, such as minimum/maximum nickname length, further character restrictions, safeguards for visually similar characters, reserved nickname handling, and authorization requirements.
Entities enforcing the Nickname profile are encouraged to be liberal in acceptance: first attempt to map characters (width, additional, case, normalization) and accept the result; only reject strings when a character is disallowed by FreeformClass and cannot be mapped.
This specification defines only the PRECIS-based processing rules. Application protocols (MSRP, XCON, XMPP, etc.) are responsible for specifying which protocol slots accept nicknames, which entities enforce the rules, and when in processing the rules are enforced.
After enforcement, the entity MUST ensure that the resulting nickname is not zero bytes in length. This check is performed after applying rules because an initially non-empty internationalized string may canonicalize to zero length.
An entity performing comparison MUST prepare each string per Section 2.2 and apply the Additional Mapping Rule, Case Mapping Rule, Normalization Rule, and Directionality Rule in that order. Two strings are equivalent if and only if they are an exact octet-for-octet match.
An entity performing enforcement MUST first prepare the string per Section 2.2 and then apply the Additional Mapping Rule, Normalization Rule, and Directionality Rule in that order.
An entity preparing a nickname string MUST ensure the string consists only of Unicode code points conforming to the PRECIS FreeformClass (RFC 7564) and MUST ensure the string is encoded as UTF-8 (RFC 3629).
Any instance of a non-ASCII space character (any Unicode code point with general category 'Zs', except U+0020) MUST be mapped to the ASCII space character U+0020 during the Additional Mapping Rule.
ASCII space characters at the beginning or end of a nickname MUST be removed (e.g., 'stpeter ' becomes 'stpeter'). Interior sequences of more than one ASCII space MUST be mapped to a single ASCII space (e.g., 'St Peter' becomes 'St Peter').
The string MUST be normalized using Unicode NFKC. NFKC performs both canonical and compatibility decomposition before recomposing, so that characters such as U+2163 ROMAN NUMERAL FOUR match the combination of U+0049 and U+0056.
Unicode Default Case Folding MUST be applied as defined in the Unicode Standard. This ensures nicknames differing only by case (e.g., 'stpeter' vs. 'StPeter') are treated as equivalent during comparison.
The Nickname profile is defined as a profile of the PRECIS FreeformClass, specifying rules for preparation, enforcement, and comparison of internationalized nickname strings used in messaging, conferencing, and petname contexts.
IANA adds a 'Nickname' entry to the PRECIS Profiles Registry with Base Class FreeformClass, no width-mapping rule (handled by NFKC), the specified additional mapping and case mapping rules, NFKC normalization, no directionality rule, and enforcement deferred to applications.
The security considerations of RFC 7564 (PRECIS Framework) apply to the FreeformClass used for nicknames, including risks from the broad character repertoire admitted by FreeformClass.
The security considerations of Unicode Technical Standard #39 (Unicode Security Mechanisms) apply to the use of Unicode characters in nicknames, covering issues such as homograph attacks and confusable character abuse.
Visually similar ('confusable') characters pose a security risk in nicknames. While the mapping rules reduce some confusion (e.g., via case folding and NFKC), this document does not provide comprehensive recommendations for handling confusables; implementors should consult UTS #39 for more detailed guidance.
The Nickname profile defines three distinct processing operations in sequence: Preparation (validate FreeformClass membership and UTF-8 encoding), Enforcement (apply Additional Mapping → Normalization → Directionality, then check non-zero length), and Comparison (apply Additional Mapping → Case Mapping → Normalization → Directionality, then octet-for-octet equality check).