Proposed change to the charter to do IDNAv2 instead of IDNA2008

[Harald Tveit Alvestrand]

I am against both the idea that "IDNAv2", as described below, is less 
complex to get right than "IDNAbis", and the idea that spending another 
6 months fiddling around with the spec is reasonable (even if we could 
hold to a timeline, which this group has been notoriously bad at). For 
one thing, that makes "IDNAv2" likely to be finished well after IDNs 
have been introduced in the root.

I think we're just about done, and should just sign on the dotted line.

(Note: due to holidays and recent developments at work, I have been 
unable to follow the discussions on the list since late December. I 
can't even promise to catch up soon.)

                    Harald Alvestrand

Paul Hoffman skrev:
> 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
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>