New Attempt to Close on IDNABIS Charter (v2)

Mon Mar 31 11:55:57 CEST 2008

Folks,

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  
charter,

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 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 specifications.

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 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 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080331/4864aeb6/attachment-0001.html