idnits 2.17.1 draft-klensin-idna-unicode-review-05.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 345: '...ated to True for the label, it MUST be...' -- The draft header indicates that this document updates RFC589, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC589, updated by this document, for RFC5378 checks: 1973-11-01) -- 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 (November 03, 2019) is 1630 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 1766 (Obsoleted by RFC 3066, RFC 3282) -- 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 (==), 12 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: 589 (if approved) P. Faltstrom 5 Intended status: Standards Track Netnod 6 Expires: May 6, 2020 November 03, 2019 8 IDNA Review for New Unicode Versions 9 draft-klensin-idna-unicode-review-05 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 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 May 6, 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 . . . . . . . 5 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 . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. Summary of Changes to RFC 5892 . . . . . . . . . . . 13 76 Appendix B. Background and Rationale for Expert Review Procedure 77 for New Code Point Analysis . . . . . . . . . . . . 14 78 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 79 C.1. Changes from version -00 (2019-06-12) to -01 . . . . . . 15 80 C.2. Changes from version -01 (2019-07-06) to -02 . . . . . . 16 81 C.3. Changes from version -02 (2019-07-22) to -03 . . . . . . 16 82 C.4. Changes from version -03 (2019-08-29) to -04 . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 The standards for Internationalized Domain Names in Applications 88 (IDNA) require a review of each new version of Unicode to determine 89 whether incompatibilities with prior versions or other issues exist 90 and, where appropriate, to allow the IETF to decide on the trade-offs 91 between compatibility with prior IDNA versions and compatibility with 92 Unicode [Unicode] going forward. That requirement, and its 93 relationship to tables maintained by IANA, has caused significant 94 confusion in the past (see Section 3 and Section 4 for additional 95 discussion of the question of appropriate decisions and the history 96 of these reviews). This document makes adjustments to the review 97 procedure based on nearly a decade of experience and updates IDNA, 98 specifically the document that specifies the relationship between 99 Unicode code points and IDNA derived properties [RFC5892], to reflect 100 those changes and clarify the various relationships involved. 102 This specification does not change the requirement that registries, 103 at all levels of the DNS tree, take responsibility for the labels 104 they are inserting in the DNS, a level of responsibility that 105 requires allowing only a subset of the code points and strings 106 allowed by the IDNA protocol itself. That requirement is discussed 107 in more detail in a companion document [RegRestr]. 109 Terminology note: In this document, "IDNA" refers to the current 110 version as described in RFC 5890 [RFC5890] and subsequent documents 111 and sometimes known as "IDNA2008". Distinctions between it and the 112 earlier version are explicit only where that is necessary to 113 understanding the relationships involved, e.g., in Section 2. 115 2. Brief History of IDNA Versions, the Review Requirement, and RFC 5982 117 The original, now-obsolete, version of IDNA, commonly known as 118 "IDNA2003" [RFC3490] [RFC3491], was defined in terms of a profile of 119 a collection of IETF-specific tables [RFC3454] that specified the 120 usability of each Unicode code point with IDNA. Because the tables 121 themselves were normative, they were intrinsically tied to a 122 particular version of Unicode. As Unicode evolved, the standard 123 would either have required a new version for each new version of 124 Unicode or it would fall further and further behind. 126 When that version of IDNA was superseded by the current one, known as 127 IDNA2008 [RFC5890], a different strategy, one that was property-based 128 rather than table-based, was adopted for a number of reasons of which 129 the reliance on normative tables was not dominant [RFC4690]. In the 130 IDNA2008 model, the use of normative tables was replaced by a set of 131 procedures and rules that operated on Unicode properties 132 [Unicode-properties] and a few internal definitions to determine the 133 category and status, and hence an IDNA-specific "derived property", 134 for any given code point. Those rules are, in principle, independent 135 of Unicode versions. They can be applied to any version of Unicode, 136 at least from approximately version 5.0 forward, to yield an 137 appropriate set of derived properties. However, the working group 138 that defined IDNA2008 recognized that not all of the Unicode 139 properties were completely stable and that, because the criteria for 140 new code points and property assignment used by the Unicode 141 Consortium might not precisely align with the needs of IDNA, there 142 were possibilities of incompatible changes to the derived property 143 value. More specifically, there could be changes that would make 144 previously-disallowed labels valid, previously-valid labels 145 disallowed, or that would be disruptive to IDNA's defining rule 146 structure. Consequently, IDNA2008 provided for an expert review of 147 each new version of Unicode with the possibility of providing 148 exceptions to the rules for particular new code points, code points 149 whose properties had changed, and newly-discovered issues with the 150 IDNA2008 collection of rules. When problems were identified, the 151 reviewer was expected to notify the IESG. The assumption was that 152 the IETF would review the situation and modify IDNA2008 as needed, 153 most likely by adding exceptions to preserve backward compatibility 154 (see Section 3.1 below). 156 For the convenience of the community, IDNA2008 also provided that 157 IANA would maintain copies of calculated tables resulting from each 158 review, showing the derived properties for each code point. Those 159 tables were expected to be helpful, especially to those without the 160 facilities to easily compute derived properties themselves. 161 Experience with the community and those tables has shown that they 162 have been confused with the normative tables of IDNA2003: the 163 IDNA2008 tables published by IANA have never been normative and 164 statements about IDNA2008 being out of date with regard to some 165 Unicode version because the IANA tables have not been updated are 166 incorrect or meaningless. 168 3. The Review Model 170 While the text has sometimes been interpreted differently, IDNA2008 171 actually calls for two types of review when a new Unicode version is 172 introduced. One is an algorithmic comparison of the set of derived 173 properties calculated from the new version of Unicode to the derived 174 properties calculated from the previous one to determine whether 175 incompatible changes have occurred. The other is a review of newly- 176 assigned code points to determine whether any of them require special 177 treatment (e.g., assignment of what IDNA2008 calls contextual rules) 178 and whether any of them violate any of the assumptions underlying the 179 IDNA2008 derived property calculations. Any of the cases of either 180 review might require either per-code point exceptions or other 181 adjustments to the rules for deriving properties that are part of RFC 182 5892. The subsections below provide a revised specification for the 183 review procedure. 185 Unless the IESG or the Designated Expert conclude that there are 186 special problems or unusual circumstances, these reviews will be 187 performed only for major Unicode versions (those numbered NN.0, e.g., 188 12.0) and not for minor updates (e.g., 12.1). 190 As can be seen in the detailed descriptions in the following 191 sections, proper review will require a team of experts that has both 192 broad and specific skills in reviewing Unicode characters and their 193 properties in relation to both the written standards and operational 194 needs. The IESG will need to appoint experts who can draw on the 195 broader community to obtain the necessary skills for particular 196 situations. See the IANA Considerations (Section 8) for details. 198 3.1. Review Model Part I: Algorithmic Comparison 200 Section 5.1 of RFC 5892 is the description of the process for 201 creating the initial IANA tables. It is noteworthy that, while it 202 can be read as strongly implying new reviews and new tables for 203 versions of Unicode after 5.2, it does not explicitly specify those 204 reviews or, e.g., the timetable for completing them. It also 205 indicates that incompatibilities are to be "flagged for the IESG" but 206 does not specify exactly what the IESG is to do about them and when. 207 For reasons related to the other type of review and discussed below, 208 only one review was completed, documented [RFC6452], and a set of 209 corresponding new tables installed. That review, for Unicode 6.0, 210 found only three incompatibilities; the consensus was to ignore them 211 (not create exceptions in IDNA2008) and remain consistent with 212 computations based on current (Unicode 6.0) properties rather than 213 preserving backward compatibility within IDNA. The 2018 review (for 214 Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12] 215 also concluded that Unicode compatibility, rather than IDNA backward 216 compatibility, should be maintained. That decision was partially 217 driven by the long period between reviews and the concern that table 218 calculations by others in the interim could result in unexpected 219 incompatibilities if derived property definitions where then changed. 220 See Section 4 for further discussion of these preferences. 222 3.2. Review Model Part II: New Code Point Analysis 224 The second type of review is not clearly explained in RFC 5892, but 225 is intended to identify cases in which newly-added code points, or 226 perhaps even newly-discovered problematic older ones, violate design 227 assumptions of IDNA, identify defects in those assumptions, or are 228 inconsistent (from an IDNA perspective) with Unicode commitments 229 about assignment, properties, and stability of newly-added code 230 points. The discovery after Unicode 7.0 was released that new code 231 points were being added that were potentially visually equivalent, in 232 the same script, to previously-available code point sequences was one 233 example of the type of situation the review was expected to discover 234 (and did so [IAB-Unicode7-2015] [IDNA-Unicode7]). 236 Because multiple perspectives on Unicode and writing systems are 237 required, this review will not be successful unless done by a team -- 238 a single, all-knowing, Designated Expert is not feasible or likely to 239 produce an adequate analysis. Rather than any single expert being 240 the sole source of analysis, the designated expert team needs to 241 understand that there will always be gaps in their knowledge, to know 242 what they don't know, and to work to find the expertise that each 243 review requires. It is also important that the DE team maintains 244 close contact with the Area Directors and that the ADs remain aware 245 of the team's changing needs, reviewing and adjusting the team's 246 membership over time, with periodic reviews at least annually. It 247 should also be recognized that, if this review identifies a problem, 248 that problem is likely to be complex and/or involve multiple trade- 249 offs. Actions to deal with it are likely to be disruptive (although 250 perhaps not to large communities of users) or to leave either 251 security risks (opportunities for attacks and inadvertent confusion 252 as expected matches do not occur) or excessive reliance on registries 253 understanding and taking responsibility for what they are registering 254 [RFC5894] [RegRestr]. The latter, while a requirement of IDNA, has 255 often not worked out well in the past. 257 Because resolution of problems identified by this part of the review 258 may take some time even if that resolution is to add additional 259 contextual rules or disallow one or more code points, there will be 260 cases in which it will be appropriate to publish the results of the 261 algorithmic review and provide IANA with corresponding tables, with 262 warnings about code points whose status is uncertain until there are 263 IETF consensus conclusions about how to proceed. The affected code 264 points should be considered unsafe and identified as "under review" 265 in the IANA tables until final derived properties are assigned. 267 4. IDNA Assumptions and Current Practice 269 At the time the IDNA2008 documents were written, the assumption was 270 that, if new versions of Unicode introduced incompatible changes, the 271 Standard would be updated to preserve backward compatibility for 272 users of IDNA. For most purposes, this would be done by adding to 273 the table of exceptions associated with Rule G [RFC5892a]. 275 This has not been the practice in the reviews completed subsequent to 276 Unicode 5.2, as discussed in Section 3. Incompatibilities were 277 identified in Unicode 6.0 [RFC6452], in the cumulative review leading 278 to tables for Unicode 11.0 [ID.draft-faltstrom-unicode11]. In all of 279 those cases, the decision was made to maintain compatibility with 280 Unicode properties rather than with prior versions of IDNA. 282 Subsequent to the publication of this document, changes in Unicode 283 detected by algorithmic reviews that would break compatibility with 284 derived properties associated with prior versions of Unicode or that 285 preserve such compatibility within IDNA at the price of departing 286 from current Unicode specifications must be documented (in documents 287 expected to be published as standards track RFCs), explained to, and 288 reviewed by the IETF. 290 The community has now made decisions and updated tables for Unicode 291 6.0 [RFC6452], done catch-up work between it and Unicode 11.0 292 [ID.draft-faltstrom-unicode11], and completed the review and tables 293 for Unicode 12.0 [IDNA-Unicode12]. The decisions made in those cases 294 were driven by preserving consistency with Unicode and Unicode 295 property changes for reasons most clearly explained by the IAB 296 [IAB-Unicode-2018]. Doing things that way is not only at variance 297 with the language in RFC 5892 but is also inconsistent with 298 commitments to the registry and user communities to ensure that IDN 299 labels, once valid under IDNA2008, would remain valid and, excepting 300 those that were invalid because they contained unassigned code 301 points, those that were invalid remained invalid. 303 This document restores and clarifies that original language and 304 intent: absent extremely strong evidence on a per-code point basis 305 that preserving the validity status of possible existing (or 306 prohibited) labels would cause significant harm, Unicode changes that 307 would affect IDNA derived properties are to be reflected in IDNA 308 exceptions that preserve the status of those labels. There is one 309 partial exception to this principle. If the new code point analysis 310 (see Section 3.2) concludes that some code points or collections of 311 code points should be further analyzed, those code points, and labels 312 including them, should be considered unsafe and used only with 313 extreme caution because the conclusions of the analysis may change 314 their derived property values and status. 316 5. Derived Tables Published by IANA 318 As discussed above, RFC 5892 specified that derived property tables 319 be provided via an IANA registry. Perhaps because most IANA 320 registries are considered normative and authoritative, that registry 321 has been the source of considerable confusion, including the 322 incorrect assumption that the absence of published tables for 323 versions of Unicode later than 6.0 meant that IDNA could not be used 324 with later versions. That position was raised in multiple ways, not 325 all of them consistent, especially in the ICANN context 326 [ICANN-LGR-SLA]. 328 If the changes specified in this document are not successful in 329 significantly mitigating the confusion about the status of the tables 330 published by IANA, serious consideration should be given to 331 eliminating those tables entirely. 333 6. Editorial clarification to RFC 5892 335 In order to avoid this document going forward with remaining known 336 errors or omissions in RFC 5892, this section updates that document 337 to provide fixes to known applicable errata. In particular, verified 338 RFC Editor Erratum 3312 [RFC5892Erratum] provides a clarification to 339 Appendix A and Section A.1 of RFC 5892. That clarification is 340 resolved below. 342 1. In Appendix A, add a new paragraph after the paragraph that 343 begins "The code point...". The new paragraph should read: 345 "For the rule to be evaluated to True for the label, it MUST be 346 evaluated separately for every occurrence of the Code point in 347 the label; each of those evaluations must result in True." 349 2. In Appendix A, Section A.1, replace the "Rule Set" by 351 Rule Set: 352 False; 353 If Canonical_Combining_Class(Before(cp)) .eq. Virama 354 Then True; 355 If cp .eq. \u200C And 356 RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp 357 (Joining_Type:T)*(Joining_Type:{R,D})) Then True; 359 7. Acknowledgements 361 This document was inspired by extensive discussions within the I18N 362 Directorate of the IETF Applications and Real Time (ART) area in the 363 first quarter of 2019 about sorting out the reviews for Unicode 11.0 364 and 12.0. Careful reviews by Joel Halpern and text suggestions from 365 Barry Leiba resulted in some clarifications. 367 Thanks to Christopher Wood for catching some editorial errors that 368 persisted until rather late in the draft's life cycle and to Benjamin 369 Kaduk for catching and raising a number of questions during Last 370 Call. Some of the issues they raised have been reflected in the 371 document; others did appear to be desirable modifications after 372 further discussion but the questions were definitely worth raising 373 and discussion. 375 8. IANA Considerations 377 For the algorithmic review described in Section 3.1, the IESG is to 378 appoint a Designated Expert [RFC8126] with appropriate expertise to 379 conduct the review and supply derived property tables to IANA. As 380 provided in Section 5.2 of the Guidelines for Writing IANA 381 Considerations [RFC8126], the Designated Expert is expected to 382 consult additional sources of expertise as needed. For the code 383 point review, the expertise will be supplied by an IESG-designated 384 expert team as discussed in Section 3.2 and Appendix B. In both 385 cases, the experts should draw on the expertise of other members of 386 the community as needed. In particular, and especially if there is 387 no overlap in the people holding the various roles, coordination with 388 the IAB-appointed liaison to the Unicode Consortium will be essential 389 to mitigate possible errors due to confusion. 391 As discussed in Section 5, and if they have not already done so, IANA 392 is requested to modify the IDNA tables collection [IANA-IDNA-Tables] 393 to identify them clearly as non-normative and in a way that drops the 394 idea of a "current" or "correct" version of those tables, pointing to 395 this document for an explanation. That includes publishing and 396 retaining tables, as supplied by the IETF's Designated Expert, for 397 each new version of Unicode after this document is published, keeping 398 all older versions available. IANA is also requested to change the 399 current title of that registry from "IDNA Parameters", which is 400 misleading, to "IDNA Rules and Derived Property Values". 402 The "Note" in that registry should also be revised to be consistent 403 with the above, perhaps to say: 405 "IDNA does not require that applications and libraries, either for 406 registration/storage or lookup, support any particular version of 407 Unicode. Instead, they are required to use derived property 408 values based on calculations associated with whatever version of 409 Unicode they are using elsewhere in the application or library. 410 For the convenience of application and library developers and 411 others, the IETF has supplied, and IANA maintains, derived 412 property tables for several version of Unicode as listed below. 413 It should be stressed that these are not normative in that, in 414 principle, an application can do its own calculations and these 415 tables can change as IETF understanding evolves. By contrast, the 416 list of code points requiring contextual rules and the associated 417 rules are normative and should be treated as updates to the list 418 in RFC 5892." 420 As long as the intent is preserved, the specific text is at IANA's 421 discretion. 423 IANA's attention is called to the introduction, in Section 3.2, of a 424 temporary "under review" category to the PVALID, DISALLOWED, etc., 425 entries in the tables. 427 9. Security Considerations 429 Application of the procedures described in this document and 430 understanding of the clarifications it provides should reduce 431 confusion about IDNA requirements. Because past confusion has 432 provided opportunities for bad behavior, the effect of these changes 433 should improve Internet security to at least some small extent. 435 Because of the preference to keep the derived property value stable 436 (as specified in RFC 5892 and discussed in Section 4), the algorithm 437 used to calculate those derived properties does change as explained 438 in Section 3. If these changes are not taken into account, the 439 derived property value will change and the implications might have 440 negative consequences, in some cases with security implications. For 441 example, changes in the calculated derived property value for a code 442 point from either DISALLOWED to PVALID or from PVALID to DISALLOWED 443 can cause changes in label interpretation that would be visible and 444 confusing to end users and might enable attacks. 446 10. References 448 10.1. Normative References 450 [IANA-IDNA-Tables] 451 Internet Assigned Numbers Authority (IDNA), "IDNA 452 Parameters", March 2019, 453 . 456 This documents make changes to this registry and a way 457 that could change the title, the URL, or both. This 458 citation is to be version published on 2019-03-31. It may 459 be appropriate to supply a citation to the finished 460 version when this document is published. 462 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 463 Internationalized Domain Names for Applications (IDNA)", 464 RFC 5892, DOI 10.17487/RFC5892, August 2010, 465 . 467 [RFC5892a] 468 Faltstrom, P., Ed., "The Unicode Code Points and 469 Internationalized Domain Names for Applications (IDNA)", 470 RFC 5892, August 2010, 471 . 473 Section 2.7 475 [RFC5892Erratum] 476 "RFC5892, "The Unicode Code Points and Internationalized 477 Domain Names for Applications (IDNA)", August 2010, Errata 478 ID: 3312", Errata ID 3312, August 2012, 479 . 481 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 482 Writing an IANA Considerations Section in RFCs", BCP 26, 483 RFC 8126, DOI 10.17487/RFC8126, June 2017, 484 . 486 [Unicode] The Unicode Consortium, "The Unicode Standard (Current 487 Version)", 2019, 488 . 490 The link given will always access the current version of 491 the Unicode Standard, independent of its version number or 492 date. 494 [Unicode-properties] 495 The Unicode Consortium, "The Unicode Standard Version 496 11.0", 2018, 497 . 499 Section 3.5. 501 10.2. Informative References 503 [IAB-Unicode-2018] 504 Internet Architecture Board (IAB), "IAB Statement on 505 Identifiers and Unicode", March 2018, 506 . 510 [IAB-Unicode7-2015] 511 Internet Architecture Board (IAB), "IAB Statement on 512 Identifiers and Unicode 7.0.0", February 2015, 513 . 517 [ICANN-LGR-SLA] 518 Internet Corporation for Assigned Names and Numbers 519 (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN 520 Tables", June 2019, . 523 Captured 2019-06-12. In public comment until 2019-07-26. 525 [ID.draft-faltstrom-unicode11] 526 Faltstrom, P., "IDNA2008 and Unicode 11.0.0", March 2019, 527 . 530 [IDNA-Unicode12] 531 Faltstrom, P., "IDNA2008 and Unicode 12.0.0", March 2019, 532 . 535 This document is in the RFC Editor queue at of 2019-06-09. 536 Update to RFC reference if/when appropriate. 538 [IDNA-Unicode7] 539 Klensin, J. and P. Falstrom, "IDNA Update for Unicode 540 7.0.0", January 2015, . 543 Note that this is an historical reference to a superseded 544 document. There is nothing "in progress" about it. 546 [RegRestr] 547 Klensin, J. and A. Freytag, "Internationalized Domain 548 Names in Applications (IDNA): Registry Restrictions and 549 Recommendations", July 2019, 550 . 553 [RFC1766] Alvestrand, H., "Tags for the Identification of 554 Languages", RFC 1766, DOI 10.17487/RFC1766, March 1995, 555 . 557 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 558 DOI 10.17487/RFC3282, May 2002, 559 . 561 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 562 Internationalized Strings ("stringprep")", RFC 3454, 563 DOI 10.17487/RFC3454, December 2002, 564 . 566 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 567 "Internationalizing Domain Names in Applications (IDNA)", 568 RFC 3490, DOI 10.17487/RFC3490, March 2003, 569 . 571 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 572 Profile for Internationalized Domain Names (IDN)", 573 RFC 3491, DOI 10.17487/RFC3491, March 2003, 574 . 576 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 577 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 578 2003, . 580 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 581 Recommendations for Internationalized Domain Names 582 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 583 . 585 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 586 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 587 September 2009, . 589 [RFC5890] Klensin, J., "Internationalized Domain Names for 590 Applications (IDNA): Definitions and Document Framework", 591 RFC 5890, DOI 10.17487/RFC5890, August 2010, 592 . 594 [RFC5894] Klensin, J., "Internationalized Domain Names for 595 Applications (IDNA): Background, Explanation, and 596 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 597 . 599 [RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code 600 Points and Internationalized Domain Names for Applications 601 (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, 602 November 2011, . 604 Appendix A. Summary of Changes to RFC 5892 606 Other than the editorial correction specified in Section 6 all of the 607 changes in this document are concerned with the reviews for new 608 versions of Unicode and with the IANA Considerations in Section 5, 609 particularly Section 5.1, of RFC 5982. Whether the changes are 610 substantive or merely clarifications may be somewhat in the eye of 611 the beholder so the list below should not be assumed to be 612 comprehensive. At a very high level, this document clarifies that 613 two types of review were intended and separates them for clarity and 614 restores the original (but so far unobserved) default for actions 615 when code point derived properties change. For this reason, this 616 document effectively provides a replacement for Section 5.1 of RFC 617 5892 and adds or changes some material needed to have the replacement 618 be clear or make better sense. 620 Changes or clarifications that may be considered important include: 622 o Separated the new Unicode version review into two explicit parts 623 and provided for different review methods and, potentially, 624 asynchronous outcomes. 626 o Specified a review team, not a single expert, for the code point 627 review. 629 o Eliminated the de facto requirement for the (formerly single) 630 Designated Expert to be the same person as the IAB's Liaison to 631 the Unicode Consortium but called out the importance of 632 coordination. 634 o Created an explicit provision for an "under review" entry in the 635 IANA tables so that, if there is ever again a need to tell the 636 community to wait until the IETF sorts things out, that will be 637 about selected potentially problematic code points and not whole 638 Unicode versions. 640 o In part because Unicode is now on a regular one-year cycle rather 641 than producing major and minor versions as needed, to avoid 642 overloading the IETF's i18n resources, and to avoid generating and 643 storing IANA tables for trivial changes (e.g., the single new code 644 point in Unicode 12.1), the review procedure is applied only to 645 major versions of Unicode unless exceptional circumstances arise 646 and are identified. 648 Appendix B. Background and Rationale for Expert Review Procedure for 649 New Code Point Analysis 651 The Expert Review for New Code Point Analysis provided for above is 652 somewhat unusual compared to the examples presented in the Guidelines 653 for Writing IANA Considerations [RFC8126]. This appendix provides an 654 explanation of that choice and the background for it. 656 Development of specifications to support use of languages and writing 657 systems other than English (and Latin Script) -- so-called 658 "internationalization" or "i18n" -- has always been problematic in 659 the IETF, especially when requirements go beyond simple coding of 660 characters (e.g., RFC 3629 [RFC3629]) or simple identification of 661 languages (e.g., RFC 3282 [RFC3282] and the earlier RFC 1766 662 [RFC1766]). A good deal of specialized knowledge is required, 663 knowledge that comes from multiple fields and that requires multiple 664 perspectives. The work is not obviously more complex than routing, 665 especially if one assumes that routing work requires a solid 666 foundation in graph theory or network optimization, or than security 667 and cryptography, but people working in those areas are drawn to the 668 IETF and people from the fields that bear on internationalization 669 typically are not. 671 One result is that we have several times thought we understood a 672 problem, generated a specification or set of specifications, and then 673 been surprised when unanticipated (by the IETF) issues arose and we 674 needed to go back and at least tune and often revise. The language 675 tag work that started with RFC 1766 is a good example of this: 676 broader considerations and requirements led to later work and a much 677 more complex and finer-grained system [RFC5646] 679 Work on IDNs further increased the difficulties because many of the 680 decisions that led to the current version of IDNA require 681 understanding the DNS and its constraints and, to at least some 682 extent, the commercial market in domain names including various ICANN 683 efforts. 685 The net result of these factors is that it is extremely unlikely that 686 the IESG will ever find an Expert Reviewer whose knowledge and 687 understanding will include everything that is required. 689 Consequently, Section 8 and other discussions in this document 690 specify a review team with the expectation that the members of the 691 team will, together, have have a broad enough perspective, collection 692 of expertise, and access to information and community to consult, so 693 as to be able to do a review and make consensus recommendations that 694 will serve the Internet well. While we anticipate that the team will 695 have one or more leaders, this differs from the suggestions in 696 Section 5.2 of the Guidelines for Writing IANA Considerations 697 [RFC8126] by not leaving whether or not a team exists or how it is 698 consulted to the discretion of the designated expert nor is the 699 expert solely accountable to the community. A team that contains 700 multiple perspectives is required, the team members are accountable 701 as a group, and any non-trivial recommendations require team 702 consensus. This also differs from the common practice in the IETF of 703 "review teams" from which a single member is selected to perform a 704 review: the principle for these reviews is team effort. 706 Appendix C. Change Log 708 RFC Editor: Please remove this appendix before publication. 710 C.1. Changes from version -00 (2019-06-12) to -01 712 o Added a note about the relationship to draft-klensin-idna- 713 rfc5891bis. 715 o Adjusted references per discussion with RFC Editor. 717 o Minor editorial corrections and improvements. 719 C.2. Changes from version -01 (2019-07-06) to -02 721 o Removed an unnecessary reference and a duplicate one. 723 C.3. Changes from version -02 (2019-07-22) to -03 725 o Addition of text to Section 3 to clarify IESG responsibilities. 727 o Very small editorial changes in response to AD review. 729 C.4. Changes from version -03 (2019-08-29) to -04 731 o Added Appendix B to describe the reasoning and details of the 732 review team for New Code Point Analysis and slightly updated the 733 IANA Considerations section to point to it. 735 o Corrections for editorial problems identified after IETF Last 736 Call. 738 Authors' Addresses 740 John C Klensin 741 1770 Massachusetts Ave, Ste 322 742 Cambridge, MA 02140 743 USA 745 Phone: +1 617 245 1457 746 Email: john-ietf@jck.com 748 Patrik Faltstrom 749 Netnod 750 Franzengatan 5 751 Stockholm 112 51 752 Sweden 754 Phone: +46 70 6059051 755 Email: paf@netnod.se