- From: Arun Ranganathan <arun@mozilla.com>
- Date: Thu, 29 Sep 2011 14:11:52 -0400
- To: Anne van Kesteren <annevk@opera.com>
- CC: WebApps WG <public-webapps@w3.org>
On 9/29/11 12:29 PM, Anne van Kesteren wrote: > On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan > <arun@mozilla.com> wrote: >> On 8/31/11 3:45 AM, Anne van Kesteren wrote: >>> Yeah sure, every URI is an IRI, but that is not what I am asking. >> >> I'm sorry, I think I'm not understanding you very clearly :( The >> spec. currently specifies what can be an opaque string for blob: >> URIs. Also, the spec. says that special characters (e.g. "#") should >> be escaped, so that the fragment isn't confused with characters in >> the opaque string production. Other special characters should be >> escaped as well. What problem have you identified with this, and >> what should we be doing instead to solve it? > > "#" is a special character. However, e.g. "ΓΌ", is not. Requiring > characters that are allowed in IRIs to be escaped serves no purpose as > far as I can tell. A good candidate for the URI listserv is the UUID; in defining the repertoire for opaque string, initially pushing for UUID itself met with some resistance from the Chrome team, so I've allowed a more expansive charset, and allow for other characters, modulo them being escaped. This doesn't seem to be too restrictive. Is there a use case you have in mind that finds UUID too restrictive, for instance, or are you able to supply a use case that requires a larger set of (unescaped) characters, including IRI characters? Bear in mind that the main use case for opaque string is unique identifier, NOT shared across the web, and that uniquely identifies an "in-memory" resource that has a pretty defined lifetime. Everything else is honestly just gravy, unless you are able to cough up a use case that gives us all collective pause. I'll gladly change it if you can do so. -- A*
Received on Thursday, 29 September 2011 18:12:22 UTC