Formal submission of our documents to AD

Vint Cerf vint at google.com
Mon Oct 5 13:41:54 CEST 2009


Character processing!

----- Original Message -----
From: "Martin J. Dürst" <duerst at it.aoyama.ac.jp>
To: Vint Cerf <vint at google.com>
Cc: Mark Davis ☕ <mark at macchiato.com>; Harald Alvestrand
<harald at alvestrand.no>; idna-update at alvestrand.no
<idna-update at alvestrand.no>
Sent: Mon Oct 05 07:03:26 2009
Subject: Re: Formal submission of our documents to AD

Vint - Do you mean flow chart in terms of the UTC process flow, or in
terms of the character processing that TR 46 proposes?

Regards,   Martin.

On 2009/10/05 18:45, Vint Cerf wrote:
> mark,
>
> is there a kind of flow chart for the proposal in URS#46 that we could
> release to the idnabis mailing list?
>
> v
>
> On Oct 5, 2009, at 4:03 AM, Mark Davis ☕ wrote:
>
>> If you have some particular suggestions regarding items in the
>> document, you can submit them directly via the [Feedback] link at the
>> top. If you also want discussion of the topics, then also on one of
>> the Unicode mailing lists. And if you have any other suggestions for
>> how to bridge the compatibility gaps between IDNA2003 implementations
>> and IDNA2008 implementations, those suggestions would be welcome. We
>> had a number of people from the browser communities at the meetings,
>> and these were the best we could come up as yet.
>>
>> Mark
>>
>>
>> On Mon, Oct 5, 2009 at 00:43, Harald Alvestrand <harald at alvestrand.no>
>> wrote:
>> 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
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp


More information about the Idna-update mailing list