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