New Attempt to Close on IDNABIS Charter (v2)

Debbie Garside debbie at
Mon Mar 31 19:47:41 CEST 2008

Looks good to me.


From: idna-update-bounces at
[mailto:idna-update-bounces at] On Behalf Of Vint Cerf
Sent: 31 March 2008 10:56
To: idna-update at
Subject: New Attempt to Close on IDNABIS Charter (v2)


We have been discussing a lot about IDNs in the mailing list, a lot of the
discussion is actually about specifics of the various draft documents
intended to form the basis for the work of the proposed IDNABIS working
group but a fair amount has been about the text of the charter. 

I have made what I hope are considered small revisions to the earlier
proposed charter to try to take into account comments made by a number of
you on the list.

The revision which I am calling IDNABIS Charter (v2) is shown below. I
imagine that there may still be comments about this version but I ask you to
consider whether further amendment to the charter is as productive as
getting to work on the documents themselves. Some concerns have been
expressed about conditions for terminating the working group and
re-chartering. I recognize but perhaps don't fully appreciate the hazards
here, but have re-worded slightly these conditions. As the proposed working
group chair, I am prepared to do the best I can to manage this process and
to defend the work of the working group against re-chartering except under
very significant deviation from the proposed framework in the referenced
draft specifications.

I don't quite know how to word the request but I would like to ask the AD,
Lisa Dusseault, to submit this version to the IESG for approval no later
than April 7, assuming that there are no further fundamental issues taken
with the text. As to "fundamental issues", I suggest that Lisa and I be the
arbiters of that for purposes of finalizing this charter for submission to
the IESG.

With thanks to all on the list who have participated in improving the

Vint Cerf


Chair(s):  Vinton G. Cerf

Applications Area Directors:

Lisa Dusseault ( <mailto:ldusseault at> ldusseault at

Chris Newman ( <mailto:Chris.Newman at> Chris.Newman at

Applications Area Advisor:

Lisa Dusseault ( <mailto:ldusseault at> ldusseault at

Mailing List:

General Discussion:  <mailto:idna-update at>
idna-update at

To Subscribe:


Archive:  <>


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 "IDNA2003").

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 decouple 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 will 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 if 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 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 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.

The specifications are initially organized as four documents: overview and
rationale, protocol, table algorithm, and improvements 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 improvement of the IDNA

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 from IETF participants and from others including
experts in the Unicode specifications and the use of scripts in languages.
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 respond with any needed changes and close in a short
period of time.  If technical issues arise that indicate a fundamentally
different approach must be taken from the one outlined above, it is
anticipated that this working group would close, and a new one with an
appropriate charter would be considered.

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

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 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
by 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: independence from Unicode version and elimination of character
mapping in the protocol)

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






-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Idna-update mailing list