Discussion of Blob URI Scheme for Binary Data Access | IETF

Greetings URI listserv!

I'm writing to this listserv at the behest of Mark Nottingham, who sent 
me here from the ietf-http-wg@w3.org listserv. This email is about a 
"new" URI scheme used to access binary data, and we'd like feedback on 
it, as well as advice on whether any further standardization endeavors 
are necessary.

My name is Arun Ranganathan, and I'm the current editor of the File API 
[1] specification (sometimes called the HTML5 File API, which is 
unfortunate); I'm also the former Chair of the WebGL Working Group [2] 
(which brings hardware-accelerated 3D graphics to the web), and have a 
continued interest in allowing binary data to be securely accessed and 
manipulated on the web.  I'm sponsored by Mozilla.

The File API introduces the notion of a Blob object [3], which 
represents immutable binary data.  A file from the underlying file 
system can be asynchronously read as a Blob object into various data 
formats, for example.  The existing File interface in JavaScript 
inherits from Blob.

Additionally, and most significantly for this listserv and this 
discussion, the 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.

Browsers such as Chrome already implement blob: URIs [7]; Firefox's 
implementation will follow-suit, although is likely to be 
vendor-prefixed.  Our goals are to address the shortcomings of the 
file:/// URI scheme, which many browsers support for directory browsing 
of the underlying file system, but for little else (file:/// URIs are 
unwise choices for APIs like XMLHttpRequest, don't supply response 
codes, etc.).  The blob: scheme was designed to address the use case of 
dereferencing files and binary data on the web safely, since data: URIs 
have shortcomings as well, and can't really be used for streams of data.

We'd welcome your feedback, including suggestions about whether 
embarking upon an IETF standardization track for this protocol is 
necessary.  The File API will soon be initiating a CFC for Last Call status.

-- A*

[1] File API: http://dev.w3.org/2006/webapi/FileAPI/
[2] WebGL: http://www.khronos.org/webgl/
[3] Blob defintion: http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob
[4] blob: URI scheme: http://dev.w3.org/2006/webapi/FileAPI/#url
[5] URL API: http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking
[6] Stream API: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#stream-api 

[7] Use of blob: URI scheme in demos: 
http://www.html5rocks.com/tutorials/workers/basics/#toc-inlineworkers-bloburis

Received on Friday, 13 May 2011 18:06:12 UTC