- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 1 Jun 2006 02:09:23 -0700
- To: Chris Lilley <chris@w3.org>
- Cc: public-webapi@w3.org
On Jun 1, 2006, at 12:55 AM, Chris Lilley wrote: > > Hello public-webapi, > > In http://www.w3.org/TR/2006/WD-Window-20060407/ there are > multiple references to RFC 2396. This is obsoleted by RFC 3986; > please replace references to the former by the latter and be sure > to use terminology consistent with 3986 which has some > clarifications and changes relative to RFC 2396. That's the plan. There is already an editorial note to this effect. > Also, why is a URI rather than an IRI or an XRI specified here? Is > this an oversight, or is it a deliberate decision to exclude usage > in countries such as China and Korea that make extensive use of > IRIs,or to require such IRIs to be hexified before using this > interface? It is neither a mistake nor a deliberate malfeasance. The goal for the first version of the Window spec is to provide a rationalized subset of features that already exist in web browsers. Many do not support IRIs either in these APIs or anywhere else. As a new feature, IRI support would be out of scope for the first version. In fact, it is hard to see how browsers will ever roll out universal support for IRIs, since the current practice for characters outside the ASCII range is to use the page encoding rather than UTF-8. And in fact there is a lot of content, particularly in China and Korea, that depends on the practice of using the page encoding. On UTF-8 pages (like google's chinese search results) this is equivalent to IRIs, but when using other common encodings like gb2312, changing over would be incompatible. An example of a site affected by this is http://www.sz.net.cn/. XRIs would be even less appropriate, since an arbitrary valid URI is not a valid XRI, so far as I can tell. So this would be even more of an incompatible change. Given these complexities I think it's best to table this issue until the next version of the Window spec. It is clear that using international characters in resource identifiers is desirable, but specifying something that contradicts existing practice would be bad, and it's not clear if there is a spec that is compatible with existing implementations and content. Regards, Maciej
Received on Thursday, 1 June 2006 09:09:34 UTC