Greetings again. The response to the thread I started earlier on the proposed charter change were mostly positive. Given that, I have prepared what I think would be a new charter for the WG. I have retained as much of the current charter as seemed sensible.
Clearly, one of the things for the WG to consider is whether we want to go forwards with this charter revision, a different revision (to cover the trajectory of the current WG documents), or to change the current WG documents to match the current charter. All are possible, but I got the feeling from the response to my earlier posting that this would be the least contentious way forwards.
Thoughts?
--Paul Hoffman
[[ This is a proposed revision to the IDNAbis charter. ]]
Description of Working Group:
The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen ("-") in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNAv1").
These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified.
This WG is chartered to update IDNAv1 to the latest version of Unicode. In the update, called "IDNAv2", the WG will strictly follow three design goals:
- No current internationalized label label will change its bits-on-the-wire representation.
- Zones (particularly large registries) will not need to change the manner in which they register IDNs when IDNA2 is deployed.
- The only changes allowed to stringprep (RFC 3454) and Nameprep (RFC 3491) are additions for characters added after Unicode version 3.2, and changes to the bidirectional rules that allow labels that were prohibited under IDNAv1 that can safely be added to IDNAv2.
The constraints of the original IDN WG still apply to IDNAv2, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design.
This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers.
There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes.
While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work.
The work will update RFCs 3454, 3490, and 3491. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG.
Because the Unicode Consortium regularly comes out with new versions of the Unicode Standard, the WG will remain alive but dormant after IDNAv2 is issued. The WG can re-activate to create future versions of IDNA following the same guidelines as are described in this charter.
Goals and Milestones:
Feb 2009 First draft of document describing IDNAv2
May 2009 WG Last Call on IDNAv2
Jul 2009 IETF Last Call on IDNAv2