Proposed change to the charter to do IDNAv2 instead of IDNA2008

[Paul Hoffman]

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