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

On 5/16/11 3:40 AM, Graham Klyne wrote:
> [Sent previously using a different email address - apologies if 
> multiple copies turn up.]
>
> 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.

Greetings Graham!

The principles of web architecture that you're likely referring to are 
probably the guidance provided for URI schemes (along with sage counsel 
about why new schemes are "costly")[1] and the counsel that URI opacity 
should be a good practice, meaning that explicitly choosing a scheme 
called "blob:" goes against the tenet that one shouldn't try to infer 
properties about the resource from the URI [2].  And by "content 
labeling" you probably mean representation *type* or media type [3].

We dutifully did consider all of these.  I'll point out that:

1. We considered scheme reuse, including urn:uuid.  In past 
correspondence, I've discussed the shortcomings of this on this 
listserv, including both implementer and web developer concerns.

2. While URI opacity is good in practice, we also wanted a scheme that 
clearly identified "in memory" resources with retrieval semantics 
(including response codes).  We wouldn't want to change the behavior of 
"file://" -- although inconsistent in browsers, it is already fairly 
well defined for directory and file system browsing, with 
well-identified security caveats.  Then, http URIs are good for 
identifying resources that can be retrieved over DNS, using the well 
understood request-response protocol already in place, but Blob 
resources are typically "in-memory" resources that, by design, must have 
a short life.  So, we chose a new scheme with an explicit scheme name.  
It would reduce confusion.

3. Oftentime, there IS no affiliated media-type with Blob resources!  
They may be "split" chunks of an existing binary resource, or distinct 
chunks coined "on-the-fly" by the user agent.  Chrome already implements 
BlobBuilder [4] and Firefox intends to follow-suit.  Most Blob resources 
are likely to be files that are accessed within a web application via 
the File API [5], in which case there *might* be a media-type that user 
agents can discern, but all bets for type are off if the resource is 
split along byte-ranges.

>
> 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.)
>

HTTP isn't right -- we want identifiers for short-lived resources unique 
in space and time.  Moreover, http URIs are affiliated with 
well-understood resources already, with well-understood ways of 
retrieving resources.  Interestingly, the Google Chrome team has chosen 
to refer to Blob resources with code URIs that look like this:

blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1 [6]

You'll note that this didn't meet with widespread approval within the 
public-webapps listserv, but nothing in the specification of the blob: 
scheme rules that kind of usage out.

urn:uuid isn't right; we've discussed this already.

The "file://" scheme isn't right, since you can't use it to identify a 
file on the underlying file-system; moreover, although *some* user 
agents allow it to be used, albeit unreliably, with APIs such as 
XMLHttpRequest, it won't do for our problem space without substantial 
change.

Graham, thanks for engaging with me on this subject!

-- A*

[1] http://www.w3.org/TR/webarch/#URI-scheme
[2] http://www.w3.org/TR/webarch/#uri-opacity
[3] http://www.w3.org/TR/webarch/#internet-media-type
[4] 
http://www.w3.org/TR/2011/WD-file-writer-api-20110419/#idl-def-BlobBuilder
[5] http://dev.w3.org/2006/webapi/FileAPI/
[6] 
http://www.html5rocks.com/tutorials/workers/basics/#toc-inlineworkers-bloburis

Received on Monday, 16 May 2011 15:34:39 UTC