Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
updates
- rfc-5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
Extracted elements (20)
IANA-published IDNA derived property tables are non-normative and exist only for the convenience of implementers; the absence of tables for a given Unicode version does not mean IDNA cannot be used with that version. Confusion over this point has caused significant harm, and the registry title has been changed from 'IDNA Parameters' to 'IDNA Rules and Derived Property Values' to reduce it.
IDNA2008 replaced IDNA2003's normative table-based approach with property-based rules derived from Unicode properties, so that the standard would not be intrinsically tied to a particular Unicode version and could be applied to any Unicode version from approximately 5.0 forward.
Reviews are limited to major Unicode versions (NN.0) rather than all versions because Unicode has moved to a regular one-year release cycle. Reviewing minor updates (e.g., 12.1, which added a single new code point) would overload IETF internationalization resources and generate IANA tables for trivial changes.
The new code point analysis review requires a team of experts (designated expert team) rather than a single designated expert, because the required expertise spans Unicode, DNS, writing systems, and ICANN policy — knowledge too broad for any one person. The team must reach consensus for any nontrivial recommendations.
This document restores the original IDNA2008 intent: absent extremely strong per-code-point evidence of significant harm, Unicode changes that would alter IDNA derived property values must be captured as IDNA exceptions that preserve the validity status of existing labels. Prior reviews deviated from this by favoring Unicode compatibility over IDNA backward compatibility.
Verified RFC Editor Erratum 3312 is incorporated: in RFC 5892 Appendix A.1, the Rule Set for the ZERO WIDTH NON-JOINER (U+200C) context rule is corrected to properly express the False default and the two True conditions (Virama predecessor and dual-joining sequence match).
Code points classified as 'under review' should be treated as unsafe: labels containing them should be used only with extreme caution because the conclusion of the new code point analysis may change their derived property values and validity status, potentially invalidating previously constructed labels.
IDNA applications need not use the same Unicode version for all purposes; the normative requirement is only that the derived properties used for IDNA label processing be consistent with whichever Unicode version the application uses elsewhere. The IANA tables are advisory aids, not authoritative references.
Absent extremely strong evidence on a per-code-point basis that preserving label validity would cause significant harm, Unicode changes affecting IDNA derived properties are to be reflected in IDNA exceptions that preserve the status of those labels.
Code points whose derived property status is uncertain pending new code point analysis (Section 3.2) should be considered unsafe and identified as 'under review' in the IANA tables until final derived properties are assigned.
For contextual rules in RFC 5892 Appendix A (incorporated via verified Erratum 3312): for the rule to evaluate to True for a label, it MUST be evaluated separately for every occurrence of the code point in the label, and each of those evaluations must result in True.
For the code point review (Part II), the IESG must appoint a designated expert team rather than a single expert, and the team must maintain close contact with Area Directors, with periodic reexamination of team membership at least annually.
IDNA applications and libraries are not required to support any particular version of Unicode; instead they are required to use derived property values based on calculations associated with whatever version of Unicode they are using elsewhere in the application or library.
If an algorithmic review detects changes in Unicode after version 12.0 that would break compatibility with prior IDNA derived properties, or that would preserve IDNA compatibility at the cost of departing from current Unicode specifications, those changes must be captured in documents published as Standards Track RFCs.
Unless the IESG or the designated expert team concludes that there are special problems or unusual circumstances, Unicode version reviews will be performed only for major Unicode versions (those numbered NN.0) and not for minor updates.
A new temporary 'under review' status category is introduced for the PVALID/DISALLOWED entries in IANA IDNA tables, allowing problematic code points to be flagged before IETF consensus is reached so that use of a new Unicode version is not blocked pending the full review.
Two distinct types of review are defined for each new major Unicode version: Part I is an algorithmic comparison of derived properties between the new and previous Unicode version to detect incompatibilities; Part II is a review of newly assigned code points for violations of IDNA design assumptions or requirements for special treatment such as contextual rules.
IANA's 'IDNA Rules and Derived Property Values' registry (formerly 'IDNA Parameters') is updated to be explicitly marked non-normative, to include a new 'Status' field for code points under review, and to point to RFC 8753 for explanation. Tables through Unicode 11.0 are retained; newer tables will be supplied by the IETF per this document's procedures.
Changes in the calculated derived property value for a code point — from DISALLOWED to PVALID or from PVALID to DISALLOWED — can cause changes in label interpretation that are visible and confusing to end users and might enable attacks such as homograph-based spoofing or unexpected label equivalence.
Past confusion about IDNA requirements — particularly whether IANA tables being out of date rendered IDNA unusable — created opportunities for bad behavior. The clarifications in this document are expected to reduce such confusion and improve Internet security to at least some small extent.