Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
obsoletes
- rfc-7700 — Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
Extracted elements (22)
NFKC normalization is chosen because it is more aggressive than other normalization forms, performing both canonical and compatibility decomposition before recomposing, thereby increasing the number of code points that would match (e.g., ROMAN NUMERAL FOUR U+2163 matches 'IV').
Non-ASCII space characters (Unicode general category 'Zs') are mapped to ASCII SPACE (U+0020) to prevent confusion, since many non-ASCII space code points are difficult to reproduce across different input methods.
The directionality rule was removed from Sections 2.3 and 2.4 (enforcement and comparison) relative to RFC 7700 in order to address Erratum 4570 and align with updated PRECIS framework guidance.
The Unicode toLowerCase() operation replaced toCaseFold() (used in RFC 7700) following working group discussions and updates to RFC 8264; toLowerCase() is less aggressive and avoids unintended cross-script conflation.
There is no directionality rule for nicknames because it is acceptable for a given nickname to be presented differently in right-to-left versus left-to-right layout systems; the Bidi Rule is inapplicable here.
There is no explicit width mapping rule in the Nickname profile because width mapping is subsumed by NFKC normalization, which performs both canonical and compatibility decomposition before recomposing code points.
Erratum 4570 against RFC 7700 was addressed in this document by removing the directionality rule from the enforcement and comparison sections; the original RFC 7700 incorrectly included a directionality rule for nicknames.
Applying the Nickname profile rules is not an idempotent procedure for all code points; for example, applying toLowerCase then NFKC to U+03D4 (GREEK UPSILON WITH DIARESIS AND HOOK SYMBOL) requires two passes to reach a stable output.
After applying all enforcement rules, the entity MUST ensure the nickname is not zero bytes in length; a non-empty input can become empty after canonicalization, and such results MUST be rejected.
An entity performing comparison MUST prepare each input string and MUST apply the Additional Mapping Rule, then Case Mapping Rule, then Normalization Rule in that order; strings are equivalent if and only if they match octet-for-octet.
An entity performing enforcement MUST prepare the input string per Section 2.2 and MUST apply the Additional Mapping Rule followed by the Normalization Rule in that order.
An entity that prepares an input string MUST ensure it consists only of Unicode code points conforming to the FreeformClass string class defined in RFC 8264.
An implementation MUST NOT treat a string as conforming to the Nickname profile until the enforcement operation has been completed; it MUST NOT assume an input string is conforming beforehand.
An implementation MUST NOT treat two strings as equivalent before the comparison operation has been completed; it MUST NOT assume equivalence from the input strings alone.
Because applying the Nickname profile rules is not idempotent for all code points, an implementation SHOULD apply the rules repeatedly until the output stabilizes; if not stable after three additional applications, the implementation SHOULD reject the input as invalid.
During enforcement, an entity SHOULD apply the Case Mapping Rule only during comparison, not enforcement, to preserve the user's chosen capitalization while still enabling case-insensitive matching.
To ensure secure operation, authentication and authorization decisions MUST be made on the basis of the thing's underlying identity (e.g., URI or file path), not its nickname.
The Nickname profile is defined over the PRECIS FreeformClass and specifies rules for width mapping (none), additional mapping, case mapping, normalization (NFKC), and directionality (none) to prepare, enforce, and compare internationalized nickname strings.
IANA has added a 'Nickname' entry to the 'PRECIS Profiles' registry, specifying base class FreeformClass, additional mapping (non-ASCII space → U+0020, strip leading/trailing spaces, collapse interior spaces), case mapping (toLowerCase), normalization (NFKC), and no directionality rule.
Authentication and authorization decisions must be based on a thing's stable underlying identity (URI, file path, etc.), not its nickname, because nicknames are human-friendly handles that can be spoofed or confused.
The mapping rules in Section 2 are designed in part to reduce nickname confusion, but the document does not provide detailed recommendations for handling visually similar ('confusable') characters; implementers are referred to Unicode Technical Standard #39.
The security considerations of RFC 8264 (PRECIS Framework) apply to the FreeformClass used for nicknames, and the security considerations of UTS39 (Unicode Security Mechanisms) apply to use of Unicode code points in nicknames.