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

From: Arun Ranganathan <[email-masked]>
Date: Thu, 12 May 2011 16:02:25 -0400

Greetings httpbis listserv!

My name is Arun Ranganathan, and I'm the current editor of the File API 
[1] specification; I'm also the outgoing 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 working group, 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 on the web.  The nascent URL API [5] which coins 
and revokes blob: URIs is also used with the Stream API [6] for 
video-conferencing use cases.

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 choises for APIs like XMLHttpRequest, don't supply response 
codes, etc. 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 embarking upon 
an IETF standardization track for this protocol.

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

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 12 May 2011 15:30:39 -0700

As the author of dynamic compilers, standardization is easier if there 
is interchange of JavaScript into intermediate language or XML flow.

I assume you meant "desired" immutable data, yet is there any 
constraint? (Not even XPath?) The reasons are more obvious if the http 
query *has to* specifically request javascript for acceptable response 
rather then the webserver present that by default. The "User-Agent:" 
field allows workaround for now. By default, the web-server "shouldn't" 
allow just any script (botnet) be server-pushed or server-solicited. 
Web-servers can't just trash the <script> tags.

However, this inspired me to say maybe the "User-Agent:" could be set to 
"urn:..." as the intermediate implementation such that vendors can apply 
security updates quicker. I assumed people aren't gonna to update their 
web-server software (too costly. i.e. hardware as in "farms"), yet they 
can update their plug-in modules less expensively (seeds).

Economy wise, if "User-Agent:" is set to "urn:..." then certificates 
make sense for cache. No certificate, no cache.

Is that deal better for... blob?

On 05/12/2011 01:02 PM, Arun Ranganathan wrote:
> My name is Arun Ranganathan, and I'm the current editor of the File 
> API [1] specification; I'm also the outgoing 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.
>
> 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 on the web.  The nascent URL API [5] which 
> coins and revokes blob: URIs is also used with the Stream API [6] for 
> file:/// URI scheme, which many browsers support for directory 
> browsing of the underlying file system, but for little else (file:/// 
> URIs are unwise choises for APIs like XMLHttpRequest, don't supply 
> response codes, etc. 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.
>

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 May 2011 12:52:33 +1000

Hi Arun,

Thanks for the heads-up.

I don't think that this group will have a *lot* to say about this, at least from an HTTP perspective, since it's only incidentally related to HTTP.

Other groups that might have some thoughts include the URI list <mailto:[email-masked]> and the APP area list <mailto:[email-masked]>. I can forward to them if you'd like to avoid the overhead of subscribing.

Cheers,

On 13/05/2011, at 6:02 AM, Arun Ranganathan wrote:

> My name is Arun Ranganathan, and I'm the current editor of the File API [1] specification; I'm also the outgoing 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 working group, 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 on the web.  The nascent URL API [5] which coins and revokes blob: URIs is also used with the Stream API [6] for video-conferencing use cases.
> 
> 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 choises for APIs like XMLHttpRequest, don't supply response codes, etc. 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 embarking upon an IETF standardization track for this protocol.
> 
> -- A*
> 
> [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
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 13 May 2011 05:55:51 +0200

>an IETF standardization track for this protocol.

Well there are all sorts of problems with your proposal (bulleted lists
with half a dozen of items do not belong in an Abstract, you list RFC
1738 as normative reference but the document does not seem to be refer-
enced at all, you mention "Data URLs that do not have media-types" which
cannot exist because there is a default if no media type is given, you
have a section on "Creating and Revoking a Blob URI" that does not say
why you would want to "revoke" a "Blob URI", this appears to be a W3C
technical report, but the latest published version seems to be over six
months old, and the version before that came about a year after the
previous draft, even though the W3C requires publication every three
months, the text for 'readAsArrayBuffer' is the same as the text for
other methods except for easily missed details, and so on and so forth).

However, as far as the HTTPbis Working Group goes, I do not see what we
could offer as feedback. What do you think someone who knows everything
about HTTP but not much else should comment on? Could you list some of
the issues where you are unsure you've made the right decision? Things
you feel are not optimal, not elegant? Why aren't you using one of the
many existing schemes? I don't mean to be overly critical, it's just
that you are essentially asking for help with the document, and I don't
see how this community in particular could help. Some insight into how
you are thinking about this proposal in relation to HTTP would help.

Generally speaking, in the IETF you find people who like to solve what
problems they encounter. Telling people about the problems you've found
and what pain you are trying to address is likely to generate the most
useful feedback (or pointers where to get that feedback from). If I were
to write your mail, I would start out saying "This is the goal, these
are the problems, these solutions came to mind but didn't meet the mark
because of problems such and such, so the idea is to have this which
solves the problems so and so".

That would enable people to point out things you've missed, criticise
the design, understand where you are coming from, give them an idea what
work has been done and what still needs to be done. It would also give
an idea of whether you feel you are past that, meaning it might be best
to focus, say, on how the methods are named, or point out performance or
usability problems in dealing with large or streamed data sets. You may
also just be looking for, say, whether the design or the details are in
some way objectionable from a HTTP perspective. How about XMLHttpRequest
for that matter? Is that relevant? Do you want to know about how this
new scheme interacts with existing HTTP frameworks?

The point is that from your message, "we" do not have much of a way to
connect to your thinking about the proposal, so "we" would largely be
drawing a blank when thinking about what feedback to provide.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Arun Ranganathan <[email-masked]>
Date: Fri, 13 May 2011 13:19:05 -0400

> I don't think that this group will have a *lot* to say about this, at least from an HTTP perspective, since it's only incidentally related to HTTP.

Thanks for the response, Mark :)  Yes, accessing Blob objects via the 
blob: scheme reuses a small subset of the HTTP response codes, which the 
blob: scheme appropriates.

If anybody feels like sending me comments, I'd be happy to receive 
them.  In the meantime:
> Other groups that might have some thoughts include the URI list<mailto:[email-masked]>  and the APP area list<mailto:[email-masked]>. I can forward to them if you'd like to avoid the overhead of subscribing.

I'm actually happy enough to subscribe.  Thanks very much for the offer 
to forward, and the suggestion for the listservs where I should forward 
this to.

-- A*

---

From: Arun Ranganathan <[email-masked]>
Date: Fri, 13 May 2011 15:01:41 -0400

Bjoern,

Firstly, thanks for your response :-)

On 5/12/11 11:55 PM, Bjoern Hoehrmann wrote:
> with half a dozen of items do not belong in an Abstract,

This appears to be a subjective stylistic nit (others in the WebApps WG 
actually like the rapid jump to IDLs), but for what it's worth, there's 
always room for improvement, and the Abstract can certainly be tightened.

> you list RFC
> enced at all,

RFC1738 is normative for URLs and for "file://", and in the File API 
those were important considerations while we coined a scheme for URLs to 
access binary data, and added more functionality over what the "file://" 
scheme allows for.  Upon reflection, this reference *can* be moved to 
the informative reference section if it makes you feel more comfortable.

> you mention "Data URLs that do not have media-types" which
> cannot exist because there is a default if no media type is given,

Certainly I'm aware of the default!  And Data URLs without a media-type 
production certainly *can* exist as plain text (which is what Firefox 
does today).  But I mention the lack of media-types simply to provide 
guidance on what to do if the Blob's type attribute is the empty 
string.  Since the slice method of a Blob can force an optional 
media-type, implementers/web developers reviewing the File API called 
for guidance about what to do if one was missing.  Data URLs can include 
a media-type or not include a media-type; this section merely provides 
guidance on what to do with Blob objects that don't have a media type.  
Since you raise a nit here, I'll look for language that's even clearer.

>   you
> why you would want to "revoke" a "Blob URI",

I can certainly include a note about why a revocation API is useful, but 
it is generally obvious to web developers: if the reference to a file 
within their application is no longer valid, that file reference should 
generate a 404.  In addition the HTML document cleanup steps, there's a 
revocation API that web developers can use.

> this appears to be a W3C

I'd be hard-pressed to find W3C WebApps specifications or editor's 
drafts that *totally* conform to this rule.  It is true, however, that 
Working Drafts of the File API could have been published more often.  
Chalk that up to editors having lots of things to do :-)  
Implementations have typically followed the Editor's Draft as opposed to 
the Working Draft, much as with the HTML specification as a "living 
standard."

The biggest difference with readAsArrayBuffer is that it suggests 
multiple ArrayBuffer objects are returned, which could be made more 
precise.  Whether this is through multiple ArrayBuffer returns depending 
on the point at which "result" is accessed, or whether this is an 
incremented "result" is implementation-specific.  The other differences 
are with encodings, which aren't necessary to mention with respect to 
ArrayBuffers.  Thank you for drawing this to my attention -- this could 
improve.
> you are thinking about this proposal in relation to HTTP would help.

Point well taken.  Here's what motivates my email:

1. We've introduced a new scheme essentially touted as the "new and 
better" file:// URI, with functionality useful to web applications, such 
as use alongside <img src=...>, use with XMLHttpRequest (which can have 
a response body of Blob), etc.  The file:// URI scheme was done under 
IETF's aegis and advanced as an RFC; what should we do with respect to 
the blob: URI scheme?  From a standardization perspective, is moving 
towards LC with the File API sufficient?  I felt that this listserv 
might have advice on that matter.

2. I'm also soliciting general feedback.  For example, earlier in the 
process, we thought we'd re-use the URN scheme (specifically, something 
like urn:uuid).  But there were a few drawbacks here.  Firstly, the urn: 
scheme was "alien" to web developers who write JavaScript applications, 
etc.   Secondly, not all user agents were reconciled to using UUID.  
Implementations were surfacing that were vendor-prefixed (e.g. moz-file: 
etc.).  Most implementers preferred a new scheme for various reasons.

> solves the problems so and so".

Point well taken.

This is the goal:

1. It was desirable to refer to Blobs of data with a URL.  This was 
useful to refer to textures (used with WebGL, for example), or to 
manipulate files on web pages (use an image on the underlying file 
system as the "src" of an image).  APIs that use URLs, such as 
XMLHttpRequest, behave inconsistently when given file:// URLs today.  So 
we wanted a URL scheme that essentially could be used just about 
anywhere an http URL could be used.

2. It was desirable to have well-defined "retrieval semantics" around 
those Blob resources.  What happens with the underlying file has 
shifted?  What happens when that file is not allowed to be accessed, or 
is destroyed?  Moreover, Blob objects can be created on the fly with the 
BlobBuilder API [1].

The Blob URI was the solution we came up with.  It reused a subset of 
HTTP response codes, and addressed use cases 1. and 2.

Problems along the way was an elaborate discussion of why we 
specifically didn't reuse an existing scheme.

> drawing a blank when thinking about what feedback to provide.

I really appreciate the time you've taken, and hope I've made some 
things clearer.

-- A*

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 13 May 2011 12:43:46 -0700

More honest implementation of decentralized XMPP would be the good 
start. I mean honest as in avoid 0-point-botnets and more physicality to 
virtualization.

Some implement streams where you have to subscribe to each one, with 
hidden expectation to offload compute "payload". Some others implement 
servers that subscribe to those streams to compute that payload and 
combine those streams into customizable stream aggregates. When they try 
to offload the "payload" again from the aggregates, they get overly 
aggressive "botnets".

People have tried to avoid the botnets and go more direct to the API of 
those servers and discoverable resources. That's where we have mapped 
you... X

X only wants to allow Y and Z transversal with optional map of U and V. 
In fact, YUV is already standard.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 13 May 2011 16:46:07 -0700

I wanted to point out some shader language as an example. Is this the WG 
to standardize something like GLSL into XML flow as an intermediate 
solution/language? To make some things more obvious or clarification, 
yes. The "urn:..." helps in HTTP headers. We've discussed low-level 
scalar data (LLSD) endlessly in the VWRAP WG for pivotal data. Named 
multi-parts sections (stream & blob:), something like Collada DAE that 
indexes those named sections (file:), already achieves what you want, 
with additional work needed to compile GLSL to XML flow (for proof first 
instead of render asset as-is at "Home").

Currently, there are some copyright/patent issues that seem to make 
people anxious about the above. Some try to analyze/solve it with 
forced-wait states, as that is the same old "look & feel" cure for gray 
goo... ☮

Wonder if there is some HTTP Header that says... "query expires upon 
some-unit of energy usage"... with microseconds as default such that the 
target system *secures the actual* power usage per second.

 > Expires: 1kW/s

206 "Partial Content"

On 05/13/2011 12:43 PM, Dzonatas Sol wrote:
> start. I mean honest as in avoid 0-point-botnets and more physicality 
> to virtualization.
>
> combine those streams into customizable stream aggregates. When they 
> try to offload the "payload" again from the aggregates, they get 
> overly aggressive "botnets".
>
> People have tried to avoid the botnets and go more direct to the API 
> of those servers and discoverable resources. That's where we have 
> mapped you... X
>
> X only wants to allow Y and Z transversal with optional map of U and 
> V. In fact, YUV is already standard.
>

--