idnits 2.17.1 draft-klensin-idna-unicode-review-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 326: '...ated to True for the label, it MUST be...' -- The draft header indicates that this document updates RFC5892, but the abstract doesn't seem to directly say this. It does mention RFC5892 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5892, updated by this document, for RFC5378 checks: 2008-04-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 22, 2019) is 1737 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IDNA-Tables' -- Duplicate reference: RFC5892, mentioned in 'RFC5892a', was also mentioned in 'RFC5892'. -- Duplicate reference: RFC5892, mentioned in 'RFC5892Erratum', was also mentioned in 'RFC5892a'. -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode-properties' -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Updates: 5892 (if approved) P. Faltstrom 5 Intended status: Standards Track Netnod 6 Expires: January 23, 2020 July 22, 2019 8 IDNA Review for New Unicode Versions 9 draft-klensin-idna-unicode-review-02 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 version 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 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 Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 23, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Brief History of IDNA Versions, the Review Requirement, and 62 RFC 5982 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The Review Model . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Review Model Part I: Algorithmic Comparison . . . . . . . 4 65 3.2. Review Model Part II: New Code Point Analysis . . . . . . 5 66 4. IDNA Assumptions and Current Practice . . . . . . . . . . . . 6 67 5. Derived Tables Published by IANA . . . . . . . . . . . . . . 7 68 6. Editorial clarification to RFC 5892 . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Appendix A. Summary of Changes to RFC 5892 . . . . . . . . . . . 12 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13 77 B.1. Changes from version -00 (2019-06-12) to -01 . . . . . . 13 78 B.2. Changes from version -01 (2019-07-06) to -02 . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The standards for Internationalized Domain Names in Applications 84 (IDNA) require a review of each new version of Unicode to determine 85 whether incompatibilities with prior version or other issues exist 86 and, where appropriate, to allow the IETF to decide on the trade-offs 87 between compatibility with prior IDNA versions and compatibility with 88 Unicode [Unicode] going forward. That requirement, and its 89 relationship to tables maintained by IANA, has caused significant 90 confusion in the past. This document makes adjustments to the review 91 procedure based on nearly a decade of experience and updates IDNA, 92 specifically the document that specifies the relationship between 93 Unicode code points and IDNA derived properties [RFC5892], to reflect 94 those changes and clarify the various relationships involved. 96 This specification does not change the requirement that registries, 97 at all levels of the DNS tree, take responsibility for the labels 98 they are inserting in the DNS, a level of responsibility that 99 requires allowing only a subset of the code points and strings 100 allowed by the IDNA protocol itself. That requirement is discussed 101 in more detail in a companion document [RegRestr]. 103 Terminology note: In this document, "IDNA" refers to the current 104 version as described in RFC 5890 [RFC5890] and subsequent documents 105 and sometimes known as "IDNA2008". Distinctions between it and the 106 earlier version are explicit only where that is necessary to 107 understanding the relationships involved, e.g., in Section 2. 109 2. Brief History of IDNA Versions, the Review Requirement, and RFC 5982 111 The original, now-obsolete, version of IDNA, commonly known as 112 "IDNA2003" [RFC3490] [RFC3491] was defined in terms of a profile of a 113 collection of IETF-specific tables [RFC3454] that specified the 114 usability of each Unicode code point with IDNA. Because the tables 115 themselves were normative, they were intrinsically tied to a 116 particular version of Unicode. As Unicode evolved, the standard 117 would either have required a new version for each new version of 118 Unicode or it would fall further and further behind. 120 When that version of IDNA was superseded by the current one, known as 121 IDNA2008 [RFC5890], a different strategy, one that was property-based 122 rather than table-based, was adopted for a number of reasons of which 123 the reliance on normative tables was not dominant [RFC4690]. In the 124 IDNA2008 model, the use of normative tables was replaced by a set of 125 procedures and rules that operated on Unicode properties 126 [Unicode-properties] and a few internal definitions to determine the 127 category and status, and hence an IDNA-specific "derived property", 128 for any given code point. Those rules are, in principle, independent 129 of Unicode versions. They can be applied to any version of Unicode, 130 at least from approximately version 5.0 forward, to yield an 131 appropriate set of derived properties. However, the working group 132 that defined IDNA2008 recognized that not all of the Unicode 133 properties were completely stable and that, because the criteria for 134 new code points and property assignment used by the Unicode 135 Consortium might not precisely align with the needs of IDNA, there 136 were possibilities of incompatible changes to the derived property 137 value. More specifically, there could be changes that would make 138 previously-disallowed labels valid, previously-valid labels 139 disallowed, or that would be disruptive to IDNA's defining rule 140 structure. Consequently, IDNA2008 provided for an expert review of 141 each new version of Unicode with the possibility of providing 142 exceptions to the rules for particular new code points, code points 143 whose properties had changed, and newly-discovered issues with the 144 IDNA2008 collection of rules. When problems were identified, the 145 reviewer was expected to notify the IESG. The assumption was that 146 the IETF would review the situation and modify IDNA2008 as needed, 147 most likely by adding exceptions to preserve backward compatibility 148 (see Section 3.1 below). 150 For the convenience of the community, IDNA2008 also provided that 151 IANA would maintain copies of calculated tables resulting from each 152 review, showing the derived properties for each code point. Those 153 tables were expected to be helpful, especially to those without the 154 facilities to easily compute derived properties themselves. 155 Experience with the community and those tables has shown that they 156 have been confused with the normative tables of IDNA2003: the 157 IDNA2008 tables published by IANA have never been normative and 158 statements about IDNA2008 being out of date with regard to some 159 Unicode version because the IANA tables have not been updated are 160 incorrect or meaningless. 162 3. The Review Model 164 While the text has sometimes been interpreted differently, IDNA2008 165 actually calls for two types of review when a new Unicode version is 166 introduced. One is an algorithmic comparison of the set of derived 167 properties calculated from the new version of Unicode to the derived 168 properties calculated from the previous one to determine whether 169 incompatible changes have occurred. The other is a review of newly- 170 assigned code points to determine whether any of them require special 171 treatment (e.g., assignment of what IDNA2008 calls contextual rules) 172 and whether any of them violate any of the assumptions underlying the 173 IDNA2008 derived property calculations. Any of the cases of either 174 review might require either per-code point exceptions or other 175 adjustments to the rules for deriving properties that are part of RFC 176 5892. The subsections below provide a revised specification for the 177 review procedure. 179 Unless the IESG or the Designated Expert conclude that there are 180 special problems or unusual circumstances, these reviews will be 181 performed only for full Unicode versions (i.e., those numbered NN.0, 182 e.g., 12.0) and not for minor updates (e.g., 12.1). 184 3.1. Review Model Part I: Algorithmic Comparison 186 Section 5.1 of RFC 5892 is the description of the process for 187 creating the initial IANA tables. It is noteworthy that, while it 188 can be read as strongly implying new reviews and new tables for 189 versions of Unicode after 5.2, it does not explicitly specify those 190 reviews or, e.g., the timetable for completing them. It also 191 indicates that incompatibilities are to be "flagged for the IESG" but 192 does not specify exactly what the IESG is to do about them and when. 193 For reasons related to the other type of review and discussed below, 194 only one review was completed, documented [RFC6452], and a set of 195 corresponding new tables installed. That review, for Unicode 6.0, 196 found only three incompatibilities; the consensus was to ignore them 197 (not create exceptions in IDNA2008) and remain consistent with 198 computations based on current (Unicode 6.0) properties rather than 199 preserving backward compatibility within IDNA. The 2018 review (for 200 Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12] 201 also concluded that maintain Unicode compatibility, rather than IDNA 202 backward compatibility, should be maintained. That decision was 203 partially driven by the long period between reviews and the concern 204 that table calculations by others in the interim could result in 205 unexpected incompatibilities if derived property definitions where 206 then changed. See Section 4 for further discussion of these 207 preferences. 209 3.2. Review Model Part II: New Code Point Analysis 211 The second type of review is not clearly explained in RFC 5892, but 212 is intended to identify cases in which newly-added code points, or 213 perhaps even newly-discovered problematic older ones, violate design 214 assumptions of IDNA, identify defects in those assumptions, or are 215 inconsistent (from an IDNA perspective) with Unicode commitments 216 about assignment, properties, and stability of newly-added code 217 points. The discovery after Unicode 7.0 was released that new code 218 points were being added that were potentially visually equivalent, in 219 the same script, to previously-available code point sequences was one 220 example of the type of situation the review was expected to discover 221 (and did so [IAB-Unicode7-2015] [IDNA-Unicode7]). 223 Because multiple perspectives on Unicode and writing systems are 224 required, this review will not be successful unless done by a team -- 225 a single, all-knowing, Designated Expert is not feasible or likely to 226 produce an adequate analysis. It should also be recognized that, if 227 this review identifies a problem, that problem is likely to be 228 complex and/or involve multiple trade-offs. Actions to deal with it 229 are likely to be disruptive (although perhaps not to large 230 communities of users) or to leave either security risks 231 (opportunities for attacks and inadvertent confusion as expected 232 matches do not occur) or excessive reliance on registries 233 understanding and taking responsibility for what they are registering 234 [RFC5894] [RegRestr]. The latter, while a requirement of IDNA, has 235 often not worked out well in the past. 237 Because resolution of problems identified by this part of the review 238 may take some time even if that resolution is to add additional 239 contextual rules or disallow one or more code points, there will be 240 cases in which it will be appropriate to publish the results of the 241 algorithmic review and provide IANA with corresponding tables, with 242 warnings about code points whose status is uncertain until there are 243 IETF consensus conclusions about how to proceed. The affected code 244 points should be considered unsafe and identified as "under review" 245 in the IANA tables until final derived properties are assigned. 247 4. IDNA Assumptions and Current Practice 249 At the time the IDNA2008 documents were written, the assumption was 250 that, if new versions of Unicode introduced incompatible changes, the 251 Standard would be updated to preserve backward compatibility for 252 users of IDNA. For most purposes, this would be done by adding to 253 the table of exceptions associated with Rule G [RFC5892a]. 255 This has not been the practice in the reviews completed subsequent to 256 Unicode 5.2, as discussed in Section 3. Incompatibilities were 257 identified in Unicode 6.0 [RFC6452], in the cumulative review leading 258 to tables for Unicode 11.0 [ID.draft-faltstrom-unicode11] and the 259 subsequent one for Unicode 12.0 [IDNA-Unicode12]. In all of those 260 cases, the decision was made to maintain compatibility with Unicode 261 properties rather than with prior versions of IDNA. 263 Subsequent to the publication of this document, changes in Unicode 264 detected by algorithmic reviews that would break compatibility with 265 derived properties associated with prior versions of Unicode or that 266 preserve such compatibility within IDNA at the price of departing 267 from current Unicode specifications must be documented (in documents 268 expected to be published as standards track RFCs), explained to, and 269 reviewed by the IETF. 271 The community has now made decisions and updated tables for Unicode 272 6.0 [RFC6452], done catch-up work between it and Unicode 11.0 273 [ID.draft-faltstrom-unicode11], and completed the review and tables 274 for Unicode 12.0 [IDNA-Unicode12]. The decisions made in those cases 275 were driven by preserving consistency with Unicode and Unicode 276 property changes for reasons most clearly explained by the IAB 277 [IAB-Unicode-2018]. Doing things that way is not only at variance 278 with the language in RFC 5892 but is also inconsistent with the 279 intent of commitments to the registry and user communities to ensure 280 that IDN labels, once valid under IDNA2008, would remain valid and, 281 excepting those that were invalid because they contained unassigned 282 code points, those that were invalid remained invalid. 284 This document restores and clarifies that original language and 285 intent: absent extremely strong evidence on a per-code point basis 286 that preserving the validity status of possible existing (or 287 prohibited) labels would cause significant harm, Unicode changes that 288 would affect IDNA derived properties are to be reflected in IDNA 289 exceptions that preserves the status of those labels. There is one 290 partial exception to this principle. If the new code point analysis 291 (see Section 3.2) concludes that some code points or collections of 292 code points should be further analyzed, those code points, and labels 293 including them, should be considered unsafe and used only with 294 extreme caution because the conclusions of the analysis may change 295 their derived property values and status. 297 5. Derived Tables Published by IANA 299 As discussed above, RFC 5892 specified that derived property tables 300 be provided via an IANA registry. Perhaps because most IANA 301 registries are considered normative and authoritative, that registry 302 has been the source of considerable confusion, including the 303 incorrect assumption that the absence of published tables for 304 versions of Unicode later than 6.0 meant that IDNA could not be used 305 with later versions. That position was raised in multiple ways, not 306 all of them consistent, especially in the ICANN context 307 [ICANN-LGR-SLA]. 309 If the changes specified in this document are not successful in 310 significantly mitigating the confusion about the status of the tables 311 published by IANA, serious consideration should be given to 312 eliminating those tables entirely. 314 6. Editorial clarification to RFC 5892 316 In order to avoid this document going forward with remaining known 317 errors or omissions in RFC 5892, this section updates that document 318 to provide fixes to known applicable errata. In particular, verified 319 RFC Editor Erratum 3312 [RFC5892Erratum] provides a clarification to 320 Appendix A and Section A.1 of RFC 5892. That clarification is 321 resolved below. 323 1. In Appendix A, add a new paragraph after the paragraph that 324 begins "The code point...". The new paragraph should read: 326 "For the rule to be evaluated to True for the label, it MUST be 327 evaluated separately for every occurrence of the Code point in 328 the label; each of those evaluations must result in True." 330 2. In Appendix A, Section A.1, replace the "Rule Set" by 331 Rule Set: 332 False; 333 If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True; 334 If cp .eq. \u200C And 335 RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp 336 (Joining_Type:T)*(Joining_Type:{R,D})) Then True; 338 7. Acknowledgements 340 This document was inspired by extensive discussions within the I18N 341 Directorate of the IETF Applications and Real Time (ART) area in the 342 first quarter of 2019 about sorting out the reviews for Unicode 11.0 343 and 12.0. 345 8. IANA Considerations 347 For the algorithmic review described in Section 3.1, the IESG is to 348 appoint a Designated Expert [RFC8126] with appropriate expertise to 349 conduct the review and supply derived property tables to IANA. For 350 the code point review, the expertise will be supplied by an IESG- 351 designated expert team as discussed in Section 3.2. In both cases, 352 the experts should draw on the expertise of other members of the 353 community as needed. In particular, and especially if there is no 354 overlap in the people holding the various roles, coordination with 355 the IAB-appointed liaison to the Unicode Consortium will be essential 356 to mitigate possible errors due to confusion. 358 As discussed in Section 5, and if they have not already done so, IANA 359 is requested to modify the IDNA tables collection [IANA-IDNA-Tables] 360 to identify them clearly as non-normative and in a way that drops the 361 idea of a "current" or "correct" version of those tables, pointing to 362 this document for an explanation. That includes publishing and 363 retaining tables, as supplied by the IETF's Designated Expert, for 364 each new version of Unicode after this document is published, keeping 365 all older versions available. IANA is also also requested to change 366 the current title of that registry from "IDNA Parameters", which is 367 misleading, to "IDNA Rules and Derived Property Values". 369 The "Note" in that registry should also be revised to be consistent 370 with the above, perhaps to say: 372 "IDNA does not require that applications and libraries, either for 373 registration/storage or lookup, support any particular version of 374 Unicode. Instead, they are required to use derived property 375 values based on calculations associated with whatever version of 376 Unicode they are using elsewhere in the application or library. 377 For the convenience of application and library developers and 378 others, the IETF has supplied, and IANA maintains, derived 379 property tables for several version of Unicode as listed below. 380 It should be stressed that these are not normative that, in 381 principle, an application can do its own calculations and these 382 tables can change as IETF understanding evolves. By contrast, the 383 list of code points requiring contextual rules and the associated 384 rules are normative and should be treated as updates to the list 385 in RFC 5892." 387 As long as the intent is preserved, the specific text is at IANA's 388 discretion. 390 IANA's attention is called to the introduction, in Section 3.2, of a 391 temporary "under review" category to the PVALID, DISALLOWED, etc., 392 entries in the tables. 394 9. Security Considerations 396 Application of the procedures described in this document and 397 understanding of the clarifications it provides should reduce 398 confusion about IDNA requirements. Because past confusion has 399 provided opportunities for bad behavior, the effect of these changes 400 should improve Internet security to at least some small extent. 402 Because of the preference to keep the derived property value stable 403 (as specified in RFC 5892 and discussed in Section 4), the algorithm 404 used to calculate those derived properties does change as explained 405 in Section 3. If these changes are not taken into account, the 406 derived property value will change and the implications might have 407 negative consequences, in some cases with security implications. For 408 example, changes in the calculated derived property value for a code 409 point from either DISALLOWED to PVALID or from PVALID to DISALLOWED 410 can cause changes in label interpretation that would be visible and 411 confusing to end users and might enable attacks. 413 10. References 415 10.1. Normative References 417 [IANA-IDNA-Tables] 418 Internet Assigned Numbers Authority (IDNA), "IDNA 419 Parameters", March 2019, 420 . 423 This documents make changes to this registry and a way 424 that could change the title, the URL, or both. This 425 citation is to be version published on 2019-03-31. It may 426 be appropriate to supply a citation to the finished 427 version when this document is published. 429 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 430 Internationalized Domain Names for Applications (IDNA)", 431 RFC 5892, DOI 10.17487/RFC5892, August 2010, 432 . 434 [RFC5892a] 435 Faltstrom, P., Ed., "The Unicode Code Points and 436 Internationalized Domain Names for Applications (IDNA)", 437 RFC 5892, August 2010, 438 . 440 Section 2.7 442 [RFC5892Erratum] 443 "RFC5892, "The Unicode Code Points and Internationalized 444 Domain Names for Applications (IDNA)", August 2010, Errata 445 ID: 3312", Errata ID 3312, August 2012, 446 . 448 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 449 Writing an IANA Considerations Section in RFCs", BCP 26, 450 RFC 8126, DOI 10.17487/RFC8126, June 2017, 451 . 453 [Unicode] The Unicode Consortium, "The Unicode Standard (Current 454 Version)", 2019, 455 . 457 The link given will always access the current version of 458 the Unicode Standard, independent of its version number or 459 date. 461 [Unicode-properties] 462 The Unicode Consortium, "The Unicode Standard Version 463 11.0", 2018, 464 . 466 Section 3.5. 468 10.2. Informative References 470 [IAB-Unicode-2018] 471 Internet Architecture Board (IAB), "IAB Statement on 472 Identifiers and Unicode", March 2018, 473 . 477 [IAB-Unicode7-2015] 478 Internet Architecture Board (IAB), "IAB Statement on 479 Identifiers and Unicode 7.0.0", February 2015, 480 . 484 [ICANN-LGR-SLA] 485 Internet Corporation for Assigned Names and Numbers 486 (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN 487 Tables", June 2019, . 490 Captured 2019-06-12. In public comment until 2019-07-26. 492 [ID.draft-faltstrom-unicode11] 493 Faltstrom, P., "IDNA2008 and Unicode 11.0.0", March 2019, 494 . 497 [IDNA-Unicode12] 498 Faltstrom, P., "IDNA2008 and Unicode 12.0.0", March 2019, 499 . 502 This document is in the RFC Editor queue at of 2019-06-09. 503 Update to RFC reference if/when appropriate. 505 [IDNA-Unicode7] 506 Klensin, J. and P. Falstrom, "IDNA Update for Unicode 507 7.0.0", January 2015, . 510 Note that this is an historical reference to a superseded 511 document. There is nothing "in progress" about it. 513 [RegRestr] 514 Klensin, J. and A. Freytag, "Internationalized Domain 515 Names in Applications (IDNA): Registry Restrictions and 516 Recommendations", July 2019, 517 . 520 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 521 Internationalized Strings ("stringprep")", RFC 3454, 522 DOI 10.17487/RFC3454, December 2002, 523 . 525 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 526 "Internationalizing Domain Names in Applications (IDNA)", 527 RFC 3490, DOI 10.17487/RFC3490, March 2003, 528 . 530 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 531 Profile for Internationalized Domain Names (IDN)", 532 RFC 3491, DOI 10.17487/RFC3491, March 2003, 533 . 535 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 536 Recommendations for Internationalized Domain Names 537 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 538 . 540 [RFC5890] Klensin, J., "Internationalized Domain Names for 541 Applications (IDNA): Definitions and Document Framework", 542 RFC 5890, DOI 10.17487/RFC5890, August 2010, 543 . 545 [RFC5894] Klensin, J., "Internationalized Domain Names for 546 Applications (IDNA): Background, Explanation, and 547 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 548 . 550 [RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code 551 Points and Internationalized Domain Names for Applications 552 (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, 553 November 2011, . 555 Appendix A. Summary of Changes to RFC 5892 557 Other than the editorial correction specified in Section 6 all of the 558 changes in this document are concerned with the reviews for new 559 versions of Unicode and with the IANA Considerations in Section 5, 560 particularly Section 5.1, of RFC 5982. Whether the changes are 561 substantive or merely clarifications may be somewhat in the eye of 562 the beholder so the list below should not be assumed to be 563 comprehensive. At a very high level, this document clarifies that 564 two types of review were intended and separates them for clarity and 565 restores the original (but so far unobserved) default for actions 566 when code point derived properties change. For this reason, this 567 document effectively provides a replacement for Section 5.1 of RFC 568 5892 and adds or changes some material needed to have the replacement 569 be clear or make better sense. 571 Changes or clarifications that may be considered important include: 573 o Separated the new Unicode version review into two explicit parts 574 and provided for different review methods and, potentially, 575 asynchronous outcomes. 577 o Specified a review team, not a single expert, for the code point 578 review. 580 o Eliminated the de facto requirement for the (formerly single) 581 Designated Expert to be the same person as the IAB's Liaison to 582 the Unicode Consortium but called out the importance of 583 coordination. 585 o Created an explicit provision for an "under review" entry in the 586 IANA tables so that, if there is ever again a need to tell the 587 community to wait until the IETF sorts things out, that will be 588 about selected potentially problematic code points and not whole 589 Unicode versions. 591 o In part because Unicode is now on a regular one-year cycle rather 592 than producing major and minor versions as needed, to avoid 593 overloading the IETF's i18n resources, and to avoid generating and 594 storing IANA tables for trivial changes (e.g., the single new code 595 point in Unicode 12.1), the review procedure is applied only to 596 major versions of Unicode unless exceptional circumstances arise 597 and are identified. 599 Appendix B. Change Log 601 RFC Editor: Please remove this appendix before publication. 603 B.1. Changes from version -00 (2019-06-12) to -01 605 o Added a note about the relationship to draft-klensin-idna- 606 rfc5891bis. 608 o Adjusted references per discussion with RFC Editor. 610 o Minor editorial corrections and improvements. 612 B.2. Changes from version -01 (2019-07-06) to -02 614 o Removed an unnecessary reference and a duplicate one. 616 Authors' Addresses 618 John C Klensin 619 1770 Massachusetts Ave, Ste 322 620 Cambridge, MA 02140 621 USA 623 Phone: +1 617 245 1457 624 Email: john-ietf@jck.com 626 Patrik Faltstrom 627 Netnod 628 Franzengatan 5 629 Stockholm 112 51 630 Sweden 632 Phone: +46 70 6059051 633 Email: paf@netnod.se