>The IESG may encounter implementation tactics for dealing with the old and new specifications that are controversial.<br><br>One set of implementation tactics is UTS#46 <a href="http://www.unicode.org/reports/tr46/">Unicode IDNA Compatible Preprocessing</a> (in draft). The UTC will be considering that for approval at its upcoming meeting, so people with concerns may want to discuss and submit them to the UTC.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Sat, Sep 26, 2009 at 05:45, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We have formally submitted our documents to the Area Director, Lisa<br>
Dusseault, for consideration by the IESG.<br>
<br>
IDNABIS - Internationalized Domain Names for Applications<br>
Document Shepherd Write-up for the IESG<br>
<br>
1a. The document shepherd for the ensemble of six IDNABIS documents is<br>
Vinton Cerf, also serving as the WG chair. I have personally reviewed<br>
each document and consulted with the WG and the document editors and<br>
believe these documents are now ready for AD and IESG consideration<br>
for release as RFCs. The documents are:<br>
(i) Definitions: draft-ietf-idnabis-defs-11.txt<br>
(ii) Protocol: draft-ietf-idnabis-protocol-16.txt<br>
(iii) Bi-Di: draft-ietf-idnabis-bidi-06a.txt<br>
(iv) Tables: draft-ietf-idnabis-tables-07.txt<br>
(v) Rationale: draft-ietf-idnabis-rationale-13.txt<br>
(vi) Mappings: draft-ietf-idnabis-mappings-04.txt<br>
<br>
Of these, Definitions, Protocol, Bi-Di and Tables are normative;<br>
Rationale and mappings are non-normative documents but part of the<br>
proposed standard ensemble.<br>
<br>
<br>
1b. The initial impetus for the revisiting of the IDNA2003 proposed<br>
standards emerged in written form in RFC4690. An informal technical<br>
team worked to develop a framework for consideration which was later<br>
discussed, edited, and ratified to create the IDNABIS working group in<br>
2008. The documents resulting from the IDNABIS Working Group effort<br>
have been extensively discussed over a two year period by the WG and<br>
by interested parties especially language experts in the Chinese,<br>
Japanese and Hangul spaces, speakers of Hebrew, Indic languages as<br>
well as a working group of expert Arabic speakers. The WG has had the<br>
participation of several Unicode consortium representatives including<br>
the chairman of the UTC. It should not surprise the IESG that there<br>
was controversy during the development of these documents and at best<br>
a rough consensus has formed around the recommendations. There<br>
continue to be some parties who resist the results. I think the two<br>
years of work have been more than sufficient - arguments have been<br>
revisited multiple times with the same outcomes.<br>
<br>
1c. I do not believe that it is necessary to seek additional review by<br>
specialist parties. The working group had a great deal of<br>
representation from many perspectives and many volunteered their<br>
comments (some coming in at the last moment during WG last call - not<br>
surprisingly). The last call was effectively extended to last a month<br>
owing to discussions and substantive contributions arriving during<br>
this period and rough consensus has been reached on the documents as<br>
they are now composed.<br>
<br>
1d. There was an impasse relating to mapping of Unicode characters<br>
into other Unicode characters prior to the generation of a punycode<br>
equivalent string to produce an A-label [please see the Definitions<br>
document]. This was resolved by introducing a non-normative "mappings"<br>
document observing ways in which this aspect of dealing with<br>
internationalized domain names might be approached. The principal<br>
rationale for re-visiting the IDNA2003 recommendations arose from<br>
field experience and a recommendation from the IAB [RFC4690]. A major<br>
objective was to re-specify the standard in such a way as to make it<br>
independent of changes to the Unicode code set (something that evolves<br>
more or less continuously). The method for achieving this is to use<br>
the Unicode properties feature (per code-point/character) to determine<br>
whether the code point should be allowed, disallowed or used only<br>
under certain conditions in domain name labels. There remains the<br>
problem of deployment in a world of web servers, browsers and other<br>
applications using domain names that may have already implemented the<br>
IDNA2003 recommendations. The IESG may encounter implementation<br>
tactics for dealing with the old and new specifications that are<br>
controversial. Perfect backward compatibility with IDNA2003 was not<br>
possible (without simply replicating it, negating the rationale for<br>
the redefinition effort of IDNA2008). IESG members will note that this<br>
is 2009 but the new specifications bear the label IDNA2008 because the<br>
work was started in that year. This is particularly true of the<br>
special characters "esszet" or "sharp-S" used in German and the "final<br>
sigma" used in Greek. These were mapped into other valid Unicode<br>
characters under IDNA2003 but allowed in IDNA2008 because the Unicode<br>
code points for these were introduced in the interim between IDNA2003<br>
and IDNA2008 standardization efforts. The treatment of languages that<br>
are expressed in Right-to-Left form (see "Bi-Di" document) has been<br>
revised relative to IDNA2003 and it is believed that the revision is<br>
clearer and more precise in its form and limitations on the use of<br>
numeric characters, for example.<br>
An IPR disclosure statement has not been filed. I am not aware of any<br>
claims to IPR associated with any of the documents and proposed<br>
standards.<br>
<br>
1e. The consensus behind these documents is based in part on the<br>
observation that repeated revisiting of issues produced the same<br>
results. There are still parties who are not in complete agreement<br>
with the results but after the introduction of the mapping document<br>
and considerable debate about its nature, much of the controversy was<br>
resolved, leading the chairman to declare that a reasonable basis for<br>
consensus existed. There remain a small number of parties who resist<br>
the outcomes but the bulk of the working group appears to be in<br>
agreement with or supportive of the results. Application of the<br>
proposed standards will face the problem of existing IDNA2003-<br>
conformant implementations. There is reported to be an apparent desire<br>
among browser implementers to avoid double DNS lookups under each<br>
framework. The simple fact of non-uniform propagation of IDNA2008-<br>
conformant implementations in all software that needs to be aware of<br>
and processs Internationalized Domain Names adds to the likelihood of<br>
various DNS-using implementations that are i) IDNA-unaware, ii)<br>
IDNA2003-aware only or IDNA2008 and IDNA2003 aware.<br>
1f. There has been no overt threat of appeal. See (1d) however<br>
regarding implementation tactics and vendor response to the new<br>
IDNA2008 specifications.<br>
1g. As far as I can determine, these documents meet all I-D criteria.<br>
1h. The document ensemble is split into normative and informational<br>
parts, as outlined in (1a). All documents are ready for advancement as<br>
Proposed Standards. No previous RFCs are affected except for those<br>
associated with IDNA2003 [RFC3490]. In particular, there is no change<br>
to the use of Punycode [RFC3492] and neither Nameprep [RFC3491] nor<br>
Stringprep [RFC3454] are used in IDNA2008.<br>
1i. IANA sections exist as required. As per IDNA2003, IANA will need<br>
to generate tables reflecting the application of the IDNA2008 Tables<br>
rules to the current Unicode release. In particular, reference is<br>
drawn to Sections 5.1 and 5.2 of the Tables document, reproduced below<br>
for convenience:<br>
<br>
5.1. IDNA derived property value registry<br>
<br>
IANA is to keep a list of the derived property for the versions of<br>
Unicode that is released after (and including) version 5.1. The<br>
derived property value is to be calculated according to the<br>
specifications in sections Section 2 and Section 3 and not by copying<br>
the non-normative table found in Appendix B. Changes to the rules,<br>
including BackwardCompatible (Section 2.7) (a set that is at release<br>
of this document is empty), require IETF Review, as described in<br>
[RFC5226]<br>
<br>
5.2. IDNA Context Registry<br>
<br>
For characters that are defined in the IDNA Character Registry list as<br>
CONTEXTO or CONTEXTJ and therefore requiring a contextual rule IANA<br>
will create and maintain a list of approved contextual rules.<br>
Additions or changes to these rules require IETF Review, as described<br>
in [RFC5226]. A table from which that registry can be initialized,<br>
and some further discussion, appears in Appendix A.<br>
<br>
1j. The Tables document does not require automatic evaluation of<br>
formulas<br>
1k. Document Announcement draft<br>
Technical Summary<br>
<br>
The Internationalized Domain Names for Applications (IDNA) revisions<br>
are intended to reduce significantly IDNA dependency on specific<br>
versions of the Unicode character coding system. The Working Group<br>
produced the following documents representing a revision to the<br>
earlier "IDNA2003" proposed standard [only RFC 3490 is specifically<br>
affected]:<br>
<br>
[Note to RFC Editor: these references should be replaced with their<br>
RFC counterparts when the documents are approved for release by the<br>
IESG]<br>
<br>
Definitions: draft-ietf-idnabis-defs-11.txt<br>
Protocol: draft-ietf-idnabis-protocol-16.txt<br>
Bi-Di: draft-ietf-idnabis-bidi-06a.txt<br>
Tables: draft-ietf-idnabis-tables-07.txt<br>
Rationale: draft-ietf-idnabis-rationale-13.txt<br>
Mappings: draft-ietf-idnabis-mappings-04.txt<br>
<br>
Of these, Definitions, Protocol, Bi-Di and Tables are normative;<br>
Rationale and mappings are non-normative documents but part of the<br>
proposed standard ensemble.<br>
<br>
<br>
Working Group Summary<br>
<br>
The initial impetus for the revisiting of the IDNA2003 proposed<br>
standards emerged in written form in RFC4690. An informal technical<br>
team worked to develop a framework for consideration that was later<br>
discussed, edited, and ratified to create the IDNABIS working group in<br>
2008. The documents resulting from the IDNABIS Working Group effort<br>
have been extensively discussed over a two year period by the WG and<br>
by interested parties especially language experts in the Chinese,<br>
Japanese and Hangul spaces, speakers of Hebrew, Indic languages as<br>
well as a working group of expert Arabic speakers. The WG has had the<br>
participation of several Unicode consortium representatives. There was<br>
controversy during the development of these documents but a rough<br>
consensus has formed around the recommendations.<br>
There was an impasse relating to mapping of Unicode characters into<br>
other Unicode characters prior to the generation of a punycode<br>
equivalent string to produce an A-label [please see the Definitions<br>
document]. This was resolved by introducing a non-normative "mappings"<br>
document observing ways in which this aspect of dealing with<br>
internationalized domain names might be approached. The principal<br>
rationale for re-visiting the IDNA2003 recommendations arose from<br>
field experience and a recommendation from the IAB [RFC4690]. A major<br>
objective was to re-specify the standard in such a way as to make it<br>
independent of changes to the Unicode code set (something that evolves<br>
more or less continuously). The method for achieving this is to use<br>
the Unicode properties feature (per code-point/character) to determine<br>
whether the code point should be allowed, disallowed or used only<br>
under certain conditions in domain name labels. There remains the<br>
problem of deployment in a world of web servers, browsers and other<br>
applications using domain names that may have already implemented the<br>
IDNA2003 recommendations. The IESG may encounter implementation<br>
tactics for dealing with the old and new specifications that are<br>
controversial. Perfect backward compatibility with IDNA2003 was not<br>
possible (without simply replicating it, negating the rationale for<br>
the redefinition effort of IDNA2008). IESG members will note that this<br>
is 2009 but the new specifications bear the label IDNA2008 because the<br>
work was started in that year. This is particularly true of the<br>
special characters "esszet" or "sharp-S" used in German and the "final<br>
sigma" used in Greek. These were mapped into other valid Unicode<br>
characters under IDNA2003 but allowed in IDNA2008 because the Unicode<br>
code points for these were introduced in the interim between IDNA2003<br>
and IDNA2008 standardization efforts. The treatment of languages that<br>
are expressed in Right-to-Left form (see "Bi-Di" document) has been<br>
revised relative to IDNA2003 and it is believed that the revision is<br>
clearer and more precise in its form and limitations on the use of<br>
numeric characters, for example.<br>
<br>
<br>
Document Quality<br>
<br>
There are test implementations of the rules proposed by IDNA2008 but<br>
no released operational software. Such implementations have awaited<br>
the achievement of rough consensus on the controversial parts of the<br>
new proposals. Inputs from special expert bodies such as a Korean<br>
expert language group, an informal Arabic speakers group, and a number<br>
of individual commentators from the Unicode community, among others,<br>
have contributed to the documents as they now exist. Multiple<br>
implementations of the Tables rules have confirmed the stability of<br>
the definitions under distinct implementation.<br>
<br>
<br>
<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>