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