idnits 2.17.1 draft-klensin-idna-unicode-review-00.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 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (June 12, 2019) is 1773 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) == Unused Reference: 'RFC2119' is defined on line 420, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IDNA-Tables' -- Duplicate reference: RFC5892, mentioned in 'RFC5892Erratum', was also mentioned in 'RFC5892'. -- 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 10 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: December 14, 2019 June 12, 2019 8 IDNA Review for New Unicode Versions 9 draft-klensin-idna-unicode-review-00 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 December 14, 2019. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The standards for Internationalized Domain Names in Applications 81 (IDNA) require a review of each new version of Unicode to determine 82 whether incompatibilities with prior version or other issues exist 83 and, where appropriate, to allow the IETF to decide on the trade-offs 84 between compatibility with prior IDNA versions and compatibility with 85 Unicode [Unicode] going forward. That requirement, and its 86 relationship to tables maintained by IANA, has caused significant 87 confusion in the past. This document makes adjustments to the review 88 procedure based on nearly a decade of experience and updates IDNA, 89 specifically the document that specifies the relationship between 90 Unicode code points and IDNA derived properties [RFC5892], to reflect 91 those changes and clarify the various relationships involved. 93 Terminology note: In this document, "IDNA" refers to the current 94 version as described in RFC 5890 [RFC5890] and subsequent documents 95 and sometimes known as "IDNA2008". Distinctions between it and the 96 earlier version are explicit only where that is necessary to 97 understanding the relationships involved, e.g., in Section 2. 99 2. Brief History of IDNA Versions, the Review Requirement, and RFC 5982 101 The original, now-obsolete, version of IDNA, commonly known as 102 "IDNA2003" [RFC3490] [RFC3491] was defined in terms of a profile of a 103 collection of IETF-specific tables [RFC3454] that specified the 104 usability of each Unicode code point with IDNA. Because the tables 105 themselves were normative, they were intrinsically tied to a 106 particular version of Unicode. As Unicode evolved, the standard 107 would either have required a new version for each new version of 108 Unicode or it would fall further and further behind. 110 When that version of IDNA was superseded by the current one, known as 111 IDNA2008 [RFC5890], a different strategy, one that was property-based 112 rather than table-based, was adopted for a number of reasons of which 113 the reliance on normative tables was not dominant [RFC4690]. In the 114 IDNA2008 model, the use of normative tables was replaced by a set of 115 procedures and rules that operated on Unicode properties 116 [Unicode-properties] and a few internal definitions to determine the 117 category and status, and hence an IDNA-specific "derived property", 118 for any given code point. Those rules are, in principle, independent 119 of Unicode versions. They can be applied to any version of Unicode, 120 at least from approximately version 5.0 forward, to yield an 121 appropriate set of derived properties. However, the working group 122 that defined IDNA2008 recognized that not all of the Unicode 123 properties were completely stable and that, because the criteria for 124 new code points and property assignment used by the Unicode 125 Consortium might not precisely align with the needs of IDNA, there 126 were possibilities of incompatible changes to the derived property 127 value. More specifically, there could be changes that would make 128 previously-disallowed labels valid, previously-valid labels 129 disallowed, or that would be disruptive to IDNA's defining rule 130 structure. Consequently, IDNA2008 provided for an expert review of 131 each new version of Unicode with the possibility of providing 132 exceptions to the rules for particular new code points, code points 133 whose properties had changed, and newly-discovered issues with the 134 IDNA2008 collection of rules. When problems were identified, the 135 reviewer was expected to notify the IESG. The assumption was that 136 the IETF would review the situation and modify IDNA2008 as needed, 137 most likely by adding exceptions to preserve backward compatibility 138 (see Section 3.1 below). 140 For the convenience of the community, IDNA2008 also provided that 141 IANA would maintain copies of calculated tables resulting from each 142 review, showing the derived properties for each code point. Those 143 tables were expected to be helpful, especially to those without the 144 facilities to easily compute derived properties themselves. 145 Experience with the community and those tables has shown that they 146 have been confused with the normative tables of IDNA2003: the 147 IDNA2008 tables published by IANA have never been normative and 148 statements about IDNA2008 being out of date with regard to some 149 Unicode version because the IANA tables have not been updated are 150 incorrect or meaningless. 152 3. The Review Model 154 While the text has sometimes been interpreted differently, IDNA2008 155 actually calls for two types of review when a new Unicode version is 156 introduced. One is an algorithmic comparison of the set of derived 157 properties calculated from the new version of Unicode to the derived 158 properties calculated from the previous one to determine whether 159 incompatible changes have occurred. The other is a review of newly- 160 assigned code points to determine whether any of them require special 161 treatment (e.g., assignment of what IDNA2008 calls contextual rules) 162 and whether any of them violate any of the assumptions underlying the 163 IDNA2008 derived property calculations. Any of the cases of either 164 review might require either per-code point exceptions or other 165 adjustments to the rules for deriving properties that are part of RFC 166 5892. The subsections below provide a revised specification for the 167 review procedure. 169 Unless the IESG or the Designated Expert conclude that there are 170 special problems or unusual circumstances, these reviews will be 171 performed only for full Unicode versions (i.e., those numbered NN.0, 172 e.g., 12.0) and not for minor updates (e.g., 12.1). 174 3.1. Review Model Part I: Algorithmic Comparison 176 Section 5.1 of RFC 5892 is the description of the process for 177 creating the initial IANA tables. It is noteworthy that, while it 178 can be read as strongly implying new reviews and new tables for 179 versions of Unicode after 5.2, it does not explicitly specify those 180 reviews or, e.g., the timetable for completing them. It also 181 indicates that incompatibilities are to be "flagged for the IESG" but 182 does not specify exactly what the IESG is to do about them and when. 183 For reasons related to the other type of review and discussed below, 184 only one review was completed, documented [RFC6452], and a set of 185 corresponding new tables installed. That review, for Unicode 6.0, 186 found only three incompatibilities; the consensus was to ignore them 187 (not create exceptions in IDNA2008) and remain consistent with 188 computations based on current (Unicode 6.0) properties rather than 189 preserving backward compatibility within IDNA. The 2018 review (for 190 Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12] 191 also concluded that maintain Unicode compatibility, rather than IDNA 192 backward compatibility, should be maintained. That decision was 193 partially driven by the long period between reviews and the concern 194 that table calculations by others in the interim could result in 195 unexpected incompatibilities if derived property definitions where 196 then changed. See Section 4 for further discussion of these 197 preferences. 199 3.2. Review Model Part II: New Code Point Analysis 201 The second type of review is not clearly explained in RFC 5892, but 202 is intended to identify cases in which newly-added code points, or 203 perhaps even newly-discovered problematic older ones, violate design 204 assumptions of IDNA, identify defects in those assumptions, or are 205 inconsistent (from an IDNA perspective) with Unicode commitments 206 about assignment, properties, and stability of newly-added code 207 points. The discovery after Unicode 7.0 was released that new code 208 points were being added that were potentially visually equivalent, in 209 the same script, to previously-available code point sequences was one 210 example of the type of situation the review was expected to discover 211 (and did so [IAB-Unicode7-2015] [IDNA-Unicode7]). 213 Because multiple perspectives on Unicode and writing systems are 214 required, this review will not be successful unless done by a team -- 215 a single, all-knowing, Designated Expert is not feasible or likely to 216 produce an adequate analysis. It should also be recognized that, if 217 this review identifies a problem, that problem is likely to be 218 complex and/or involve multiple trade-offs. Actions to deal with it 219 are likely to be disruptive (although perhaps not to large 220 communities of users) or to leave either security risks 221 (opportunities for attacks and inadvertent confusion as expected 222 matches do not occur) or excessive reliance on registries 223 understanding and taking responsibility for what they are registering 224 [RFC5894] [RegRestr]. The latter, while a requirement of IDNA, has 225 often not worked out well in the past. 227 Because resolution of problems identified by this part of the review 228 may take some time even if that resolution is to add additional 229 contextual rules or disallow one or more code points, there will be 230 cases in which it will be appropriate to publish the results of the 231 algorithmic review and provide IANA with corresponding tables, with 232 warnings about code points whose status is uncertain until there are 233 IETF consensus conclusions about how to proceed. The affected code 234 points should be considered unsafe and identified as "under review" 235 in the IANA tables until final derived properties are assigned. 237 4. IDNA Assumptions and Current Practice 239 At the time the IDNA2008 documents were written, the assumption was 240 that, if new versions of Unicode introduced incompatible changes, the 241 Standard would be updated to preserve backward compatibility for 242 users of IDNA. For most purposes, this would be done by adding to 243 the table of exceptions associated with Rule G (Section 2.7 of RFC 244 5892). 246 This has not been the practice in the reviews completed subsequent to 247 Unicode 5.2, as discussed in Section 3. Incompatibilities were 248 identified in Unicode 6.0 [RFC6452], in the cumulative review leading 249 to tables for Unicode 11.0 [ID.draft-faltstrom-unicode11] and the 250 subsequent one for Unicode 12.0 [IDNA-Unicode12]. In all of those 251 cases, the decision was made to maintain compatibility with Unicode 252 properties rather than with prior versions of IDNA. 254 Subsequent to the publication of this document, changes in Unicode 255 detected by algorithmic reviews that would break compatibility with 256 derived properties associated with prior versions of Unicode or that 257 preserve such compatibility within IDNA at the price of departing 258 from current Unicode specifications must be documented (in documents 259 expected to be published as standards track RFCs), explained to, and 260 reviewed by the IETF. 262 The community has now made decisions and updated tables for Unicode 263 6.0 [RFC6452], done catch-up work between it and Unicode 11.0 264 [ID.draft-faltstrom-unicode11], and completed the review and tables 265 for Unicode 12.0 [IDNA-Unicode12]. The decisions made in those cases 266 were driven by preserving consistency with Unicode and Unicode 267 property changes for reasons most clearly explained by the IAB 268 [IAB-Unicode-2018]. Doing things that way is not only at variance 269 with the language in RFC 5892 but is also inconsistent with the 270 intent of commitments to the registry and user communities to ensure 271 that IDN labels, once valid under IDNA2008, would remain valid and, 272 excepting those that were invalid because they contained unassigned 273 code points, those that were invalid remained invalid. 275 This document restores and clarifies that original language and 276 intent: absent extremely strong evidence on a per-code point basis 277 that preserving the validity status of possible existing (or 278 prohibited) labels would cause significant harm, Unicode changes that 279 would affect IDNA derived properties are to be reflected in IDNA 280 exceptions that preserves the status of those labels. There is one 281 partial exception to this principle. If the new code point analysis 282 (see Section 3.2) concludes that some code points or collections of 283 code points should be further analyzed, those code points, and labels 284 including them, should be considered unsafe and used only with 285 extreme caution because the conclusions of the analysis may change 286 their derived property values and status. 288 5. Derived Tables Published by IANA 290 As discussed above, RFC 5892 specified that derived property tables 291 be provided via an IANA registry. Perhaps because most IANA 292 registries are considered normative and authoritative, that registry 293 has been the source of considerable confusion, including the 294 incorrect assumption that the absence of published tables for 295 versions of Unicode later than 6.0 meant that IDNA could not be used 296 with later versions. That position was raised in multiple ways, not 297 all of them consistent, especially in the ICANN context 298 [ICANN-LGR-SLA]. 300 If the changes specified in this document are not successful in 301 significantly mitigating the confusion about the status of the tables 302 published by IANA, serious consideration should be given to 303 eliminating those tables entirely. 305 6. Editorial clarification to RFC 5892 307 In order to avoid this document going forward with remaining known 308 errors or omissions in RFC 5892, this section updates that document 309 to provide fixes to known applicable errata. In particular, verified 310 RFC Editor Erratum 3312 [RFC5892Erratum] provides a clarification to 311 Appendix A and Section A.1 of RFC 5892, which is resolved below. 313 1. In Appendix A, add a new paragraph after the paragraph that 314 begins "The code point...". The new paragraph should read: 316 "For the rule to be evaluated to True for the label, it MUST be 317 evaluated separately for every occurrence of the Code point in 318 the label; each of those evaluations must result in True." 320 2. In Appendix A, Section A.1, replace the "Rule Set" by 322 Rule Set: 323 False; 324 If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True; 325 If cp .eq. \u200C And 326 RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp 327 (Joining_Type:T)*(Joining_Type:{R,D})) Then True; 329 7. Acknowledgements 331 This document was inspired by extensive discussions within the I18N 332 Directorate of the IETF Applications and Real Time (ART) area in the 333 first quarter of 2019 about sorting out the reviews for Unicode 11.0 334 and 12.0. 336 8. IANA Considerations 338 For the algorithmic review described in Section 3.1, the IESG is to 339 appoint a Designated Expert [RFC8126] with appropriate expertise to 340 conduct the review and supply derived property tables to IANA. For 341 the code point review, the expertise will be supplied by an IESG- 342 designated expert team as discussed in Section 3.2. In both cases, 343 the experts should draw on the expertise of other members of the 344 community as needed. In particular, and especially if there is no 345 overlap in the people holding the various roles, coordination with 346 the IAB-appointed liaison to the Unicode Consortium will be essential 347 to mitigate possible errors due to confusion. 349 As discussed in Section 5, and if they have not already done so, IANA 350 is requested to modify the IDNA tables collection [IANA-IDNA-Tables] 351 to identify them clearly as non-normative and in a way that drops the 352 idea of a "current" or "correct" version of those tables, pointing to 353 this document for an explanation. That includes publishing and 354 retaining tables, as supplied by the IETF's Designated Expert, for 355 each new version of Unicode after this document is published, keeping 356 all older versions available. IANA is also also requested to change 357 the current title of that registry from "IDNA Parameters", which is 358 misleading, to "IDNA Rules and Derived Property Values". 360 The "Note" in that registry should also be revised to be consistent 361 with the above, perhaps to say: 363 "IDNA does not require that applications and libraries, either for 364 registration/storage or lookup, support any particular version of 365 Unicode. Instead, they are required to use derived property 366 values based on calculations associated with whatever version of 367 Unicode they are using elsewhere in the application or library. 368 For the convenience of application and library developers and 369 others, the IETF has supplied, and IANA maintains, derived 370 property tables for several version of Unicode as listed below. 371 It should be stressed that these are not normative that, in 372 principle, an application can do its own calculations and these 373 tables can change as IETF understanding evolves. By contrast, the 374 list of code points requiring contextual rules and the associated 375 rules are normative and should be treated as updates to the list 376 in RFC 5892." 378 As long as the intent is preserved, the specific text is at IANA's 379 discretion. 381 IANA's attention is called to the introduction, in Section 3.2, of a 382 temporary "under review" category to the PVALID, DISALLOWED, etc., 383 entries in the tables. 385 9. Security Considerations 387 Application of the procedures described in this document and 388 understanding of the clarifications it provides should reduce 389 confusion about IDNA requirements. Because past confusion has 390 provided opportunities for bad behavior, the effect of these changes 391 should improve Internet security to at least some small extent. 393 Because of the preference to keep the derived property value stable 394 (as specified in RFC 5892 and discussed in Section 4), the algorithm 395 used to calculate those derived properties does change as explained 396 in Section 3. If these changes are not taken into account, the 397 derived property value will change and the implications might have 398 negative consequences, in some cases with security implications. For 399 example, changes in the calculated derived property value for a code 400 point from either DISALLOWED to PVALID or from PVALID to DISALLOWED 401 can cause changes in label interpretation that would be visible and 402 confusing to end users and might enable attacks. 404 10. References 406 10.1. Normative References 408 [IANA-IDNA-Tables] 409 Internet Assigned Numbers Authority (IDNA), "IDNA 410 Parameters", March 2019, 411 . 414 This documents make changes to this registry and a way 415 that could change the title, the URL, or both. This 416 citation is to be version published on 2019-03-31. It may 417 be appropriate to supply a citation to the finished 418 version when this document is published. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 426 Internationalized Domain Names for Applications (IDNA)", 427 RFC 5892, DOI 10.17487/RFC5892, August 2010, 428 . 430 [RFC5892Erratum] 431 "RFC5892, "The Unicode Code Points and Internationalized 432 Domain Names for Applications (IDNA)", August 2010, Errata 433 ID: 3312", Errata ID 3312, August 2012, 434 . 436 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 437 Writing an IANA Considerations Section in RFCs", BCP 26, 438 RFC 8126, DOI 10.17487/RFC8126, June 2017, 439 . 441 [Unicode] The Unicode Consortium, "The Unicode Standard (Current 442 Version)", 2019, 443 . 445 The link given will always access the current version of 446 the Unicode Standard, independent of its version number or 447 date. 449 [Unicode-properties] 450 The Unicode Consortium, "The Unicode Standard Version 451 11.0", 2018, 452 . 454 Section 3.5. 456 10.2. Informative References 458 [IAB-Unicode-2018] 459 Internet Architecture Board (IAB), "IAB Statement on 460 Identifiers and Unicode", March 2018, 461 . 465 [IAB-Unicode7-2015] 466 Internet Architecture Board (IAB), "IAB Statement on 467 Identifiers and Unicode 7.0.0", February 2015, 468 . 472 [ICANN-LGR-SLA] 473 Internet Corporation for Assigned Names and Numbers 474 (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN 475 Tables", June 2019, . 478 Captured 2019-06-12. In public comment until 2019-07-26. 480 [ID.draft-faltstrom-unicode11] 481 Faltstrom, P., "IDNA2008 and Unicode 11.0.0", March 2019, 482 . 485 [IDNA-Unicode12] 486 Faltstrom, P., "IDNA2008 and Unicode 12.0.0", March 2019, 487 . 490 This document is in the RFC Editor queue at of 2019-06-09. 491 Update to RFC reference if/when appropriate. 493 [IDNA-Unicode7] 494 Klensin, J. and P. Falstrom, "IDNA Update for Unicode 495 7.0.0", January 2015, . 498 Note that this is an historical reference to a superseded 499 document. There is nothing "in progress" about it. 501 [RegRestr] 502 Klensin, J. and A. Freytag, "Internationalized Domain 503 Names in Applications (IDNA): Registry Restrictions and 504 Recommendations", September 2017, 505 . 508 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 509 Internationalized Strings ("stringprep")", RFC 3454, 510 DOI 10.17487/RFC3454, December 2002, 511 . 513 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 514 "Internationalizing Domain Names in Applications (IDNA)", 515 RFC 3490, DOI 10.17487/RFC3490, March 2003, 516 . 518 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 519 Profile for Internationalized Domain Names (IDN)", 520 RFC 3491, DOI 10.17487/RFC3491, March 2003, 521 . 523 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 524 Recommendations for Internationalized Domain Names 525 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 526 . 528 [RFC5890] Klensin, J., "Internationalized Domain Names for 529 Applications (IDNA): Definitions and Document Framework", 530 RFC 5890, DOI 10.17487/RFC5890, August 2010, 531 . 533 [RFC5894] Klensin, J., "Internationalized Domain Names for 534 Applications (IDNA): Background, Explanation, and 535 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 536 . 538 [RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code 539 Points and Internationalized Domain Names for Applications 540 (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, 541 November 2011, . 543 Appendix A. Summary of Changes to RFC 5892 545 Other than the editorial correction specified in Section 6 all of the 546 changes in this document are concerned with the reviews for new 547 versions of Unicode and with the IANA Considerations in Section 5, 548 particularly Section 5.1, of RFC 5982. Whether the changes are 549 substantive or merely clarifications may be somewhat in the eye of 550 the beholder so the list below should not be assumed to be 551 comprehensive. At a very high level, this document clarifies that 552 two types of review were intended and separates them for clarity and 553 restores the original (but so far unobserved) default for actions 554 when code point derived properties change. For this reason, this 555 document effectively provides a replacement for Section 5.1 of RFC 556 5892 and adds or changes some material needed to have the replacement 557 be clear or make better sense. 559 Changes or clarifications that may be considered important include: 561 o Separated the new Unicode version review into two explicit parts 562 and provided for different review methods and, potentially, 563 asynchronous outcomes. 565 o Specified a review team, not a single expert, for the code point 566 review. 568 o Eliminated the de facto requirement for the (formerly single) 569 Designated Expert to be the same person as the IAB's Liaison to 570 the Unicode Consortium but called out the importance of 571 coordination. 573 o Created an explicit provision for an "under review" entry in the 574 IANA tables so that, if there is ever again a need to tell the 575 community to wait until the IETF sorts things out, that will be 576 about selected potentially problematic code points and not whole 577 Unicode versions. 579 o In part because Unicode is now on a regular one-year cycle rather 580 than producing major and minor versions as needed, to avoid 581 overloading the IETF's i18n resources, and to avoid generating and 582 storing IANA tables for trivial changes (e.g., the single new code 583 point in Unicode 12.1), the review procedure is applied only to 584 major versions of Unicode unless exceptional circumstances arise 585 and are identified. 587 Authors' Addresses 589 John C Klensin 590 1770 Massachusetts Ave, Ste 322 591 Cambridge, MA 02140 592 USA 594 Phone: +1 617 245 1457 595 Email: john-ietf@jck.com 597 Patrik Faltstrom 598 Netnod 599 Franzengatan 5 600 Stockholm 112 51 601 Sweden 603 Phone: +46 70 6059051 604 Email: paf@netnod.se