Proposed Charter for the IDNAbis Working Group

Mark Davis mark.davis at icu-project.org
Wed Mar 26 16:06:34 CET 2008 

Looks very good.

Mark

On Wed, Mar 26, 2008 at 4:08 AM, Vint Cerf <vint at google.com> wrote:

> Ladies and gentlemen,
>
> on the basis of the several weeks of exchanges on this list, a draft
> charter for the IDNAbis Working Group has emerged. It is enclosed
> below and as the proposed chair, I ask the participants in the IDNA-
> update distribution list to confirm adoption of the charter. If there
> are no strong objections, I request that Area Directors Lisa
> Dusseault and Chris Newman put the charter forward to the IESG for
> its approval. Needless to say, I am grateful to all of you who have
> contributed to the production of this charter in the past several
> weeks, most particularly john klensin, paul hoffman, martin duerst,
> patrik fältström, mark davis, harald alvestrand, stephane bortzmeyer,
> erik van der poel, jefsey morfin, simon josefsson, lisa dusseault,
> among many others. Apologies if I missed adding your name to the list
> - it was starting to get kind of long.
>
> I look forward to what I hope will be rapid progress of this working
> group towards the production of RFCs documenting improvements to the
> IDNA protocols.
>
> Vint Cerf
>
>
> -------------
>
>
> IDNABIS Charter
>
> Chair(s):  Vinton G. Cerf
>
> Applications Area Directors:
>
> Lisa Dusseault (ldusseault at commerce.net)
> Chris Newman (Chris.Newman at sun.com)
>
> Applications Area Advisor:
>
> Lisa Dusseault (ldusseault at commerce.net)
>
> Mailing List:
>
> General Discussion: idna-update at alvestrand.no
> To Subscribe:
> http://www.alvestrand.no/mailman/listinfo/idna-update
> Archive: http://www.alvestrand.no/pipermail/idna-update/
>
> Description:
>
> The original Internationalized Domain Name (IDN) WG set the
> requirements for international characters in domain names in
> RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003).
> 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 a number of real or perceived defects or
> inadequacies with the protocol.
>
> This WG is chartered to untie IDNA from specific versions of
> Unicode using algorithms that define validity based on Unicode
> properties.  It is recognized that some explicit exceptions may
> be necessary in any case, but attempts would be made to
> minimize these exceptions.
>
> Additional goals:
>
>   - Separate requirements for valid IDNs at registration time
>     (insertion of names into DNS zone files), vs. at resolution
>        time (looking up those names)
>
>   - Review, and, as necessary revise, the algorithms and rules
>     for handling right to left character sequences in an IDN
>        context to allow labels based on additional scripts and
>        languages and to make presentation as predictable as
>        reasonably possible.
>
>   - Permit effective use of some scripts that were
>        inadvertently excluded by the original protocols.
>
>   - Ensure practical stability of validity algorithms for
>     IDNs.
>
> The constraints of the original IDN WG still apply to IDNABIS,
> 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
> basic 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.
>
> The work is initially organized as four documents: overview and
> rationale, protocol, table algorithm, and changes to the
> bidirectional algorithm. These documents are to be used as the basis
> for the discussion of the general direction of the work.
>
> This working group will be providing extended public review of
> the output of a design team that has been working on the issues
> described below. This review-based approach is being used in
> part because of the way the work was undertaken by the team; in
> particular, the design team has been working with IETF
> visibility and has solicited and received significant amounts
> of technical review already.  If the public review provided by
> this Working Group confirms the basic method outlined in the
> input documents, it is expected that the working group will be
> able to provide any needed changes and close in a short period
> of time.  If technical issues arise that indicate a
> fundamentally different approach must be taken, it is
> anticipated that this working group would close, and a new one
> with an appropriate charter would be considered.
>
> This work will address stable and unambiguous IDN identifiers.
> There are a variety of unsolvable problems, notably the problem
> of characters that are confusingly similar in appearance (often
> known as the "phishing" problem) that are not part of the scope
> of the WG.
>
> While it is referenced from the original IDNA 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 or obsolete RFC 3490.  It is not expected
> to continue to use Nameprep (RFC 3491).  Nameprep is used by
> other specifications; determining how (or whether) to update
> those specifications and, consequently, the long-term status of
> Nameprep, are not part of this effort.  The method for
> ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC
> 3492) will not be revised by this WG.
>
> Subject to the more general constraints described above, the WG
> is permitted to consider changes that are not strictly
> backwards-compatible.  For any such change that is recommended, it
> is expected to document the reasons for the change, the
> characters affected, and possible transition strategies.
>
> The assumptions outlined above are considered critical to the
> WG constituted this charter.  The WG will stop, close, and
> recommend that a new charter be generated if it concludes that
> any of the following are necessary to meet its goals:
>
>    (i) A change to the "punycode" algorithm or to the ACE
>    approach to encoding names in the DNS.
>
>    (ii) A change to the ACE prefix from "xn--"
>
>    (iii) A change to the basic approach taken in the design
>    team documents (Namely: a protocol that is independent of Unicode
>    versions, that removes any character mapping in the
>    protocol, and that has improvements to the bidi algorithm).
>
> Goals and milestones:
>
> Apr 08: WG formation
> May 08: Decision on form and structure of the WG document set
> Sep 08: WG Last Call on WG document set
> Nov 08: IETF Last Call on WG document set
>
>
> Documents:
>
> http://tools.ietf.org/html/draft-klensin-idnabis-issues
> http://tools.ietf.org/html/draft-klensin-idnabis-protocol
> http://tools.ietf.org/html/draft-faltstrom-idnabis-tables
> http://tools.ietf.org/html/draft-alvestrand-idna-bidi
>
> ---------------------
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080326/33fb8e2c/attachment.html

More information about the Idna-update mailing list