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

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.

You're going to have to nail down what can and can't be an opaqueString. Why? Because an opaqueString must not contain a '#' or else the fragment is ambiguous. And that's just the beginning.

You'll need to consider why you might allow or forbit '@', ':', and '/' as well. It's not that computers have any issues with them, but they're meaningful to humans.

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.

You'll need to think about internationalization. You will not enjoy the process. You might be the one author that finally writes a decent guide to writing the internationalization section of a URI scheme spec. You'll probably just repurpose something from another draft and mould it so it looks plausibly accurate without really understanding what it means. 

You're going to get hung up on the validity vs reservedness vs authoritativeness of any string that starts with blob:. Is it a valid blob: URI? Does the blob: URI actually identify a real thing? Can my blob: URI share the same string as yours, but identify different things? What if I use a blob: URI for a thing that doesn't exist, and then you create a thing that should be identified by that blob: URI? Do I then get to access it? Can I share access to a resource by sharing its blob: URI? What does it all mean?

But before you do any of that crap, please write out examples for every important way that blob: URIs can be used.
- how to parse a blob: URI (ABNF is great for matching, sometimes okay for tokenizing, and useless for parsing. What does each token mean?)
- how to construct a blob: URI from tokens
- what operations you can perform using those tokens
- every kind of error, and what error recovery looks like
- how a blob: URI could be used outside of a web browser. Yes, things other than browsers still exist.

Finally, you really should talk to the folks at http://magnet-uri.sourceforge.net. You have similar aims and I think you both could benefit from using the same names for things. magnet:?xt=urn:uuid:550e8400-e29b-41d4-a716-446655440000#aboutABBA looks horrible, but that's not enough reason to reinvent the opaque string wheel, right? 

Garrulously yours,
--
http://josephholsten.com

Received on Friday, 13 May 2011 23:03:30 UTC