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

At a quick glance, this proposal seems to be potentially problematic.  The idea
of a URI scheme to access a particular kind of data seems to be questionable
(i.e. at odds with the principles of web architecture).  My initial sense is
that the problem you are addressing should be addressed through content
labelling, not a new URI scheme.

Before asking others to expend time and effort to study what you propose, can
you please explain (or point to an explanation of) what this scheme achieves
that cannot already be achieved using HTTP or other URI schemes?  (You have
partially explained below why file: isn't suitable, but it's not clear from that
what problem/requirement is not addressed by other schemes.)

#g
--


Arun Ranganathan wrote:
> 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, 3 June 2011 19:03:41 UTC