Formal submission of our documents to AD

Harald Alvestrand harald at alvestrand.no
Mon Oct 5 09:43:28 CEST 2009


Mark Davis ☕ wrote:
> >The IESG may encounter implementation tactics for dealing with the 
> old and new specifications that are controversial.
>
> One set of implementation tactics is UTS#46 Unicode IDNA Compatible 
> Preprocessing <http://www.unicode.org/reports/tr46/> (in draft). 
Yes, that's one of the controversial ones.
> 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.
>
> Mark
>
>
> On Sat, Sep 26, 2009 at 05:45, Vint Cerf <vint at google.com 
> <mailto:vint at google.com>> wrote:
>
>     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.
>
>
>
>
>
>
>     _______________________________________________
>     Idna-update mailing list
>     Idna-update at alvestrand.no <mailto:Idna-update at alvestrand.no>
>     http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>   



More information about the Idna-update mailing list