Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
RFC 5890
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21 |
13 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2015-10-14 |
13 | (System) | Notify list changed from idnabis-chairs@ietf.org, draft-ietf-idnabis-defs@ietf.org to (None) |
2010-08-04 |
13 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2010-08-04 |
13 | Cindy Morgan | [Note]: 'RFC 5890' added by Cindy Morgan |
2010-08-04 |
13 | (System) | RFC published |
2010-01-12 |
13 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2010-01-11 |
13 | (System) | IANA Action state changed to No IC from In Progress |
2010-01-11 |
13 | (System) | IANA Action state changed to In Progress |
2010-01-11 |
13 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-01-11 |
13 | Amy Vezza | IESG has approved the document |
2010-01-11 |
13 | Amy Vezza | Closed "Approve" ballot |
2010-01-08 |
13 | (System) | Removed from agenda for telechat - 2010-01-07 |
2010-01-07 |
13 | Cindy Morgan | State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan |
2010-01-07 |
13 | (System) | New version available: draft-ietf-idnabis-defs-13.txt |
2010-01-07 |
13 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
2010-01-07 |
13 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-01-07 |
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2010-01-07 |
13 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-01-07 |
13 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2010-01-07 |
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2010-01-07 |
13 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2010-01-06 |
13 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2010-01-06 |
13 | Tim Polk | [Ballot comment] Section 2.3.1, para 4 s/(see U-labels turns out to be/(see U-labels) turns out to be/ |
2010-01-05 |
13 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-01-04 |
13 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2010-01-04 |
13 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-01-02 |
13 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2010-01-02 |
13 | Ralph Droms | [Ballot comment] I think it would improve the clarity of draft-ietf-idnabis-defs to check on the meaning of the phrase "these documents" throughout and replace, as … [Ballot comment] I think it would improve the clarity of draft-ietf-idnabis-defs to check on the meaning of the phrase "these documents" throughout and replace, as appropriate, "these documents" with "the IDNA2008 documents". For example, in this sentence from the third paragraph of section 2.2: These documents generally use the term "domain name". it wasn't clear to me whether "these documents" refer to RFC 103[45] or the IDNA2008 documents. |
2009-12-27 |
13 | Alexey Melnikov | [Ballot comment] 1.3. Roadmap of IDNA2008 Documents o A specification [IDNA2008-Tables] of the categories and rules that identify the code points … [Ballot comment] 1.3. Roadmap of IDNA2008 Documents o A specification [IDNA2008-Tables] of the categories and rules that identify the code points allowed in a label written in native character form (defined more specifically as a "U-label" in Section 2.3.2.1 below), based on Unicode 5.1 [Unicode51] code [IDNA2008-Tables] is using Unicode 5.2 now, so the two documents need to be consistent. point assignments and additional rules unique to IDNA2008. The Unicode-based rules are expected to be stable across Unicode updates and hence independent of Unicode versions. That specification obsoletes RFC 3941 and IDN use of the tables to which it refers. It is referred to informally in other documents in the set as "Tables". 2.3.1. LDH-label A consequence of the restrictions on valid characters in the native Unicode character form (see U-labels turns out to be that mixed-case Missing ")" after "U-labels"? annotation, of the sort outlined in RFC 3492 Appendix A [RFC3492], is never useful. Therefore, since a valid A-label is the result of Punycode encoding of a U-label, A-labels should be produced only in lower case, despite matching other (mixed- or upper-case) potential labels in the DNS. 2.3.2.1. IDNA-valid strings, A-label, and U-label o A "U-label" is an IDNA-valid string of Unicode characters, in normalization form NFC and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). What is "standard" here? Are non-UTF-8 encodings relevant for IDNA documents? A.12. Version -11 o Adjusted Acknowledgments to remove Mark Davis's name, per his request and advice from IETF Trust Counsel. Some clarification of what has happened here would be helpful (and how is this relevant to IETF Trust Counsel). |
2009-12-27 |
13 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-12-20 |
13 | Lisa Dusseault | Placed on agenda for telechat - 2010-01-07 by Lisa Dusseault |
2009-12-20 |
13 | Lisa Dusseault | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lisa Dusseault |
2009-12-20 |
13 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault |
2009-12-20 |
13 | Lisa Dusseault | Ballot has been issued by Lisa Dusseault |
2009-12-20 |
13 | Lisa Dusseault | Created "Approve" ballot |
2009-10-26 |
12 | (System) | New version available: draft-ietf-idnabis-defs-12.txt |
2009-10-22 |
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Paul Hoffman. |
2009-10-15 |
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-10-07 |
13 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have no IANA Actions. |
2009-10-03 |
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2009-10-03 |
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2009-10-01 |
13 | Cindy Morgan | Last call sent |
2009-10-01 |
13 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2009-10-01 |
13 | Lisa Dusseault | State Changes to Last Call Requested from In Last Call by Lisa Dusseault |
2009-10-01 |
13 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2009-10-01 |
13 | Lisa Dusseault | Intended Status has been changed to Proposed Standard from Draft Standard |
2009-09-29 |
13 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-09-28 |
13 | Lisa Dusseault | State Changes to Last Call Requested from AD Evaluation by Lisa Dusseault |
2009-09-28 |
13 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2009-09-28 |
13 | (System) | Ballot writeup text was added |
2009-09-28 |
13 | (System) | Last call text was added |
2009-09-28 |
13 | (System) | Ballot approval text was added |
2009-09-28 |
13 | Lisa Dusseault | IDNABIS - Internationalized Domain Names for Applications Document Shepherd Write-up for the IESG 1a. The document shepherd for the ensemble of six IDNABIS documents is … IDNABIS - Internationalized Domain Names for Applications Document Shepherd Write-up for the IESG 1a. The document shepherd for the ensemble of six IDNABIS documents is Vinton Cerf, also serving as the WG chair. I have personally reviewed each document and consulted with the WG and the document editors and believe these documents are now ready for AD and IESG consideration for release as RFCs. The documents are: (i) Definitions: draft-ietf-idnabis-defs-11.txt (ii) Protocol: draft-ietf-idnabis-protocol-16.txt (iii) Bi-Di: draft-ietf-idnabis-bidi-06a.txt (iv) Tables: draft-ietf-idnabis-tables-07.txt (v) Rationale: draft-ietf-idnabis-rationale-13.txt (vi) Mappings: draft-ietf-idnabis-mappings-04.txt Of these, Definitions, Protocol, Bi-Di and Tables are normative; Rationale and mappings are non-normative documents but part of the proposed standard ensemble. 1b. The initial impetus for the revisiting of the IDNA2003 proposed standards emerged in written form in RFC4690. An informal technical team worked to develop a framework for consideration which was later discussed, edited, and ratified to create the IDNABIS working group in 2008. The documents resulting from the IDNABIS Working Group effort have been extensively discussed over a two year period by the WG and by interested parties especially language experts in the Chinese, Japanese and Hangul spaces, speakers of Hebrew, Indic languages as well as a working group of expert Arabic speakers. The WG has had the participation of several Unicode consortium representatives including the chairman of the UTC. It should not surprise the IESG that there was controversy during the development of these documents and at best a rough consensus has formed around the recommendations. There continue to be some parties who resist the results. I think the two years of work have been more than sufficient - arguments have been revisited multiple times with the same outcomes. 1c. I do not believe that it is necessary to seek additional review by specialist parties. The working group had a great deal of representation from many perspectives and many volunteered their comments (some coming in at the last moment during WG last call - not surprisingly). The last call was effectively extended to last a month owing to discussions and substantive contributions arriving during this period and rough consensus has been reached on the documents as they are now composed. 1d. There was an impasse relating to mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label [please see the Definitions document]. This was resolved by introducing a non-normative "mappings" document observing ways in which this aspect of dealing with internationalized domain names might be approached. The principal rationale for re-visiting the IDNA2003 recommendations arose from field experience and a recommendation from the IAB [RFC4690]. A major objective was to re-specify the standard in such a way as to make it independent of changes to the Unicode code set (something that evolves more or less continuously). The method for achieving this is to use the Unicode properties feature (per code-point/character) to determine whether the code point should be allowed, disallowed or used only under certain conditions in domain name labels. There remains the problem of deployment in a world of web servers, browsers and other applications using domain names that may have already implemented the IDNA2003 recommendations. The IESG may encounter implementation tactics for dealing with the old and new specifications that are controversial. Perfect backward compatibility with IDNA2003 was not possible (without simply replicating it, negating the rationale for the redefinition effort of IDNA2008). IESG members will note that this is 2009 but the new specifications bear the label IDNA2008 because the work was started in that year. This is particularly true of the special characters "esszet" or "sharp-S" used in German and the "final sigma" used in Greek. These were mapped into other valid Unicode characters under IDNA2003 but allowed in IDNA2008 because the Unicode code points for these were introduced in the interim between IDNA2003 and IDNA2008 standardization efforts. The treatment of languages that are expressed in Right-to-Left form (see "Bi-Di" document) has been revised relative to IDNA2003 and it is believed that the revision is clearer and more precise in its form and limitations on the use of numeric characters, for example. An IPR disclosure statement has not been filed. I am not aware of any claims to IPR associated with any of the documents and proposed standards. 1e. The consensus behind these documents is based in part on the observation that repeated revisiting of issues produced the same results. There are still parties who are not in complete agreement with the results but after the introduction of the mapping document and considerable debate about its nature, much of the controversy was resolved, leading the chairman to declare that a reasonable basis for consensus existed. There remain a small number of parties who resist the outcomes but the bulk of the working group appears to be in agreement with or supportive of the results. Application of the proposed standards will face the problem of existing IDNA2003-conformant implementations. There is reported to be an apparent desire among browser implementers to avoid double DNS lookups under each framework. The simple fact of non-uniform propagation of IDNA2008-conformant implementations in all software that needs to be aware of and processs Internationalized Domain Names adds to the likelihood of various DNS-using implementations that are i) IDNA-unaware, ii) IDNA2003-aware only or IDNA2008 and IDNA2003 aware. 1f. There has been no overt threat of appeal. See (1d) however regarding implementation tactics and vendor response to the new IDNA2008 specifications. 1g. As far as I can determine, these documents meet all I-D criteria. 1h. The document ensemble is split into normative and informational parts, as outlined in (1a). All documents are ready for advancement as Proposed Standards. No previous RFCs are affected except for those associated with IDNA2003 [RFC3490]. In particular, there is no change to the use of Punycode [RFC3492] and neither Nameprep [RFC3491] nor Stringprep [RFC3454] are used in IDNA2008. 1i. IANA sections exist as required. As per IDNA2003, IANA will need to generate tables reflecting the application of the IDNA2008 Tables rules to the current Unicode release. In particular, reference is drawn to Sections 5.1 and 5.2 of the Tables document, reproduced below for convenience: 5.1. IDNA derived property value registry IANA is to keep a list of the derived property for the versions of Unicode that is released after (and including) version 5.1. The derived property value is to be calculated according to the specifications in sections Section 2 and Section 3 and not by copying the non-normative table found in Appendix B. Changes to the rules, including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty), require IETF Review, as described in [RFC5226] 5.2. IDNA Context Registry For characters that are defined in the IDNA Character Registry list as CONTEXTO or CONTEXTJ and therefore requiring a contextual rule IANA will create and maintain a list of approved contextual rules. Additions or changes to these rules require IETF Review, as described in [RFC5226]. A table from which that registry can be initialized, and some further discussion, appears in Appendix A. 1j. The Tables document does not require automatic evaluation of formulas 1k. Document Announcement draft Technical Summary The Internationalized Domain Names for Applications (IDNA) revisions are intended to reduce significantly IDNA dependency on specific versions of the Unicode character coding system. The Working Group produced the following documents representing a revision to the earlier "IDNA2003" proposed standard [only RFC 3490 is specifically affected]: [Note to RFC Editor: these references should be replaced with their RFC counterparts when the documents are approved for release by the IESG] Definitions: draft-ietf-idnabis-defs-11.txt Protocol: draft-ietf-idnabis-protocol-16.txt Bi-Di: draft-ietf-idnabis-bidi-06a.txt Tables: draft-ietf-idnabis-tables-07.txt Rationale: draft-ietf-idnabis-rationale-13.txt Mappings: draft-ietf-idnabis-mappings-04.txt Of these, Definitions, Protocol, Bi-Di and Tables are normative; Rationale and mappings are non-normative documents but part of the proposed standard ensemble. Working Group Summary The initial impetus for the revisiting of the IDNA2003 proposed standards emerged in written form in RFC4690. An informal technical team worked to develop a framework for consideration that was later discussed, edited, and ratified to create the IDNABIS working group in 2008. The documents resulting from the IDNABIS Working Group effort have been extensively discussed over a two year period by the WG and by interested parties especially language experts in the Chinese, Japanese and Hangul spaces, speakers of Hebrew, Indic languages as well as a working group of expert Arabic speakers. The WG has had the participation of several Unicode consortium representatives. There was controversy during the development of these documents but a rough consensus has formed around the recommendations. There was an impasse relating to mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label [please see the Definitions document]. This was resolved by introducing a non-normative "mappings" document observing ways in which this aspect of dealing with internationalized domain names might be approached. The principal rationale for re-visiting the IDNA2003 recommendations arose from field experience and a recommendation from the IAB [RFC4690]. A major objective was to re-specify the standard in such a way as to make it independent of changes to the Unicode code set (something that evolves more or less continuously). The method for achieving this is to use the Unicode properties feature (per code-point/character) to determine whether the code point should be allowed, disallowed or used only under certain conditions in domain name labels. There remains the problem of deployment in a world of web servers, browsers and other applications using domain names that may have already implemented the IDNA2003 recommendations. The IESG may encounter implementation tactics for dealing with the old and new specifications that are controversial. Perfect backward compatibility with IDNA2003 was not possible (without simply replicating it, negating the rationale for the redefinition effort of IDNA2008). IESG members will note that this is 2009 but the new specifications bear the label IDNA2008 because the work was started in that year. This is particularly true of the special characters "esszet" or "sharp-S" used in German and the "final sigma" used in Greek. These were mapped into other valid Unicode characters under IDNA2003 but allowed in IDNA2008 because the Unicode code points for these were introduced in the interim between IDNA2003 and IDNA2008 standardization efforts. The treatment of languages that are expressed in Right-to-Left form (see "Bi-Di" document) has been revised relative to IDNA2003 and it is believed that the revision is clearer and more precise in its form and limitations on the use of numeric characters, for example. Document Quality There are test implementations of the rules proposed by IDNA2008 but no released operational software. Such implementations have awaited the achievement of rough consensus on the controversial parts of the new proposals. Inputs from special expert bodies such as a Korean expert language group, an informal Arabic speakers group, and a number of individual commentators from the Unicode community, among others, have contributed to the documents as they now exist. Multiple implementations of the Tables rules have confirmed the stability of the definitions under distinct implementation. |
2009-09-28 |
13 | Lisa Dusseault | Draft Added by Lisa Dusseault in state AD Evaluation |
2009-09-14 |
11 | (System) | New version available: draft-ietf-idnabis-defs-11.txt |
2009-08-09 |
10 | (System) | New version available: draft-ietf-idnabis-defs-10.txt |
2009-06-23 |
09 | (System) | New version available: draft-ietf-idnabis-defs-09.txt |
2009-03-09 |
08 | (System) | New version available: draft-ietf-idnabis-defs-08.txt |
2009-03-06 |
07 | (System) | New version available: draft-ietf-idnabis-defs-07.txt |
2009-02-21 |
06 | (System) | New version available: draft-ietf-idnabis-defs-06.txt |
2008-12-11 |
05 | (System) | New version available: draft-ietf-idnabis-defs-05.txt |
2008-12-09 |
04 | (System) | New version available: draft-ietf-idnabis-defs-04.txt |
2008-11-28 |
03 | (System) | New version available: draft-ietf-idnabis-defs-03.txt |
2008-11-18 |
02 | (System) | New version available: draft-ietf-idnabis-defs-02.txt |
2008-11-02 |
01 | (System) | New version available: draft-ietf-idnabis-defs-01.txt |
2008-10-14 |
00 | (System) | New version available: draft-ietf-idnabis-defs-00.txt |