Re: [File API] opaque string
On 9/29/11 12:29 PM, Anne van Kesteren wrote: On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan 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*
Re: [File API] opaque string
On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] opaque string
On 8/31/11 3:45 AM, Anne van Kesteren wrote: On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan wrote: On 8/14/11 6:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? You can; they have to be escaped. 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? I also noticed that "Use Cases for a New Scheme" is actually only listing requirements, not use cases. Maybe it should be renamed? Agreed! I will rename it "Requirements for a New Scheme." -- A*
Re: [File API] opaque string
On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan wrote: On 8/14/11 6:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? You can; they have to be escaped. Yeah sure, every URI is an IRI, but that is not what I am asking. The bit on UUID should be turned into a note if it is non-normative instead of saying it is non-normative. Done (with an Appendix). Cool! I also noticed that "Use Cases for a New Scheme" is actually only listing requirements, not use cases. Maybe it should be renamed? -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] opaque string
On 8/14/11 6:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? You can; they have to be escaped. The bit on UUID should be turned into a note if it is non-normative instead of saying it is non-normative. Done (with an Appendix). -- A*
Re: [File API] opaque string
On 8/15/11 12:27 PM, Anne van Kesteren wrote: On Mon, 15 Aug 2011 18:06:30 +0200, Arun Ranganathan wrote: On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the "permissible charset" for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? I do not really see why we should be escaping … or other characters outside the ASCII range. After all these URLs are not going over HTTP so we do not have the same restrictions. These URLs are highly localized, but they also allow for fragment identifiers, so the "repertoire" of the opaqueString should be defined lest the fragment get hosed. Being conservative, I reasoned that all the reserved chars should be banned. It sounds like you think forbidding the URI-reserved chars is a bad idea. OK, I'm willing to relax this restriction. Do you have a proposal? I am not really sure what URL-tagging is in this context and I think Opera can implement whatever is decided. I just would like it not to be something arbitrary. I'm sorry, I should be clearer. Chrome folks want Blob URLs that look like this: blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1 [1] This string is still opaque, but seems to be useful to them to "tag" the blob URI with some metadata before something like a UUID sequence. I want to allow this, but also want to make fragments valid. *Enforcing* UUID would make my life simpler :) But this use is also valid. -- A* [1] http://www.html5rocks.com/en/tutorials/workers/basics/#toc-inlineworkers-bloburis
Re: [File API] opaque string
On Mon, 15 Aug 2011 18:06:30 +0200, Arun Ranganathan wrote: On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the "permissible charset" for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? I do not really see why we should be escaping … or other characters outside the ASCII range. After all these URLs are not going over HTTP so we do not have the same restrictions. I am not really sure what URL-tagging is in this context and I think Opera can implement whatever is decided. I just would like it not to be something arbitrary. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] opaque string
On 8/14/11 9:00 AM, Anne van Kesteren wrote: Why can you not use characters legally allowed in IRIs? Are you referring to the "permissible charset" for ranges of characters or the condition disallowing reserved characters? I've only omitted the ones that should be percent-encoded. Honestly, we just need terse prose requiring something globally unique; I wanted to allow the Chrome Team's use of URL-tagging, and largely do allow it if they percent encode things. Is this nit backed by a use case? Does Opera wish to URl-tag the opaqueString production as well, and does escaping characters fall short of that requirement? The bit on UUID should be turned into a note if it is non-normative instead of saying it is non-normative. OK.
[File API] opaque string
Why can you not use characters legally allowed in IRIs? The bit on UUID should be turned into a note if it is non-normative instead of saying it is non-normative. -- Anne van Kesteren http://annevankesteren.nl/
