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