W3C home > Mailing lists > Public > uri@w3.org > May 2011

Re: Discussion of Blob URI Scheme for Binary Data Access | IETF

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 16 May 2011 12:35:39 +1000
Cc: arun@mozilla.com, uri@w3.org
Message-Id: <62314343-01BA-4B99-8658-C32DDE6A381A@mnot.net>
To: Joseph Anthony Pasquale Holsten <joseph@josephholsten.com>
My .02 below, ymmv.

On 14/05/2011, at 9:03 AM, Joseph Anthony Pasquale Holsten wrote:

> On May 13, 2011, at 1:05 PM, Arun Ranganathan wrote:
>> [T]he File API introduces a URI scheme for Blob access [4].  The URI scheme uses a subset of the HTTP status codes, and is designed to be used wherever http URIs can be used within HTML markup and within APIs in JavaScript (e.g. for "img src =", alongside XMLHttpRequest, etc.).  The nascent URL API [5] which coins and revokes blob: URIs is also used with the Stream API [6] for video-conferencing use cases, and thus this scheme is becoming integral to emerging technologies under the broad aegis of HTML.
> Hello! Before you begin on your journey, please accept my apologies. The road to a URI scheme is hard and paved with pedantry. That you use the acronym URL probably means this will be many interesting conversations. That you want the URI to be opaque means you will certainly enjoy the attention of URN fans.

I don't think that is necessary, and perhaps we (as a community) need to make sure that the bar isn't raised *too* high. 

Specifically, although Arun and the folks working with him should benefit from the experience of the people on this list, improving their spec in the process, I do NOT think it should have the character of "you must do X or you won't get a URI scheme."

And, luckily, the registration procedures (RFC4395) are behind me; if the bar is too high, it's possible to get a Provisional URI Scheme Registration without such a high level of scrutiny. I'd encourage Arun to go for Permanent, and congratulate him for doing the right thing and trying to engage various stakeholders, but no one should think for a moment that this gives those stakeholders iron-clad control over the outcome (or the ability to refuse a URI scheme).


> You'll need to justify why this should or shouldn't be a URN. It's true, no one uses urn: URIs. But no one uses blob: URIs today either. One way is shorter, one is already designed for the purpose you're looking for. If you go with a urn: some people will look at you funny. But if you can actually get a urn to be well used, you might pull up a bunch of other opaque identifiers out of obscurity as well.

I'm aware that TBL and others have argued against too many URI schemes. I'll agree that having too many schemes for networked data access is a generally bad thing, but I'll push back (strongly) on the notion that we shouldn't mint new URI schemes for identifying things just because we already have URNs. 


Mark Nottingham   http://www.mnot.net/
Received on Monday, 16 May 2011 02:36:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:15 UTC