Formal submission of our documents to AD

Vint Cerf vint at google.com
Sat Sep 26 14:45:55 CEST 2009


We have formally submitted our documents to the Area Director, Lisa  
Dusseault, for consideration by the IESG.

IDNABIS - Internationalized Domain Names for Applications
Document Shepherd Write-up for the IESG

1a. The document shepherd for the ensemble of six IDNABIS documents is  
Vinton Cerf, also serving as the WG chair. I have personally reviewed  
each document and consulted with the WG and the document editors and  
believe these documents are now ready for AD and IESG consideration  
for release as RFCs. The documents are:
(i) Definitions: draft-ietf-idnabis-defs-11.txt
(ii) Protocol: draft-ietf-idnabis-protocol-16.txt
(iii) Bi-Di: draft-ietf-idnabis-bidi-06a.txt
(iv) Tables: draft-ietf-idnabis-tables-07.txt
(v) Rationale: draft-ietf-idnabis-rationale-13.txt
(vi) Mappings: draft-ietf-idnabis-mappings-04.txt

Of these, Definitions, Protocol, Bi-Di and Tables are normative;  
Rationale and mappings are non-normative documents but part of the  
proposed standard ensemble.


1b. The initial impetus for the revisiting of the IDNA2003 proposed  
standards emerged in written form in RFC4690. An informal technical  
team worked to develop a framework for consideration which was later  
discussed, edited, and ratified to create the IDNABIS working group in  
2008. The  documents resulting from the IDNABIS Working Group effort  
have been extensively discussed over a two year period by the WG and  
by interested parties especially language experts in the Chinese,  
Japanese and Hangul spaces, speakers of Hebrew, Indic languages as  
well as a working group of expert Arabic speakers. The WG has had the  
participation of several Unicode consortium representatives including  
the chairman of the UTC. It should not surprise the IESG that there  
was controversy during the development of these documents and at best  
a rough consensus has formed around the recommendations. There  
continue to be some parties who resist the results. I think the two  
years of work have been more than sufficient - arguments have been  
revisited multiple times with the same outcomes.

1c. I do not believe that it is necessary to seek additional review by  
specialist parties. The working group had a great deal of  
representation from many perspectives and many volunteered their  
comments (some coming in at the last moment during WG last call - not  
surprisingly). The last call was effectively extended to last a month  
owing to discussions and substantive contributions arriving during  
this period and rough consensus has been reached on the documents as  
they are now composed.

1d. There was an impasse relating to mapping of Unicode characters  
into other Unicode characters prior to the generation of a punycode  
equivalent string to produce an A-label [please see the Definitions  
document]. This was resolved by introducing a non-normative "mappings"  
document observing ways in which this aspect of dealing with  
internationalized domain names might be approached. The principal  
rationale for re-visiting the IDNA2003 recommendations arose from  
field experience and a recommendation from the IAB [RFC4690]. A major  
objective was to re-specify the standard in such a way as to make it  
independent of changes to the Unicode code set (something that evolves  
more or less continuously). The method for achieving this is to use  
the Unicode properties feature (per code-point/character) to determine  
whether the code point should be allowed, disallowed or used only  
under certain conditions in domain name labels. There remains the  
problem of deployment in a world of web servers, browsers and other  
applications using domain names that may have already implemented the  
IDNA2003 recommendations. The IESG may encounter implementation  
tactics for dealing with the old and new specifications that are  
controversial. Perfect backward compatibility with IDNA2003 was not  
possible (without simply replicating it, negating the rationale for  
the redefinition effort of IDNA2008). IESG members will note that this  
is 2009 but the new specifications bear the label IDNA2008 because the  
work was started in that year. This is particularly true of the  
special characters "esszet" or "sharp-S" used in German and the "final  
sigma" used in Greek. These were mapped into other valid Unicode  
characters under IDNA2003 but allowed in IDNA2008 because the Unicode  
code points for these were introduced in the interim between IDNA2003  
and IDNA2008 standardization efforts. The treatment of languages that  
are expressed in Right-to-Left form (see "Bi-Di" document) has been  
revised relative to IDNA2003 and it is believed that the revision is  
clearer and more precise in its form and limitations on the use of  
numeric characters, for example.
An IPR disclosure statement has not been filed. I am not aware of any  
claims to IPR associated with any of the documents and proposed  
standards.

1e. The consensus behind these documents is based in part on the  
observation that repeated revisiting of issues produced the same  
results. There are still parties who are not in complete agreement  
with the results but after the introduction of the mapping document  
and considerable debate about its nature, much of the controversy was  
resolved, leading the chairman to declare that a reasonable basis for  
consensus existed. There remain a small number of parties who resist  
the outcomes but the bulk of the working group appears to be in  
agreement with or supportive of the results. Application of the  
proposed standards will face the problem of existing IDNA2003- 
conformant implementations. There is reported to be an apparent desire  
among browser implementers to avoid double DNS lookups under each  
framework. The simple fact of non-uniform propagation of IDNA2008- 
conformant implementations in all software that needs to be aware of  
and processs Internationalized Domain Names adds to the likelihood of  
various DNS-using implementations that are i) IDNA-unaware, ii)  
IDNA2003-aware only or IDNA2008 and IDNA2003 aware.
1f. There has been no overt threat of appeal. See (1d) however  
regarding implementation tactics and vendor response to the new  
IDNA2008 specifications.
1g. As far as I can determine, these documents meet all I-D criteria.
1h. The document ensemble is split into normative and informational  
parts, as outlined in (1a). All documents are ready for advancement as  
Proposed Standards. No previous RFCs are affected except for those  
associated with IDNA2003 [RFC3490]. In particular, there is no change  
to the use of Punycode [RFC3492] and neither Nameprep [RFC3491] nor  
Stringprep [RFC3454] are used in IDNA2008.
1i. IANA sections exist as required. As per IDNA2003, IANA will need  
to generate tables reflecting the application of the IDNA2008 Tables  
rules to the current Unicode release. In particular, reference is  
drawn to Sections 5.1 and 5.2 of the Tables document, reproduced below  
for convenience:

5.1. IDNA derived property value registry

IANA is to keep a list of the derived property for the versions of  
Unicode that is released after (and including) version 5.1.  The  
derived property value is to be calculated according to the  
specifications in sections Section 2 and Section 3 and not by copying  
the non-normative table found in Appendix B. Changes to the rules,   
including BackwardCompatible (Section 2.7) (a set that is at release  
of this document is empty), require IETF Review, as described in  
[RFC5226]

5.2. IDNA Context Registry

For characters that are defined in the IDNA Character Registry list as  
CONTEXTO or CONTEXTJ and therefore requiring a contextual rule  IANA  
will create and maintain a list of approved contextual rules.  
Additions or changes to these rules require IETF Review, as described   
in [RFC5226].  A table from which that registry can be initialized,  
and some further discussion, appears in Appendix A.

1j. The Tables document does not require automatic evaluation of  
formulas
1k. Document Announcement draft
Technical Summary

The Internationalized Domain Names for Applications (IDNA) revisions  
are intended to reduce significantly IDNA dependency on specific  
versions of the Unicode character coding system. The Working Group  
produced the following documents representing a revision to the  
earlier "IDNA2003" proposed standard [only RFC 3490 is specifically  
affected]:

[Note to RFC Editor: these references should be replaced with their  
RFC counterparts when the documents are approved for release by the  
IESG]

Definitions: draft-ietf-idnabis-defs-11.txt
Protocol: draft-ietf-idnabis-protocol-16.txt
Bi-Di: draft-ietf-idnabis-bidi-06a.txt
Tables: draft-ietf-idnabis-tables-07.txt
Rationale: draft-ietf-idnabis-rationale-13.txt
Mappings: draft-ietf-idnabis-mappings-04.txt

Of these, Definitions, Protocol, Bi-Di and Tables are normative;  
Rationale and mappings are non-normative documents but part of the  
proposed standard ensemble.


      Working Group Summary

  The initial impetus for the revisiting of the IDNA2003 proposed  
standards emerged in written form in RFC4690. An informal technical  
team worked to develop a framework for consideration that was later  
discussed, edited, and ratified to create the IDNABIS working group in  
2008. The documents resulting from the IDNABIS Working Group effort  
have been extensively discussed over a two year period by the WG and  
by interested parties especially language experts in the Chinese,  
Japanese and Hangul spaces, speakers of Hebrew, Indic languages as  
well as a working group of expert Arabic speakers. The WG has had the  
participation of several Unicode consortium representatives. There was  
controversy during the development of these documents but a rough  
consensus has formed around the recommendations.
There was an impasse relating to mapping of Unicode characters into  
other Unicode characters prior to the generation of a punycode  
equivalent string to produce an A-label [please see the Definitions  
document]. This was resolved by introducing a non-normative "mappings"  
document observing ways in which this aspect of dealing with  
internationalized domain names might be approached. The principal  
rationale for re-visiting the IDNA2003 recommendations arose from  
field experience and a recommendation from the IAB [RFC4690]. A major  
objective was to re-specify the standard in such a way as to make it  
independent of changes to the Unicode code set (something that evolves  
more or less continuously). The method for achieving this is to use  
the Unicode properties feature (per code-point/character) to determine  
whether the code point should be allowed, disallowed or used only  
under certain conditions in domain name labels. There remains the  
problem of deployment in a world of web servers, browsers and other  
applications using domain names that may have already implemented the  
IDNA2003 recommendations. The IESG may encounter implementation  
tactics for dealing with the old and new specifications that are  
controversial. Perfect backward compatibility with IDNA2003 was not  
possible (without simply replicating it, negating the rationale for  
the redefinition effort of IDNA2008). IESG members will note that this  
is 2009 but the new specifications bear the label IDNA2008 because the  
work was started in that year. This is particularly true of the  
special characters "esszet" or "sharp-S" used in German and the "final  
sigma" used in Greek. These were mapped into other valid Unicode  
characters under IDNA2003 but allowed in IDNA2008 because the Unicode  
code points for these were introduced in the interim between IDNA2003  
and IDNA2008 standardization efforts. The treatment of languages that  
are expressed in Right-to-Left form (see "Bi-Di" document) has been  
revised relative to IDNA2003 and it is believed that the revision is  
clearer and more precise in its form and limitations on the use of  
numeric characters, for example.


      Document Quality

There are test implementations of the rules proposed by IDNA2008 but  
no released operational software. Such implementations have awaited  
the achievement of rough consensus on the controversial parts of the  
new proposals. Inputs from special expert bodies such as a Korean  
expert language group, an informal Arabic speakers group, and a number  
of individual commentators from the Unicode community, among others,  
have contributed to the documents as they now exist. Multiple  
implementations of the Tables rules have confirmed the stability of  
the definitions under distinct implementation.








More information about the Idna-update mailing list