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