vint at google.com
Mon Dec 21 08:43:33 CET 2009
it might be useful to hear from cary karp what the scope of the
committee actually is.
On Dec 21, 2009, at 2:37 AM, Martin J. Dürst wrote:
> Hello Vint,
> I don't think any ICANN Committee is actually suited very much for
> talking about mapping. There are at least two reasons for this:
> 1) ICANN is mainly political, it takes technical direction from the
> IETF. (if said committee is an exception, then I apologize in advance)
> 2) [WAY MORE IMPORTANT] ICANN is mainly concerned with registration.
> As you mention, we are extremely clear on registration: NO MAPPINGS.
> Mappings are an issue of lookup, and in that area, ICANN doesn't
> have much interest or say, nor does it have any direct links to
> browser vendors and others in a similar position.
> Regards, Martin.
> On 2009/12/19 21:50, Vint Cerf wrote:
>> Another way to think about this, Michel, is that the IDNABIS working
>> group simply
>> does not make a normative recommendation on mapping. It has been
>> about no mapping for registration (in other words, you register only
>> characters and the registry does not map for the registrant).
>> With regard to lookup, there isn't consensus within the IDNABIS WG on
>> the nature of mappings or even the advisability.
>> It has been suggested that a better forum in which to deal with
>> IDNA2003 and
>> IDNA2008 incompatibility is the ICANN IDN Guidelines Committee.
>> That may
>> be a better forum with broader participation than the IDNABIS working
>> in which the TR46 proposal or other proposals may be discussed. If we
>> Cary Karp's offer, your observations, below, would be input into the
>> committee discussions.
>> On Dec 18, 2009, at 10:13 PM, Michel SUIGNARD wrote:
>>>> From Lisa Dusseault (Dec 1st)
>>>> I don't believe we know what the WG consensus position is around
>>>> strongly pre-lookup mappings are recommended and in what use cases,
>>>> and how compatible optional pre-lookup mappings are with IDNA2003
>>>> in-protocol mapping.
>>> I'd like to give a new feedback to that statement. The issue some of
>>> us have with the current recommendation in idna-mappings [draft-
>>> idnabis-mappings-05] is that it is vastly different from the mapping
>>> done in IDNA_2003, especially concerning compatibility mapping done
>>> beyond the narrow/wide mapping suggested in the current document.
>>> The solution proposes the referencing of a single mapping table,
>>> improving greatly odds that implementers will do the right thing.
>>> Finally, it makes trivial for the draft Unicode TR46 to refer to a
>>> common mapping definition, avoiding potential confusion and
>>> unnecessary duplication.
>>> Some examples of characters mapped differently between idna-mappings
>>> and idna 2003 (in idna-mappings they stay unmapped):
>>> 00AA ( ª ) => 0061 ( a ) # FEMININE ORDINAL INDICATOR
>>> 00B2 ( ² ) => 0032 ( 2 ) # SUPERSCRIPT TWO
>>> 00B3 ( ³ ) => 0033 ( 3 ) # SUPERSCRIPT THREE
>>> 00B5 ( µ ) => 03BC ( μ ) # MICRO SIGN
>>> 00B9 ( ¹ ) => 0031 ( 1 ) # SUPERSCRIPT ONE
>>> 00BA ( º ) => 006F ( o ) # MASCULINE ORDINAL INDICATOR
>>> 0130 ( İ ) => 0069 0307 ( i̇ ) # LATIN CAPITAL LETTER I WITH DOT
>>> 0132 ( Ĳ ) => 0069 006A ( ij ) # LATIN CAPITAL LIGATURE IJ
>>> 013F ( Ŀ ) => 006C 00B7 ( l• ) # LATIN CAPITAL LETTER L WITH
>>> MIDDLE DOT
>>> 0140 ( ŀ ) => 006C 00B7 ( l• ) # LATIN SMALL LETTER L WITH
>>> 0149 ( ŉ ) => 02BC 006E ( ʼn ) # LATIN SMALL LETTER N PRECEDED
>>> 017F ( ſ ) => 0073 ( s ) # LATIN SMALL LETTER LONG S
>>> 01C4 ( Ǆ ) => 0064 017E ( dž ) # LATIN CAPITAL LETTER DZ WITH
>>> 01F3 ( ǳ ) => 0064 007A ( dz ) # LATIN SMALL LETTER DZ
>>> By using a mapping table based on the NFKC_CF property already
>>> exposed in Unicode (reflecting IDNA mapping as designed in IDNA
>>> 2003), modified to improve compatibility with IDNA 2008, it is
>>> possible to address the concern expressed above. The table is
>>> available in http://www.unicode.org/Public/idna/5.1.0/IdnaMappingTable.txt
>>> and its construction is explained in section 7 of the latest TR46
>>> draft in http://www.unicode.org/reports/tr46/
>>> The editing instruction for idna-mappings to include referencing to
>>> this new mapping table follows:
>>> In Section 2, replace items 1-4 and all following text by:
>>> 1. For each code point in the input string to be used under the IDNA
>>> protocol, map the code point using the [IDNA Mapping Table], as
>>> a. Look up the status value for the code point in the table.
>>> b. If the status is "ignored", removed the code point from the
>>> c. If the status is "mapped", replace the code point in the input
>>> by the mapped value in the table. Note that the mapped value
>>> may consist of more than one code point.
>>> d. For any other status ("valid", "disallowed", "deviation"), and
>>> any code point which is unassigned for the Unicode version of
>>> the table, leave the code point unchanged in the input string.
>>> 2. Normalize the string which results from the mapping in step 1,
>>> Unicode Normalization Form C (NFC).
>>> Note that the result of this mapping and normalization of the input
>>> string may result in a string which is not valid per [I-D.ietf-
>>> idnabis-protocol], because it may contain disallowed or unassigned
>>> code points, or may otherwise fail well-formedness conditions
>>> specified in that protocol. Such verification is outside the scope
>>> of this document.
>>> If the mappings in this document are applied to versions of Unicode
>>> later than Unicode 5.1, the corresponding version of the IDNA
>>> Mapping Table for those later versions of the Unicode Standard
>>> should be used.
>>> In Section 6 Normative references
>>> [IDNA Mapping Table] add reference to
>>> Best regards,
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>> Idna-update mailing list
>> Idna-update at alvestrand.no
> #-# 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