On 9/29/11 12:29 PM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan
<[email protected]> 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*
