Mapping ( was: Thai Codepoint U+0E33)

[Vint Cerf]

Gerv,

The working group reached its conclusion after 18 months of debate,  
and in particular after two IETF meetings and countless emails devoted  
to discussion about mappings.

The problem is that there is no single set of mappings that can be  
applied that seem to satisfy all requirements. We have documented what  
can be registered in the system (namely A-labels). We have documented  
how to transform a string from A-label to U-label and back (they are  
exactly equivalent under punycode transformation). We have shown that  
it is possible to safely perform fewer tests on strings to be looked  
up than on strings to be registered, on the assumption that all  
registered strings will have passed the stringent tests for U-label  
and/or A-label forms prior to being registered.

Mapping functionality occurs in different places in the system,  
depending on where you start and what application you happen to be  
running and maybe what scripts you happen to be using to say nothing  
of what input methods might be invoked (voice, keyboard, cut/paste,  
computation, etc).

Mark's comments reflect his opinions. The WG consensus reflects the  
general opinions of a wider range of experts.

vint


On Jul 30, 2009, at 5:36 AM, Gervase Markham wrote:

> On 28/07/09 18:15, Mark Davis ⌛ wrote:
>> The mapping has a quite number of flaws, but now that it looks like  
>> it
>> will not be normative, I don't think it is worth any spending any
>> further time on it.
>>
>> My recommendation (for Google and other companies) is to use a more
>> robust mapping that maintains as much backwards compatibility as
>> possible, which is to map non-PVALID/CONTEXTx characters via the  
>> Unicode
>> property NFKC_Casefold.
>
> Again, I find myself baffled by what's going on on this list, and
> thinking I must have missed something.
>
> Do I understand correctly? Our resident Unicode expert believes that  
> the
> mapping document we are about to publish as "quite a number of flaws"
> and is already recommending that companies don't use it? Then how
> exactly is this document at all useful in meeting the goal of
> encouraging consistency in mapping across implementations?
>
> If companies have to come to their own conclusions on the best way  
> to do
> mapping, it's possible that consensus will be painfully achieved, but
> that consensus may well not do the right thing for some language
> communities, who will then be left with something sub-optimal. We  
> aren't
> the experts.
>
> Gerv
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update