1 Internet Engineering Task Force (IETF)                        J. Klensin   
    2 Request for Comments: 8753                                                 
    3 Updates: 5892                                               P. Fältström   
    4 Category: Standards Track                                         Netnod   
    5 ISSN: 2070-1721                                               April 2020   
    8  Internationalized Domain Names for Applications (IDNA) Review for New     
    9                             Unicode Versions                               
   11 Abstract                                                                   
   13    The standards for Internationalized Domain Names in Applications        
   14    (IDNA) require a review of each new version of Unicode to determine     
   15    whether incompatibilities with prior versions or other issues exist     
   16    and, where appropriate, to allow the IETF to decide on the trade-offs   
   17    between compatibility with prior IDNA versions and compatibility with   
   18    Unicode going forward.  That requirement, and its relationship to       
   19    tables maintained by IANA, has caused significant confusion in the      
   20    past.  This document makes adjustments to the review procedure based    
   21    on experience and updates IDNA, specifically RFC 5892, to reflect       
   22    those changes and to clarify the various relationships involved.  It    
   23    also makes other minor adjustments to align that document with          
   24    experience.                                                             
   26 Status of This Memo                                                        
   28    This is an Internet Standards Track document.                           
   30    This document is a product of the Internet Engineering Task Force       
   31    (IETF).  It represents the consensus of the IETF community.  It has     
   32    received public review and has been approved for publication by the     
   33    Internet Engineering Steering Group (IESG).  Further information on     
   34    Internet Standards is available in Section 2 of RFC 7841.               
   36    Information about the current status of this document, any errata,      
   37    and how to provide feedback on it may be obtained at                    
   38    https://www.rfc-editor.org/info/rfc8753.                                
   40 Copyright Notice                                                           
   42    Copyright (c) 2020 IETF Trust and the persons identified as the         
   43    document authors.  All rights reserved.                                 
   45    This document is subject to BCP 78 and the IETF Trust's Legal           
   46    Provisions Relating to IETF Documents                                   
   47    (https://trustee.ietf.org/license-info) in effect on the date of        
   48    publication of this document.  Please review these documents            
   49    carefully, as they describe your rights and restrictions with respect   
   50    to this document.  Code Components extracted from this document must    
   51    include Simplified BSD License text as described in Section 4.e of      
   52    the Trust Legal Provisions and are provided without warranty as         
   53    described in the Simplified BSD License.                                
   55 Table of Contents                                                          
   57    1.  Introduction                                                        
   58    2.  Brief History of IDNA Versions, the Review Requirement, and RFC     
   59            5982                                                            
   60    3.  The Review Model                                                    
   61      3.1.  Review Model Part I: Algorithmic Comparison                     
   62      3.2.  Review Model Part II: New Code Point Analysis                   
   63    4.  IDNA Assumptions and Current Practice                               
   64    5.  Derived Tables Published by IANA                                    
   65    6.  Editorial Clarification to RFC 5892                                 
   66    7.  IANA Considerations                                                 
   67    8.  Security Considerations                                             
   68    9.  References                                                          
   69      9.1.  Normative References                                            
   70      9.2.  Informative References                                          
   71    Appendix A.  Summary of Changes to RFC 5892                             
   72    Appendix B.  Background and Rationale for Expert Review Procedure       
   73            for New Code Point Analysis                                     
   74    Acknowledgments                                                         
   75    Authors' Addresses                                                      
   77 1.  Introduction                                                           
   79    The standards for Internationalized Domain Names in Applications        
   80    (IDNA) require a review of each new version of Unicode to determine     
   81    whether incompatibilities with prior versions or other issues exist     
   82    and, where appropriate, to allow the IETF to decide on the trade-offs   
   83    between compatibility with prior IDNA versions and compatibility with   
   84    Unicode [Unicode] going forward.  That requirement, and its             
   85    relationship to tables maintained by IANA, has caused significant       
   86    confusion in the past (see Section 3 and Section 4 for additional       
   87    discussion of the question of appropriate decisions and the history     
   88    of these reviews).  This document makes adjustments to the review       
   89    procedure based on nearly a decade of experience and updates IDNA,      
   90    specifically the document that specifies the relationship between       
   91    Unicode code points and IDNA derived properties [RFC5892], to reflect   
   92    those changes and to clarify the various relationships involved.        
   94    This specification does not change the requirement that registries at   
   95    all levels of the DNS tree take responsibility for the labels they      
   96    insert in the DNS, a level of responsibility that requires allowing     
   97    only a subset of the code points and strings allowed by the IDNA        
   98    protocol itself.  That requirement is discussed in more detail in a     
   99    companion document [RegRestr].                                          
  101    Terminology note: In this document, "IDNA" refers to the current        
  102    version as described in RFC 5890 [RFC5890] and subsequent documents     
  103    and sometimes known as "IDNA2008".  Distinctions between it and the     
  104    earlier version are explicit only where they are necessary for          
  105    understanding the relationships involved, e.g., in Section 2.           
  107 2.  Brief History of IDNA Versions, the Review Requirement, and RFC 5982   
  109    The original, now-obsolete, version of IDNA, commonly known as          
  110    "IDNA2003" [RFC3490] [RFC3491], was defined in terms of a profile of    
  111    a collection of IETF-specific tables [RFC3454] that specified the       
  112    usability of each Unicode code point with IDNA.  Because the tables     
  113    themselves were normative, they were intrinsically tied to a            
  114    particular version of Unicode.  As Unicode evolved, the IDNA2003        
  115    standard would have required the creation of a new profile for each     
  116    new version of Unicode, or the tables would have fallen further and     
  117    further behind.                                                         
  119    When IDNA2003 was superseded by the current version, known as           
  120    IDNA2008 [RFC5890], a different strategy, one that was property-based   
  121    rather than table-based, was adopted for a number of reasons, of        
  122    which the reliance on normative tables was not dominant [RFC4690].      
  123    In the IDNA2008 model, the use of normative tables was replaced by a    
  124    set of procedures and rules that operated on Unicode properties         
  125    [Unicode-properties] and a few internal definitions to determine the    
  126    category and status, and hence an IDNA-specific "derived property",     
  127    for any given code point.  Those rules are, in principle, independent   
  128    of Unicode versions.  They can be applied to any version of Unicode,    
  129    at least from approximately version 5.0 forward, to yield an            
  130    appropriate set of derived properties.  However, the working group      
  131    that defined IDNA2008 recognized that not all of the Unicode            
  132    properties were completely stable and that, because the criteria for    
  133    new code points and property assignment used by the Unicode             
  134    Consortium might not precisely align with the needs of IDNA, there      
  135    were possibilities of incompatible changes to the derived property      
  136    values.  More specifically, there could be changes that would make      
  137    previously disallowed labels valid, previously valid labels             
  138    disallowed, or that would be disruptive to IDNA's defining rule         
  139    structure.  Consequently, IDNA2008 provided for an expert review of     
  140    each new version of Unicode with the possibility of providing           
  141    exceptions to the rules for particular new code points, code points     
  142    whose properties had changed, and newly discovered issues with the      
  143    IDNA2008 collection of rules.  When problems were identified, the       
  144    reviewer was expected to notify the IESG.  The assumption was that      
  145    the IETF would review the situation and modify IDNA2008 as needed,      
  146    most likely by adding exceptions to preserve backward compatibility     
  147    (see Section 3.1).                                                      
  149    For the convenience of the community, IDNA2008 also provided that       
  150    IANA would maintain copies of calculated tables resulting from each     
  151    review, showing the derived properties for each code point.  Those      
  152    tables were expected to be helpful, especially to those without the     
  153    facilities to easily compute derived properties themselves.             
  154    Experience with the community and those tables has shown that they      
  155    have been confused with the normative tables of IDNA2003: the           
  156    IDNA2008 tables published by IANA have never been normative, and        
  157    statements about IDNA2008 being out of date with regard to some         
  158    Unicode version because the IANA tables have not been updated are       
  159    incorrect or meaningless.                                               
  161 3.  The Review Model                                                       
  163    While the text has sometimes been interpreted differently, IDNA2008     
  164    actually calls for two types of review when a new Unicode version is    
  165    introduced.  One is an algorithmic comparison of the set of derived     
  166    properties calculated from the new version of Unicode to the derived    
  167    properties calculated from the previous one to determine whether        
  168    incompatible changes have occurred.  The other is a review of newly     
  169    assigned code points to determine whether any of them require special   
  170    treatment (e.g., assignment of what IDNA2008 calls contextual rules)    
  171    and whether any of them violate any of the assumptions underlying the   
  172    IDNA2008 derived property calculations.  Any of the cases of either     
  173    review might require either per-code point exceptions or other          
  174    adjustments to the rules for deriving properties that are part of RFC   
  175    5892.  The subsections below provide a revised specification for the    
  176    review procedure.                                                       
  178    Unless the IESG or the designated expert team concludes that there      
  179    are special problems or unusual circumstances, these reviews will be    
  180    performed only for major Unicode versions (those numbered NN.0, e.g.,   
  181    12.0) and not for minor updates (e.g., 12.1).                           
  183    As can be seen in the detailed descriptions in the following            
  184    subsections, proper review will require a team of experts that has      
  185    both broad and specific skills in reviewing Unicode characters and      
  186    their properties in relation to both the written standards and          
  187    operational needs.  The IESG will need to appoint experts who can       
  188    draw on the broader community to obtain the necessary skills for        
  189    particular situations.  See the IANA Considerations (Section 7) for     
  190    details.                                                                
  192 3.1.  Review Model Part I: Algorithmic Comparison                          
  194    Section 5.1 of RFC 5892 is the description of the process for           
  195    creating the initial IANA tables.  It is noteworthy that, while it      
  196    can be read as strongly implying new reviews and new tables for         
  197    versions of Unicode after 5.2, it does not explicitly specify those     
  198    reviews or, e.g., the timetable for completing them.  It also           
  199    indicates that incompatibilities are to be "flagged for the IESG" but   
  200    does not specify exactly what the IESG is to do about them and when.    
  201    For reasons related to the other type of review and discussed below,    
  202    only one review was completed, documented [RFC6452], and a set of       
  203    corresponding new tables installed.  That review, which was for         
  204    Unicode 6.0, found only three incompatibilities; the consensus was to   
  205    ignore them (not create exceptions in IDNA2008) and to remain           
  206    consistent with computations based on current (Unicode 6.0)             
  207    properties rather than preserving backward compatibility within IDNA.   
  208    The 2018 review (for Unicode 11.0 and versions in between it and 6.0)   
  209    [IDNA-Unicode12] also concluded that Unicode compatibility, rather      
  210    than IDNA backward compatibility, should be maintained.  That           
  211    decision was partially driven by the long period between reviews and    
  212    the concern that table calculations by others in the interim could      
  213    result in unexpected incompatibilities if derived property              
  214    definitions were then changed.  See Section 4 for further discussion    
  215    of these preferences.                                                   
  217 3.2.  Review Model Part II: New Code Point Analysis                        
  219    The second type of review, which is not clearly explained in RFC        
  220    5892, is intended to identify cases in which newly added or recently    
  221    discovered problematic code points violate the design assumptions of    
  222    IDNA, to identify defects in those assumptions, or to identify          
  223    inconsistencies (from an IDNA perspective) with Unicode commitments     
  224    about assignment, properties, and stability of newly added code         
  225    points.  One example of this type of review was the discovery of new    
  226    code points after Unicode 7.0 that were potentially visually            
  227    equivalent, in the same script, to previously available code point      
  228    sequences [IAB-Unicode7-2015] [IDNA-Unicode7].                          
  230    Because multiple perspectives on Unicode and writing systems are        
  231    required, this review will not be successful unless it is done by a     
  232    team.  Finding one all-knowing expert is improbable, and a single       
  233    expert is unlikely to produce an adequate analysis.  Rather than any    
  234    single expert being the sole source of analysis, the designated         
  235    expert (DE) team needs to understand that there will always be gaps     
  236    in their knowledge, to know what they don't know, and to work to find   
  237    the expertise that each review requires.  It is also important that     
  238    the DE team maintains close contact with the Area Directors (ADs) and   
  239    that the ADs remain aware of the team's changing needs, examining and   
  240    adjusting the team's membership over time, with periodic                
  241    reexamination at least annually.  It should also be recognized that,    
  242    if this review identifies a problem, that problem is likely to be       
  243    complex and/or involve multiple trade-offs.  Actions to deal with it    
  244    are likely to be disruptive (although perhaps not to large              
  245    communities of users), or to leave security risks (opportunities for    
  246    attacks and inadvertent confusion as expected matches do not occur),    
  247    or to cause excessive reliance on registries understanding and taking   
  248    responsibility for what they are registering [RFC5894] [RegRestr].      
  249    The latter, while a requirement of IDNA, has often not worked out       
  250    well in the past.                                                       
  252    Because resolution of problems identified by this part of the review    
  253    may take some time even if that resolution is to add additional         
  254    contextual rules or to disallow one or more code points, there will     
  255    be cases in which it will be appropriate to publish the results of      
  256    the algorithmic review and to provide IANA with corresponding tables,   
  257    with warnings about code points whose status is uncertain until there   
  258    is IETF consensus about how to proceed.  The affected code points       
  259    should be considered unsafe and identified as "under review" in the     
  260    IANA tables until final derived properties are assigned.                
  262 4.  IDNA Assumptions and Current Practice                                  
  264    At the time the IDNA2008 documents were written, the assumption was     
  265    that, if new versions of Unicode introduced incompatible changes, the   
  266    Standard would be updated to preserve backward compatibility for        
  267    users of IDNA.  For most purposes, this would be done by adding to      
  268    the table of exceptions associated with Rule G [RFC5892a].              
  270    This has not been the practice in the reviews completed subsequent to   
  271    Unicode 5.2, as discussed in Section 3.  Incompatibilities were         
  272    identified in Unicode 6.0 [RFC6452] and in the cumulative review        
  273    leading to tables for Unicode 11.0 [IDNA-Unicode11].  In all of those   
  274    cases, the decision was made to maintain compatibility with Unicode     
  275    properties rather than with prior versions of IDNA.                     
  277    If an algorithmic review detects changes in Unicode after version       
  278    12.0 that would break compatibility with derived properties             
  279    associated with prior versions of Unicode or changes that would         
  280    preserve compatibility within IDNA at the cost of departing from        
  281    current Unicode specifications, those changes must be captured in       
  282    documents expected to be published as Standards Track RFCs so that      
  283    the IETF can review those changes and maintain a historical record.     
  285    The community has now made decisions and updated tables for Unicode     
  286    6.0 [RFC6452], done catch-up work between it and Unicode 11.0           
  287    [IDNA-Unicode11], and completed the review and tables for Unicode       
  288    12.0 [IDNA-Unicode12].  The decisions made in those cases were driven   
  289    by preserving consistency with Unicode and Unicode property changes     
  290    for reasons most clearly explained by the IAB [IAB-Unicode-2018].       
  291    These actions were not only at variance with the language in RFC 5892   
  292    but were also inconsistent with commitments to the registry and user    
  293    communities to ensure that IDN labels that were once valid under        
  294    IDNA2008 would remain valid, and previously invalid labels would        
  295    remain invalid, except for those labels that were invalid because       
  296    they contained unassigned code points.                                  
  298    This document restores and clarifies that original language and         
  299    intent: absent extremely strong evidence on a per-code point basis      
  300    that preserving the validity status of possible existing (or            
  301    prohibited) labels would cause significant harm, Unicode changes that   
  302    would affect IDNA derived properties are to be reflected in IDNA        
  303    exceptions that preserve the status of those labels.  There is one      
  304    partial exception to this principle.  If the new code point analysis    
  305    (see Section 3.2) concludes that some code points or collections of     
  306    code points should be further analyzed, those code points, and labels   
  307    including them, should be considered unsafe and used only with          
  308    extreme caution because the conclusions of the analysis may change      
  309    their derived property values and status.                               
  311 5.  Derived Tables Published by IANA                                       
  313    As discussed above, RFC 5892 specified that derived property tables     
  314    be provided via an IANA registry.  Perhaps because most IANA            
  315    registries are considered normative and authoritative, that registry    
  316    has been the source of considerable confusion, including the            
  317    incorrect assumption that the absence of published tables for           
  318    versions of Unicode later than 6.0 meant that IDNA could not be used    
  319    with later versions.  That position was raised in multiple ways, not    
  320    all of them consistent, especially in the ICANN context                 
  321    [ICANN-LGR-SLA].                                                        
  323    If the changes specified in this document are not successful in         
  324    significantly mitigating the confusion about the status of the tables   
  325    published by IANA, serious consideration should be given to             
  326    eliminating those tables entirely.                                      
  328 6.  Editorial Clarification to RFC 5892                                    
  330    This section updates RFC 5892 to provide fixes for known applicable     
  331    errata and omissions.  In particular, verified RFC Editor Erratum       
  332    3312 [Err3312] provides a clarification to Appendix A and A.1 in RFC    
  333    5892.  That clarification is incorporated below.                        
  335    1.  In Appendix A, add a new paragraph after the paragraph that         
  336        begins "The code point...".  The new paragraph should read:         
  338        |  For the rule to be evaluated to True for the label, it MUST be   
  339        |  evaluated separately for every occurrence of the code point in   
  340        |  the label; each of those evaluations must result in True.        
  342    2.  In Appendix A.1, replace the "Rule Set" by                          
  344            Rule Set:                                                       
  345              False;                                                        
  346              If Canonical_Combining_Class(Before(cp)) .eq. Virama          
  347                    Then True;                                              
  348              If cp .eq. \u200C And                                         
  349                     RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp    
  350                (Joining_Type:T)*(Joining_Type:{R,D})) Then True;           
  352 7.  IANA Considerations                                                    
  354    For the algorithmic review described in Section 3.1, the IESG is to     
  355    appoint a designated expert [RFC8126] with appropriate expertise to     
  356    conduct the review and to supply derived property tables to IANA.  As   
  357    provided in Section 5.2 of the Guidelines for Writing IANA              
  358    Considerations [RFC8126], the designated expert is expected to          
  359    consult additional sources of expertise as needed.  For the code        
  360    point review, the expertise will be supplied by an IESG-designated      
  361    expert team as discussed in Section 3.2 and Appendix B.  In both        
  362    cases, the experts should draw on the expertise of other members of     
  363    the community as needed.  In particular, and especially if there is     
  364    no overlap of the people holding the various roles, coordination with   
  365    the IAB-appointed liaison to the Unicode Consortium will be essential   
  366    to mitigate possible errors due to confusion.                           
  368    As discussed in Section 5, IANA has modified the IDNA tables            
  369    collection [IANA-IDNA-Tables] by identifying them clearly as non-       
  370    normative, so that a "current" or "correct" version of those tables     
  371    is not implied, and by pointing to this document for an explanation.    
  372    IANA has published tables supplied by the IETF for all Unicode          
  373    versions through 11.0, retaining all older versions and making them     
  374    available.  Newer tables will be constructed as specified in this       
  375    document and then made available by IANA.  IANA has changed the title   
  376    of that registry from "IDNA Parameters", which is misleading, to        
  377    "IDNA Rules and Derived Property Values".                               
  379    The "Note" in that registry says:                                       
  381    |  IDNA does not require that applications and libraries, either for    
  382    |  registration/storage or lookup, support any particular version of    
  383    |  Unicode.  Instead, they are required to use derived property         
  384    |  values based on calculations associated with whatever version of     
  385    |  Unicode they are using elsewhere in the application or library.      
  386    |  For the convenience of application and library developers and        
  387    |  others, the IETF has supplied, and IANA maintains, derived           
  388    |  property tables for several version of Unicode as listed below.      
  389    |  It should be stressed that these are not normative in that, in       
  390    |  principle, an application can do its own calculations and these      
  391    |  tables can change as IETF understanding evolves.  By contrast, the   
  392    |  list of code points requiring contextual rules and the associated    
  393    |  rules are normative and should be treated as updates to the list     
  394    |  in RFC 5892.                                                         
  396    As long as the intent is preserved, the text of that note may be        
  397    changed in the future at IANA's discretion.                             
  399    IANA's attention is called to the introduction, in Section 3.2, of a    
  400    temporary "under review" category to the PVALID, DISALLOWED, etc.,      
  401    entries in the tables.                                                  
  403 8.  Security Considerations                                                
  405    Applying the procedures described in this document and understanding    
  406    of the clarifications it provides should reduce confusion about IDNA    
  407    requirements.  Because past confusion has provided opportunities for    
  408    bad behavior, the effect of these changes should improve Internet       
  409    security to at least some small extent.                                 
  411    Because of the preference to keep the derived property value stable     
  412    (as specified in RFC 5892 and discussed in Section 4), the algorithm    
  413    used to calculate those derived properties does change as explained     
  414    in Section 3.  If these changes are not taken into account, the         
  415    derived property value will change, and the implications might have     
  416    negative consequences, in some cases with security implications.  For   
  417    example, changes in the calculated derived property value for a code    
  418    point from either DISALLOWED to PVALID or from PVALID to DISALLOWED     
  419    can cause changes in label interpretation that would be visible and     
  420    confusing to end users and might enable attacks.                        
  422 9.  References                                                             
  424 9.1.  Normative References                                                 
  426    [IANA-IDNA-Tables]                                                      
  427               IANA, "IDNA Rules and Derived Property Values",              
  428               <https://www.iana.org/assignments/idna-tables>.              
  430    [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and             
  431               Internationalized Domain Names for Applications (IDNA)",     
  432               RFC 5892, DOI 10.17487/RFC5892, August 2010,                 
  433               <https://www.rfc-editor.org/info/rfc5892>.                   
  435    [RFC5892a] Faltstrom, P., Ed., "The Unicode Code Points and             
  436               Internationalized Domain Names for Applications (IDNA)",     
  437               Section 2.7, RFC 5892, August 2010,                          
  438               <https://www.rfc-editor.org/rfc/rfc5892.txt>.                
  440    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for        
  441               Writing an IANA Considerations Section in RFCs", BCP 26,     
  442               RFC 8126, DOI 10.17487/RFC8126, June 2017,                   
  443               <https://www.rfc-editor.org/info/rfc8126>.                   
  445    [Unicode]  The Unicode Consortium, "The Unicode Standard (Current       
  446               Version)", <http://www.unicode.org/versions/latest/>.  The   
  447               link given will always access the current version of the     
  448               Unicode Standard, independent of its version number or       
  449               date.                                                        
  451    [Unicode-properties]                                                    
  452               The Unicode Consortium, "The Unicode Standard Version        
  453               11.0", Section 3.5, 2018,                                    
  454               <https://www.unicode.org/versions/Unicode11.0.0/>.           
  456 9.2.  Informative References                                               
  458    [Err3312]  RFC Errata, Erratum ID 3312, RFC 5892,                       
  459               <https://www.rfc-editor.org/errata/eid3312>.                 
  461    [IAB-Unicode-2018]                                                      
  462               Internet Architecture Board (IAB), "IAB Statement on         
  463               Identifiers and Unicode", 15 March 2018,                     
  464               <https://www.iab.org/documents/correspondence-reports-       
  465               documents/2018-2/iab-statement-on-identifiers-and-           
  466               unicode/>.                                                   
  468    [IAB-Unicode7-2015]                                                     
  469               Internet Architecture Board (IAB), "IAB Statement on         
  470               Identifiers and Unicode 7.0.0", 11 February 2015,            
  471               <https://www.iab.org/documents/correspondence-reports-       
  472               documents/2015-2/iab-statement-on-identifiers-and-unicode-   
  473               7-0-0/>.                                                     
  475    [ICANN-LGR-SLA]                                                         
  476               Internet Corporation for Assigned Names and Numbers          
  477               (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN         
  478               Tables", 10 June 2019, <https://www.icann.org/public-        
  479               comments/proposed-iana-sla-lgr-idn-tables-2019-06-10-en>.    
  481    [IDNA-Unicode7]                                                         
  482               Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 7.0   
  483               and Later Versions", Work in Progress, Internet-Draft,       
  484               draft-klensin-idna-5892upd-unicode70-05, 8 October 2017,     
  485               <https://tools.ietf.org/html/draft-klensin-idna-5892upd-     
  486               unicode70-05>.                                               
  488    [IDNA-Unicode11]                                                        
  489               Faltstrom, P., "IDNA2008 and Unicode 11.0.0", Work in        
  490               Progress, Internet-Draft, draft-faltstrom-unicode11-08, 11   
  491               March 2019, <https://tools.ietf.org/html/draft-faltstrom-    
  492               unicode11-08>.                                               
  494    [IDNA-Unicode12]                                                        
  495               Faltstrom, P., "IDNA2008 and Unicode 12.0.0", Work in        
  496               Progress, Internet-Draft, draft-faltstrom-unicode12-00, 11   
  497               March 2019, <https://tools.ietf.org/html/draft-faltstrom-    
  498               unicode12-00>.                                               
  500    [RegRestr] Klensin, J. and A. Freytag, "Internationalized Domain        
  501               Names in Applications (IDNA): Registry Restrictions and      
  502               Recommendations", Work in Progress, Internet-Draft, draft-   
  503               klensin-idna-rfc5891bis-05, 29 August 2019,                  
  504               <https://tools.ietf.org/html/draft-klensin-idna-             
  505               rfc5891bis-05>.                                              
  507    [RFC1766]  Alvestrand, H., "Tags for the Identification of              
  508               Languages", RFC 1766, DOI 10.17487/RFC1766, March 1995,      
  509               <https://www.rfc-editor.org/info/rfc1766>.                   
  511    [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,        
  512               DOI 10.17487/RFC3282, May 2002,                              
  513               <https://www.rfc-editor.org/info/rfc3282>.                   
  515    [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of                 
  516               Internationalized Strings ("stringprep")", RFC 3454,         
  517               DOI 10.17487/RFC3454, December 2002,                         
  518               <https://www.rfc-editor.org/info/rfc3454>.                   
  520    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,                 
  521               "Internationalizing Domain Names in Applications (IDNA)",    
  522               RFC 3490, DOI 10.17487/RFC3490, March 2003,                  
  523               <https://www.rfc-editor.org/info/rfc3490>.                   
  525    [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep         
  526               Profile for Internationalized Domain Names (IDN)",           
  527               RFC 3491, DOI 10.17487/RFC3491, March 2003,                  
  528               <https://www.rfc-editor.org/info/rfc3491>.                   
  530    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO          
  531               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November     
  532               2003, <https://www.rfc-editor.org/info/rfc3629>.             
  534    [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and   
  535               Recommendations for Internationalized Domain Names           
  536               (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,     
  537               <https://www.rfc-editor.org/info/rfc4690>.                   
  539    [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying   
  540               Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,          
  541               September 2009, <https://www.rfc-editor.org/info/rfc5646>.   
  543    [RFC5890]  Klensin, J., "Internationalized Domain Names for             
  544               Applications (IDNA): Definitions and Document Framework",    
  545               RFC 5890, DOI 10.17487/RFC5890, August 2010,                 
  546               <https://www.rfc-editor.org/info/rfc5890>.                   
  548    [RFC5894]  Klensin, J., "Internationalized Domain Names for             
  549               Applications (IDNA): Background, Explanation, and            
  550               Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,     
  551               <https://www.rfc-editor.org/info/rfc5894>.                   
  553    [RFC6452]  Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code    
  554               Points and Internationalized Domain Names for Applications   
  555               (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,       
  556               November 2011, <https://www.rfc-editor.org/info/rfc6452>.    
  558 Appendix A.  Summary of Changes to RFC 5892                                
  560    Other than the editorial correction specified in Section 6, all of      
  561    the changes in this document are concerned with the reviews for new     
  562    versions of Unicode and with the IANA Considerations in Section 5 of    
  563    [RFC5892], particularly Section 5.1 of [RFC5892].  Whether the          
  564    changes are substantive or merely clarifications may be somewhat in     
  565    the eye of the beholder, so the list below should not be assumed to     
  566    be comprehensive.  At a very high level, this document clarifies that   
  567    two types of review were intended and separates them for clarity.       
  568    This document also restores the original (but so far unobserved)        
  569    default for actions when code point derived properties change.  For     
  570    this reason, this document effectively replaces Section 5.1 of          
  571    [RFC5892] and adds or changes some text so that the replacement makes   
  572    better sense.                                                           
  574    Changes or clarifications that may be considered important include:     
  576    *  Separated the new Unicode version review into two explicit parts     
  577       and provided for different review methods and, potentially,          
  578       asynchronous outcomes.                                               
  580    *  Specified a DE team, not a single designated expert, for the code    
  581       point review.                                                        
  583    *  Eliminated the de facto requirement for the (formerly single)        
  584       designated expert to be the same person as the IAB's liaison to      
  585       the Unicode Consortium, but called out the importance of             
  586       coordination.                                                        
  588    *  Created the "Status" field in the IANA tables to inform the          
  589       community about specific potentially problematic code points.        
  590       This change creates the ability to add information about such code   
  591       points before IETF review is completed instead of having the         
  592       review process hold up the use of the new Unicode version.           
  594    *  In part because Unicode is now on a regular one-year cycle rather    
  595       than producing major and minor versions as needed, to avoid          
  596       overloading the IETF's internationalization resources, and to        
  597       avoid generating and storing IANA tables for trivial changes         
  598       (e.g., the single new code point in Unicode 12.1), the review        
  599       procedure is applied only to major versions of Unicode unless        
  600       exceptional circumstances arise and are identified.                  
  602 Appendix B.  Background and Rationale for Expert Review Procedure for      
  603              New Code Point Analysis                                       
  605    The expert review procedure for new code point analysis described in    
  606    Section 3.2 is somewhat unusual compared to the examples presented in   
  607    the Guidelines for Writing IANA Considerations [RFC8126].  This         
  608    appendix explains that choice and provides the background for it.       
  610    Development of specifications to support use of languages and writing   
  611    systems other than English (and Latin script) -- so-called              
  612    "internationalization" or "i18n" -- has always been problematic in      
  613    the IETF, especially when requirements go beyond simple coding of       
  614    characters (e.g., RFC 3629 [RFC3629]) or simple identification of       
  615    languages (e.g., RFC 3282 [RFC3282] and the earlier RFC 1766            
  616    [RFC1766]).  A good deal of specialized knowledge is required,          
  617    knowledge that comes from multiple fields and that requires multiple    
  618    perspectives.  The work is not obviously more complex than routing,     
  619    especially if one assumes that routing work requires a solid            
  620    foundation in graph theory or network optimization, or than security    
  621    and cryptography, but people working in those areas are drawn to the    
  622    IETF and people from the fields that bear on internationalization       
  623    typically are not.                                                      
  625    As a result, we have often thought we understood a problem, generated   
  626    a specification or set of specifications, but then have been            
  627    surprised by unanticipated (by the IETF) issues.  We then needed to     
  628    tune and often revise our specification.  The language tag work that    
  629    started with RFC 1766 is a good example of this: broader                
  630    considerations and requirements led to later work and a much more       
  631    complex and finer-grained system [RFC5646].                             
  633    Work on IDNs further increased the difficulties because many of the     
  634    decisions that led to the current version of IDNA require               
  635    understanding the DNS, its constraints, and, to at least some extent,   
  636    the commercial market of domain names, including various ICANN          
  637    efforts.                                                                
  639    The net result of these factors is that it is extremely unlikely that   
  640    the IESG will ever find a designated expert whose knowledge and         
  641    understanding will include everything that is required.                 
  643    Consequently, Section 7 and other discussions in this document          
  644    specify a DE team that is expected to have the broad perspective,       
  645    expertise, and access to information and community in order to review   
  646    new Unicode versions and to make consensus recommendations that will    
  647    serve the Internet well.  While we anticipate that the team will have   
  648    one or more leaders, the structure of the team differs from the         
  649    suggestions given in Section 5.2 of the Guidelines for Writing IANA     
  650    Considerations [RFC8126] since neither the team's formation nor its     
  651    consultation is left to the discretion of the designated expert, nor    
  652    is the designated expert solely accountable to the community.  A team   
  653    that contains multiple perspectives is required, the team members are   
  654    accountable as a group, and any nontrivial recommendations require      
  655    team consensus.  This also differs from the common practice in the      
  656    IETF of "review teams" from which a single member is selected to        
  657    perform a review: the principle for these reviews is team effort.       
  659 Acknowledgments                                                            
  661    This document was inspired by extensive discussions within the I18N     
  662    Directorate of the IETF Applications and Real-Time (ART) area in the    
  663    first quarter of 2019 about sorting out the reviews for Unicode 11.0    
  664    and 12.0.  Careful reviews by Joel Halpern and text suggestions from    
  665    Barry Leiba resulted in some clarifications.                            
  667    Thanks to Christopher Wood for catching some editorial errors that      
  668    persisted until rather late in the document's life cycle and to         
  669    Benjamin Kaduk for catching and raising a number of questions during    
  670    Last Call.  Some of the issues they raised have been reflected in the   
  671    document; others did not appear to be desirable modifications after     
  672    further discussion, but the questions were definitely worth raising     
  673    and discussing.                                                         
  675 Authors' Addresses                                                         
  677    John C Klensin                                                          
  678    1770 Massachusetts Ave, Ste 322                                         
  679    Cambridge, MA 02140                                                     
  680    United States of America                                                
  682    Phone: +1 617 245 1457                                                  
  683    Email: john-ietf@jck.com                                                
  686    Patrik Fältström                                                        
  687    Netnod                                                                  
  688    Greta Garbos Väg 13                                                     
  689    SE-169 40 Solna                                                         
  690    Sweden                                                                  
  692    Phone: +46 70 6059051                                                   
  693    Email: paf@netnod.se                                                    

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.