While the text has sometimes been interpreted differently, IDNA2008 actually calls for two types of review when a new Unicode version is introduced. One is an algorithmic comparison of the set of derived properties calculated from the new version of Unicode to the derived properties calculated from the previous one to determine whether incompatible changes have occurred. The other is a review of newly assigned code points to determine whether any of them require special treatment (e.g., assignment of what IDNA2008 calls contextual rules) and whether any of them violate any of the assumptions underlying the IDNA2008 derived property calculations. Any of the cases of either review might require either per-code point exceptions or other adjustments to the rules for deriving properties that are part of RFC 5892
. The subsections below provide a revised specification for the review procedure.
Unless the IESG or the designated expert team concludes that there are special problems or unusual circumstances, these reviews will be performed only for major Unicode versions (those numbered NN.0, e.g., 12.0) and not for minor updates (e.g., 12.1).
As can be seen in the detailed descriptions in the following subsections, proper review will require a team of experts that has both broad and specific skills in reviewing Unicode characters and their properties in relation to both the written standards and operational needs. The IESG will need to appoint experts who can draw on the broader community to obtain the necessary skills for particular situations. See the IANA Considerations (Section 7
) for details.
of RFC 5892
is the description of the process for creating the initial IANA tables. It is noteworthy that, while it can be read as strongly implying new reviews and new tables for versions of Unicode after 5.2, it does not explicitly specify those reviews or, e.g., the timetable for completing them. It also indicates that incompatibilities are to be "flagged for the IESG" but does not specify exactly what the IESG is to do about them and when. For reasons related to the other type of review and discussed below, only one review was completed, documented [RFC 6452
], and a set of corresponding new tables installed. That review, which was for Unicode 6.0, found only three incompatibilities; the consensus was to ignore them (not create exceptions in IDNA2008) and to remain consistent with computations based on current (Unicode 6.0) properties rather than preserving backward compatibility within IDNA. The 2018 review (for Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12
] also concluded that Unicode compatibility, rather than IDNA backward compatibility, should be maintained. That decision was partially driven by the long period between reviews and the concern that table calculations by others in the interim could result in unexpected incompatibilities if derived property definitions were then changed. See Section 4
for further discussion of these preferences.
The second type of review, which is not clearly explained in RFC 5892
, is intended to identify cases in which newly added or recently discovered problematic code points violate the design assumptions of IDNA, to identify defects in those assumptions, or to identify inconsistencies (from an IDNA perspective) with Unicode commitments about assignment, properties, and stability of newly added code points. One example of this type of review was the discovery of new code points after Unicode 7.0 that were potentially visually equivalent, in the same script, to previously available code point sequences [IAB-Unicode7-2015
Because multiple perspectives on Unicode and writing systems are required, this review will not be successful unless it is done by a team. Finding one all-knowing expert is improbable, and a single expert is unlikely to produce an adequate analysis. Rather than any single expert being the sole source of analysis, the designated expert (DE) team needs to understand that there will always be gaps in their knowledge, to know what they don't know, and to work to find the expertise that each review requires. It is also important that the DE team maintains close contact with the Area Directors (ADs) and that the ADs remain aware of the team's changing needs, examining and adjusting the team's membership over time, with periodic reexamination at least annually. It should also be recognized that, if this review identifies a problem, that problem is likely to be complex and/or involve multiple trade-offs. Actions to deal with it are likely to be disruptive (although perhaps not to large communities of users), or to leave security risks (opportunities for attacks and inadvertent confusion as expected matches do not occur), or to cause excessive reliance on registries understanding and taking responsibility for what they are registering [RFC 5894
]. The latter, while a requirement of IDNA, has often not worked out well in the past.
Because resolution of problems identified by this part of the review may take some time even if that resolution is to add additional contextual rules or to disallow one or more code points, there will be cases in which it will be appropriate to publish the results of the algorithmic review and to provide IANA with corresponding tables, with warnings about code points whose status is uncertain until there is IETF consensus about how to proceed. The affected code points should be considered unsafe and identified as "under review" in the IANA tables until final derived properties are assigned.