The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
updated by
- rfc-8753 — Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
Extracted elements (27)
An inclusion-based approach is used to select permitted code points for IDNs, rather than the exclusion-based approach of Stringprep/Nameprep. This reflects IAB consensus that identifying permitted characters is preferable to excluding a small number from the total Unicode set.
Conjoining Hangul Jamo are excluded from PVALID status so that old Hangul syllables (spelled with Jamo sequences) cannot appear in IDN labels. This avoids the complexity of Jamo-sequence handling in domain names and limits Korean IDNs to preformed syllable code points.
NFKC normalization is used in the Unstable category calculation even though NFC is used in the Protocol document (RFC 5891). NFKC is applied at the classification stage to identify characters that are not stable across normalization forms, catching a broader set of problematic code points.
The document specifies a procedure (algorithm) rather than a static table of code points, so the derived property can be computed for any Unicode version including characters added after Unicode 5.2. Changes in Unicode properties that do not affect the algorithm output do not affect IDN code point status.
Unicode property changes that do not alter the algorithm's output (e.g., General_Category shifting from So to Sm or Lo to Ll) have no effect on IDN code point status. This design allows the IDNA2008 algorithm to remain stable across Unicode versions without requiring periodic re-review of the standard itself.
A character with derived property value CONTEXTJ or CONTEXTO MUST NOT be used in an IDN label unless an appropriate contextual rule has been established and the context of the character is consistent with that rule. It is invalid to register or look up a string containing such characters without a satisfied contextual rule.
Arabic-Indic digits (U+0660–U+0669) and Extended Arabic-Indic digits (U+06F0–U+06F9) MUST NOT be mixed within the same label. Each set has a CONTEXTO rule that returns False if any character in the label belongs to the other digit set.
The category definitions and algorithm in Sections 2 and 3 are normative. The code point table in Appendix B is non-normative and included only for illustration; implementations MUST use the algorithm to compute derived property values rather than copying the table.
The BackwardCompatible (G) category is currently empty but provides a stability mechanism: if a future Unicode property change would alter a code point's derived IDNA property value, this list can be updated to preserve the original assignment and protect existing registered domain names.
The contextual rule for U+00B7 (MIDDLE DOT) permits its use only when both the immediately preceding and immediately following characters are U+006C (LATIN SMALL LETTER L), allowing expression of the Catalan character ela geminada. This rule is not applied at lookup time.
The contextual rule for U+200C (ZERO WIDTH NON-JOINER) permits its use in formally cursive scripts (e.g., Persian) where it breaks a required cursive connection, or in Indic scripts immediately following a character with Canonical_Combining_Class equal to Virama. The rule also permits it when it appears between characters with appropriate Joining_Type values (L or D on the left, R or D on the right, with optional T characters in between).
The contextual rule for U+200D (ZERO WIDTH JOINER) permits its use in Indic scripts in a consonant-conjunct context. It is valid only if the character immediately preceding U+200D has Canonical_Combining_Class equal to Virama.
The contextual rule for U+30FB (KATAKANA MIDDLE DOT) requires that at least one character in the label have a Script property value of Hiragana, Katakana, or Han. The Katakana Middle Dot itself has Script=Common, so labels consisting solely of this character are disallowed.
The contextual rule pseudo-code language used in the Contextual Rules Registry supports Boolean expressions, set membership (.in.), equality (.eq.), character position functions (Before(cp), After(cp), FirstChar, LastChar), Script(cp), Canonical_Combining_Class(cp), RegExpMatch(), and a For-All-Characters loop construct. Undefined propagates immediately to terminate rule evaluation.
The Exceptions (F) category explicitly overrides core Unicode property assignments. Notable entries: U+00DF (LATIN SMALL LETTER SHARP S) and U+3007 (IDEOGRAPHIC NUMBER ZERO) become PVALID; U+00B7 (MIDDLE DOT), U+0375, U+05F3, U+05F4, U+30FB become CONTEXTO; Arabic-Indic digit sets (U+0660–U+0669, U+06F0–U+06F9) become CONTEXTO; U+0640 (ARABIC TATWEEL) and ten vertical Kana repeat marks become DISALLOWED.
The IDNA derived property has five possible values: PVALID (permitted for general use in IDNs), CONTEXTJ (Join Control characters requiring contextual rules), CONTEXTO (other characters requiring contextual rules), DISALLOWED (not permitted in IDNs), and UNASSIGNED (unassigned Unicode code points).
The IgnorableBlocks (D) category covers code points in the Unicode blocks {Combining Diacritical Marks for Symbols, Musical Symbols, Ancient Greek Musical Notation}, which are impractical for IDN use and are DISALLOWED.
The IgnorableProperties (C) category groups code points that are Default_Ignorable_Code_Point, White_Space, or Noncharacter_Code_Point — characters not recommended for use in identifiers. These are DISALLOWED in IDNs.
The JoinControl (H) category consists of characters with Join_Control(cp) = True — specifically U+200C (ZERO WIDTH NON-JOINER) and U+200D (ZERO WIDTH JOINER). These are assigned CONTEXTJ and require a contextual rule to be used in any IDN label.
The LDH (E) category explicitly lists the traditional hostname characters: U+002D (HYPHEN-MINUS), U+0030–0039 (digits 0–9), and U+0061–007A (lowercase a–z). These are assigned PVALID.
The LetterDigits (A) category covers Unicode General_Category values {Ll, Lu, Lo, Nd, Lm, Mn, Mc} — lowercase letters, uppercase letters, other letters, decimal numbers, modifier letters, nonspacing marks, and spacing marks. Code points in this category are the primary candidates for PVALID status.
The OldHangulJamo (I) category covers Hangul_Syllable_Type values {L, V, T} — all conjoining Hangul Jamo (leading, vowel, and trailing). These are DISALLOWED, restricting Korean PVALID characters exclusively to preformed modern Hangul syllables.
The Unstable (B) category identifies code points where toNFKC(toCaseFold(toNFKC(cp))) != cp — characters not stable under NFKC normalization and case folding. These are generally DISALLOWED in IDNs.
IANA has created the IDNA-Derived Property Value Registry covering Unicode versions 5.2 and later. Values are computed by a designated expert per the algorithm in Sections 2–3. Changes to the underlying rules require IETF Review; non-backward-compatible issues must be flagged to the IESG.
IANA maintains the IDNA Context Registry of approved contextual rules for all CONTEXTO and CONTEXTJ code points. Each entry includes the code point, a plain-English overview, whether the rule applies at lookup time, and a pseudo-code rule set. Additions or changes require IETF Review.
Security considerations for IDNA2008 (except issues specific to right-to-left scripts) are described in the Definitions document (RFC 5890). Issues for labels containing right-to-left script characters are covered in the Bidi document (RFC 5893).
The derived property algorithm evaluates code points in strict priority order: Exceptions → BackwardCompatible → Unassigned (→UNASSIGNED) → LDH (→PVALID) → JoinControl (→CONTEXTJ) → Unstable (→DISALLOWED) → IgnorableProperties (→DISALLOWED) → IgnorableBlocks (→DISALLOWED) → OldHangulJamo (→DISALLOWED) → LetterDigits (→PVALID) → else DISALLOWED.