W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: [CSS21][css3-namespace][css3-page][css3-selectors][css3-content] Unicode Normalization

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Sat, 31 Jan 2009 16:40:08 +0900
Message-Id: <6.0.0.20.2.20090131163708.06d21300@localhost>
To: "Anne van Kesteren" <annevk@opera.com>, "Jonathan Kew" <jonathan@jfkew.plus.com>
Cc: "Richard Ishida" <ishida@w3.org>, "'L. David Baron'" <dbaron@dbaron.org>, public-i18n-core@w3.org, www-style@w3.org

At 00:18 09/01/31, Anne van Kesteren wrote:
>
>I don't have much to add to my previous e-mail, apart from this.
>
>On Fri, 30 Jan 2009 16:02:02 +0100, Jonathan Kew <jonathan@jfkew.plus.com>  
>wrote:
>> It seems to me that this issue is similar to that of Internationalized  
>> Domain Names, where it certainly isn't considered acceptable for there  
>> to be canonically-equivalent names that are treated as distinct.
>
>Program code and IDNs are very different. Actual end users have to  
>interact with IDNs so it makes a lot of sense not to allow effectively  
>identical names to be registered as that would open up all kinds of  
>spoofing issues (apart from the spoofing issues IDNs already enable). End  
>users do not deal with program code.

And on top of this, please note that while the 2003 version of IDNA
prescribes normalization NFKC as part of the protocol, the new version
currently worked on by the IDNAbis WG still makes sure everything that's
not NFKC-normalized cannot be used (to reduce spoofing), but doesn't
require the actual normalization step anymore.

Given that the normalization step has been part of the protocol,
I'm personally very ambivalent about removing it, to say the least,
but it may be taken as an additional indication that CSS as currently
implemented isn't that bad.

Regards,    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
Received on Sunday, 1 February 2009 08:33:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT