Formal submission of our documents to AD
Vint Cerf
vint at google.com
Mon Oct 5 11:45:32 CEST 2009
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091005/bf6eb766/attachment-0001.htm
More information about the Idna-update
mailing list