"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Mon Dec 21 08:37:07 CET 2009
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.
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 how
>>> 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-ietf-
>> 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 MIDDLE
>> 0149 ( ŉ ) => 02BC 006E ( ʼn ) # LATIN SMALL LETTER N PRECEDED BY
>> 017F ( ſ ) => 0073 ( s ) # LATIN SMALL LETTER LONG S
>> 01C4 ( Ǆ ) => 0064 017E ( dž ) # LATIN CAPITAL LETTER DZ WITH CARON
>> 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 input
>> 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