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

On 13.05.2011 20:05, Arun Ranganathan wrote:
> Greetings URI listserv!

Hi there!

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

A few comments on the definition in "6.7. A URI for Blob and File 
reference":

"Whereas the file URI scheme (defined in [RFC1630] and [RFC1738]) allows 
user agents to surface local file and directory structures, it cannot be 
used within web applications owing to origin considerations and lack of 
HTTP [HTTP] semantics."

- Citing RFC 1738 should be sufficient, unless 1630 contains any 
additional information. Does it?

- You *could* define HTTP semantics for file:, so that doesn't seem a 
compelling reason not to use it. Actually, browsers do so in XHR 
already, no?

"In general, this scheme is designed to be used wherever URLs can be 
used on the web."

s/URL/URI/

"This scheme can allow for fragment identifiers for well-defined format 
types. For example, if the file selected is an SVG file, this scheme 
should allow for SVG fragment identifiers. If the file selected is an 
HTML file, this scheme should allow for fragment identifiers within an 
HTML document."

This is very misleading. Fragment identifier semantics are a property of 
the media type, not the URI scheme.

"Whereas file URIs are subject to strict same origin restrictions for 
security reasons and allow directory browsing, this scheme is applicable 
only to user-selected files (and to Blob objects that web applications 
generate)."

An alternative would have been to relax the same-origin constraints for 
some file: URIs. Just sayin'.

"A blob: URI consists of the blob: scheme and an opaque string, along 
with zero or one fragment identifiers."

s/zero or one/an optional/

"blob = scheme ":" opaqueString [fragIdentifier]"

The fragment identifier should not be part of the scheme definition.

"; opaqueString could be a UUID in its canonical form
; opaqueString tokens MUST be unique"

Unique or globally unique? If the latter, how can you be sure without 
mandating a specific format?

Furthermore, you need to state the allowed character repertoire for 
opaqueString.

...finally, as this probably will become an FAQ, it would be good to 
include the rational for not simply using "urn:uuid:" as syntax.

Best regards, Julian

Received on Saturday, 14 May 2011 08:07:03 UTC