Proposed change to the charter to do IDNAv2 instead of IDNA2008

[Mark Davis]

Hmmm. If this were to go forward (and I have no sense of which direction the
WG leans), I would not want to lose some of the valuable work that was done
in the WG, like the expanded bidi rules that Harald and others came up with
to avoid (as much as possible) the bidi reordering problems, or the work
that Patrik has done with tables, or the work that John has done with
clarifying the definitions of terms and how they interrelate. (And not
discounting the contributions that others have made in feedback on these
docs.)

That is, if the WG leans this way, I would at least like to see a document
as a part of the charter with recommendations to avoid labels that don't
qualify under the rules we have developed in the tables and bidi documents,
and which utilizes where possible the definitional framework that John has
developed.

Mark


On Thu, Jan 22, 2009 at 14:01, Paul Hoffman <phoffman at imc.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090122/07e97243/attachment.htm