- From: Addison Phillips <addison.phillips@quest.com>
- Date: Tue, 3 May 2005 14:42:43 -0700
- To: "Ian Hickson" <ian@hixie.ch>, "Richard Ishida" <ishida@w3.org>
- Cc: <www-style@w3.org>, <public-i18n-core@w3.org>
What follows is a personal response. I believe that you are confusing two different issues here. IDN imposes particular restrictions on what can be registered in a domain name (and what user-agents must do when requesting content from a non-ASCII domain name in order to encode the characters for DNS). IRI, by contrast, describes how to use non-ASCII characters in URIs. While domain names are certainly a part of a URI, their handling in IRI has nothing to do with Stringprep or Punycode. Implementations of one are not coupled to implementations of the other necessarily. URIs are quite important in CSS. I would strongly suggest that IRI would make sense to include there so that implementations will begin to track to this standard mechanism for representing non-ASCII URIs. Whether particular implementations support IDN when actually retrieving content is a separate matter. Items 1b and 1c in Section 3 of IRI basically say that URIs should use the UTF-8 encoding for percent escaping non-ASCII characters (making them reliable, whereas today they might NOT be encoded using UTF-8, causing interoperability woes). This requires no special knowledge of Unicode, merely conversion between the native encoding and Unicode (when a native, legacy encoding is used for the stylesheet). Since the character set for HTML and XML is Unicode and since Unicode holds at least a special place in CSS, this doesn't strike me as an insuperable burden. I do recognize that strict adoption of IRI would have a certain impact on CSS. In particular, it might require a close look at the formal grammar in Appendix G of CSS 2.1. But I think we should really discuss this before you reject making a normative reference to IRI. Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: public-i18n-core-request@w3.org [mailto:public-i18n-core- > request@w3.org] On Behalf Of Ian Hickson > Sent: 2005?5?3? 10:07 > To: Richard Ishida > Cc: www-style@w3.org; public-i18n-core@w3.org > Subject: Re: [CSS21] uri() > > > On Tue, 3 May 2005, Richard Ishida wrote: > > > > Note that http://www.ietf.org/rfc/rfc3986 now obsoletes rfc 1808 and > updates > > rfc 1738. > > I have added this to our issues list, thanks. > > > > Also, RFC 3987 Internationalized Resource Identifiers (IRIs) is now an > IETF > > Proposed Standard, and references rfc 3986. > > We considered updating CSS2.1 to use IRIs. However, there was some concern > that the requirements in RFC 3987 were unimplementable. In particular, the > difference between steps 1b and 1c in section 3.1 imply behaviour that > would be hard to specify in terms of the CSS model. There was also a > concern that the difference between RFC 3987 5.3.2.2:2 and RFC 3491 2 (qv. > RFC 3454 B.2) would require implements to include excessive amounts of the > Unicode database in IDN/IRI-aware CSS processors. Therefore, until the > working group has more implementation experience, IRI processing > requirements have not been added to CSS. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 3 May 2005 21:42:55 UTC