The IESG has approved the following document: - 'The Unicode code points and IDNA ' <draft-ietf-idnabis-tables-09.txt> as a Proposed Standard This document is the product of the Internationalized Domain Names in Applications, Revised Working Group. The IESG contact persons are Lisa Dusseault and Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idnabis-tables-09.txt 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]: 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 is informative and mappings is optional (Informational). 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. Readers will note that this is nearly 2010 but the new specifications bear the label IDNA2008 because the work was started in that year. 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 the 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. Implementation tactics for dealing with the old and new specifications may vary. Perfect backward compatibility with IDNA2003 was not possible (without simply replicating it, negating the rationale for the redefinition effort of IDNA2008). 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. Registries have several implementation choices including bundled registration of previously mapped and newly allowed characters or rejection of conflicting new registrations. 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 implementations.
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
