Discussion of Blob URI Scheme for Binary Data Access | IETF

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion of Blob URI Scheme for Binary Data Access | IETF

Arun Ranganathan-4
Greetings URI listserv!

I'm writing to this listserv at the behest of Mark Nottingham, who sent
me here from the [hidden email] 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 


Reply | Threaded
Open this post in threaded view
|

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

Joseph Holsten
On May 13, 2011, at 1:05 PM, Arun Ranganathan wrote:

> [T]he 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.

Hello! Before you begin on your journey, please accept my apologies. The road to a URI scheme is hard and paved with pedantry. That you use the acronym URL probably means this will be many interesting conversations. That you want the URI to be opaque means you will certainly enjoy the attention of URN fans.

You're going to have to nail down what can and can't be an opaqueString. Why? Because an opaqueString must not contain a '#' or else the fragment is ambiguous. And that's just the beginning.

You'll need to consider why you might allow or forbit '@', ':', and '/' as well. It's not that computers have any issues with them, but they're meaningful to humans.

You'll need to justify why this should or shouldn't be a URN. It's true, no one uses urn: URIs. But no one uses blob: URIs today either. One way is shorter, one is already designed for the purpose you're looking for. If you go with a urn: some people will look at you funny. But if you can actually get a urn to be well used, you might pull up a bunch of other opaque identifiers out of obscurity as well.

You'll need to think about internationalization. You will not enjoy the process. You might be the one author that finally writes a decent guide to writing the internationalization section of a URI scheme spec. You'll probably just repurpose something from another draft and mould it so it looks plausibly accurate without really understanding what it means.

You're going to get hung up on the validity vs reservedness vs authoritativeness of any string that starts with blob:. Is it a valid blob: URI? Does the blob: URI actually identify a real thing? Can my blob: URI share the same string as yours, but identify different things? What if I use a blob: URI for a thing that doesn't exist, and then you create a thing that should be identified by that blob: URI? Do I then get to access it? Can I share access to a resource by sharing its blob: URI? What does it all mean?

But before you do any of that crap, please write out examples for every important way that blob: URIs can be used.
- how to parse a blob: URI (ABNF is great for matching, sometimes okay for tokenizing, and useless for parsing. What does each token mean?)
- how to construct a blob: URI from tokens
- what operations you can perform using those tokens
- every kind of error, and what error recovery looks like
- how a blob: URI could be used outside of a web browser. Yes, things other than browsers still exist.

Finally, you really should talk to the folks at http://magnet-uri.sourceforge.net. You have similar aims and I think you both could benefit from using the same names for things. magnet:?xt=urn:uuid:550e8400-e29b-41d4-a716-446655440000#aboutABBA looks horrible, but that's not enough reason to reinvent the opaque string wheel, right?

Garrulously yours,
--
http://josephholsten.com


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Arun Ranganathan-4
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


Reply | Threaded
Open this post in threaded view
|

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

Arun Ranganathan-4
In reply to this post by Joseph Holsten
Greetings Joseph, and thanks for your response :)


On 5/13/11 7:03 PM, Joseph Anthony Pasquale Holsten wrote:
On May 13, 2011, at 1:05 PM, Arun Ranganathan wrote:

[T]he 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.
Hello! Before you begin on your journey, please accept my apologies. The road to a URI scheme is hard and paved with pedantry. That you use the acronym URL probably means this will be many interesting conversations. That you want the URI to be opaque means you will certainly enjoy the attention of URN fans.


I recognize this, and in fact, *did* actually start with a URN.  And as far as URI/URL goes, I prefer the term URI, but the Stream API [1] (which uses this scheme) actually prefers Blob URL over Blob URI.  I quote:

"A Blob URL is the same as what the File API specification calls a Blob URI, except that anything in the definition of that feature that refers to File and Blob objects is hereby extended to also apply to Stream and GeneratedStream objects."

You're going to have to nail down what can and can't be an opaqueString. Why? Because an opaqueString must not contain a '#' or else the fragment is ambiguous. And that's just the beginning.


This is an excellent point; not defining opaque string better is a shortcoming that I'm happy to fix.

You'll need to consider why you might allow or forbit '@', ':', and '/' as well. It's not that computers have any issues with them, but they're meaningful to humans.

Hmmm.... OK.  Can you be a bit more specific with any use case you have in mind where confusion might arise?

You'll need to justify why this should or shouldn't be a URN. It's true, no one uses urn: URIs. But no one uses blob: URIs today either. One way is shorter, one is already designed for the purpose you're looking for. If you go with a urn: some people will look at you funny. But if you can actually get a urn to be well used, you might pull up a bunch of other opaque identifiers out of obscurity as well.

I honestly did consider URN, but after discussions on the public-webapps listserv, concluded that URNs were not tenable.

Firstly, web developers wrote in saying that the syntax using urn:uuid was simply weird.  Something about "URN" on the open web (of applications) galled the spirit.  Naming is, after all, the second hardest problem in software.  They preferred something that clearly indicated what was going on.  "file:///" is unambiguous with respect to the name of the scheme and what it is trying to do, so we felt that we should have a cleanly named scheme for Blob and Stream access (where a "Stream" may be seen as a dynamic Blob). 

Secondly, implementer opinion was divided between apathy and strong opinions against urn:uuid.  I ignored apathy (though payed attention when major implementers said they had a "slight preference").  For instance, read [2][3][4] on the public-webapps listserv.  I'd hate to call out individual user agents, but I was keen to hear from major browser vendors.  You can follow the relevant thread to see how they stood on urn:uuid vs. a dedicated scheme (such as blob: ).

You'll need to think about internationalization. You will not enjoy the process. You might be the one author that finally writes a decent guide to writing the internationalization section of a URI scheme spec. You'll probably just repurpose something from another draft and mould it so it looks plausibly accurate without really understanding what it means. 

Phew!  Point well taken.  You've assigned me a veritable Hercules 12 Tasks :-)

More seriously, the specification leaves "opaque string" as an implementation detail (only suggesting UUID informatively), much as I used to leave things as an "exercise to the reader" in mathematics ~p.  Do you think the specification itself should provide guidance, or is an informative note sufficient?  I'm inclined to the latter.  We put in a LOT of thought towards i18n in the Firefox project.  I'm sure other projects do as well.

You're going to get hung up on the validity vs reservedness vs authoritativeness of any string that starts with blob:. Is it a valid blob: URI? Does the blob: URI actually identify a real thing? Can my blob: URI share the same string as yours, but identify different things? 

They are actually unique per session, which is why I suggest UUID as being good choices.  Also, scope rules and origin rules in HTML may satisfy these clauses.  But in a nutshell, two blob:URI are not likely to point to the same resource.  After all, a blob:URI is most likely to be used to identify a distinct file on a user's hard drive, which in all likelihood, the user themselves picked.  Also, a blob:URI can point to a web-app generated Blob object using BlobBuilder.  Or, a video-conferencing Stream.  All these resources are pretty much unique in space and time.

What if I use a blob: URI for a thing that doesn't exist, and then you create a thing that should be identified by that blob: URI? Do I then get to access it? Can I share access to a resource by sharing its blob: URI? What does it all mean?

The short answer is no :)

But the point is well taken.  I'm optimistic that the scope rules, origin rules, and lifetime stipulations cover this.  Do you feel they fall short?

But before you do any of that crap, please write out examples for every important way that blob: URIs can be used.
- how to parse a blob: URI (ABNF is great for matching, sometimes okay for tokenizing, and useless for parsing. What does each token mean?)
- how to construct a blob: URI from tokens
- what operations you can perform using those tokens
- every kind of error, and what error recovery looks like
- how a blob: URI could be used outside of a web browser. Yes, things other than browsers still exist.


This point is well taken, and I intend to follow this feedback in the specification.  Thanks again for the helpful suggestions.

Finally, you really should talk to the folks at http://magnet-uri.sourceforge.net. You have similar aims and I think you both could benefit from using the same names for things. magnet:?xt=urn:uuid:550e8400-e29b-41d4-a716-446655440000#aboutABBA looks horrible, but that's not enough reason to reinvent the opaque string wheel, right? 


I'm not sure the magnet project's goals really overlap with identifying distinct resources that are represented by the Blob API (and the File API) or the Stream API.  But I did dutifully study the pointer you provided.

-- A*

[1] See for Blob URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#blob-url
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0642.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0656.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0736.html


Reply | Threaded
Open this post in threaded view
|

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

Mark Nottingham-2
In reply to this post by Joseph Holsten
My .02 below, ymmv.

On 14/05/2011, at 9:03 AM, Joseph Anthony Pasquale Holsten wrote:

> On May 13, 2011, at 1:05 PM, Arun Ranganathan wrote:
>
>> [T]he 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.
>
> Hello! Before you begin on your journey, please accept my apologies. The road to a URI scheme is hard and paved with pedantry. That you use the acronym URL probably means this will be many interesting conversations. That you want the URI to be opaque means you will certainly enjoy the attention of URN fans.

I don't think that is necessary, and perhaps we (as a community) need to make sure that the bar isn't raised *too* high.

Specifically, although Arun and the folks working with him should benefit from the experience of the people on this list, improving their spec in the process, I do NOT think it should have the character of "you must do X or you won't get a URI scheme."

And, luckily, the registration procedures (RFC4395) are behind me; if the bar is too high, it's possible to get a Provisional URI Scheme Registration without such a high level of scrutiny. I'd encourage Arun to go for Permanent, and congratulate him for doing the right thing and trying to engage various stakeholders, but no one should think for a moment that this gives those stakeholders iron-clad control over the outcome (or the ability to refuse a URI scheme).

[...]

> You'll need to justify why this should or shouldn't be a URN. It's true, no one uses urn: URIs. But no one uses blob: URIs today either. One way is shorter, one is already designed for the purpose you're looking for. If you go with a urn: some people will look at you funny. But if you can actually get a urn to be well used, you might pull up a bunch of other opaque identifiers out of obscurity as well.


I'm aware that TBL and others have argued against too many URI schemes. I'll agree that having too many schemes for networked data access is a generally bad thing, but I'll push back (strongly) on the notion that we shouldn't mint new URI schemes for identifying things just because we already have URNs.

Cheers,

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




Reply | Threaded
Open this post in threaded view
|

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

Graham Klyne-2
In reply to this post by Arun Ranganathan-4
[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.

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 [hidden email] 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 
>
>






Reply | Threaded
Open this post in threaded view
|

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

Arun Ranganathan-4
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

Reply | Threaded
Open this post in threaded view
|

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

Arun Ranganathan-4
In reply to this post by Julian Reschke
On 5/14/11 4:06 AM, Julian Reschke wrote:

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

Hi Julien!  Useful feedback as usual.  A few things:

I find that both RFCs 1738 and 1630 jointly provide the broadest
"official" RFC-level overview of the file URI scheme, so I think it's
important enough to cite both.  RFC1738 gives us an overview of the
scheme; RFC1630 gives us an explanation of the intended use, which is
important when explaining why blob: addresses different use cases than
what the file:// scheme does.
>
> - 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?
>

Not really :)  Defining HTTP semantics for the file URI scheme would be
a late-breaking change to a scheme that's already well understood (and
dusty with age).  Also, an important distinction here is that the
file:// URI is best used for the underlying file system, and can more or
less identify directories, files, and resources that have *at least* a
semi-permanent structure in that they are stored on disk.  But Blob
resources are typically short lived, and identify a binary resource *in
memory* for the lifetime of the Document (or sooner!).  Moreover, a Blob
resource may at times *only* live in memory, and may not stem from a
file resource (which could be identified with the "file://" URI
scheme).  Consider the use of the BlobBuilder API [1], or even the
Blob.slice API [2].

Browsers behave inconsistently with respect to the file URI scheme and
XHR, and so it's not really a reliable indicator of what to do next.  
I'd almost say that what browsers do with respect to file URIs and XHR
is developer-facing programmatic sugar :) There are security
implications here as well.

> "In general, this scheme is designed to be used wherever URLs can be
> used on the web."
>
> s/URL/URI/
>
Done.

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

OK, I'll work on clarifying language and notify you when I've put it in
place.


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

No, that would be unsafe, and would be a late-breaking change that we
probably shouldn't undertake.

>
> "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/
>
Done.

> "blob = scheme ":" opaqueString [fragIdentifier]"
>
> The fragment identifier should not be part of the scheme definition.
>

OK -- I think your suggestion is to maybe have a separate section that
discusses fragments?  Is that really necessary?  Is that a convention or
a stylistic preference?  Since fragments are optional, I've only
included them for completeness.  What do I gain by a separate section
that discusses fragments?

> "; 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?

Globally unique -- and I've already made a change suggesting this in the
specification.  Implementers pushed back on UUID as an explicit choice,
strongly urging merely a note that suggests UUID usage.

Left to me, I'd like to mandate UUID :)  But I want this specification
to be widely adopted, and if implementers have nits about mandating
UUID, I'll challenge them to come up with something UUID-like in
characteristics.

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

Yes -- working on this, thanks.  At a minimum I'll prohibit "#" in
Unicode and ASCII.  I wonder if others should be prohibited.

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

OK, I'll add this.

-- A*
[1]
http://www.w3.org/TR/2011/WD-file-writer-api-20110419/#idl-def-BlobBuilder
[2] http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 2011-05-16 19:04, Arun Ranganathan wrote:

> ...
>> - 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?
>>
>
> Not really :) Defining HTTP semantics for the file URI scheme would be a
> late-breaking change to a scheme that's already well understood (and
> dusty with age). Also, an important distinction here is that the file://
> URI is best used for the underlying file system, and can more or less
> identify directories, files, and resources that have *at least* a
> semi-permanent structure in that they are stored on disk. But Blob
> resources are typically short lived, and identify a binary resource *in
> memory* for the lifetime of the Document (or sooner!). Moreover, a Blob
> resource may at times *only* live in memory, and may not stem from a
> file resource (which could be identified with the "file://" URI scheme).
> Consider the use of the BlobBuilder API [1], or even the Blob.slice API
> [2].
> ...

Understood; but most of the things you just mentioned have nothing to do
with the "HTTP semantics" part.

> ...
>> "blob = scheme ":" opaqueString [fragIdentifier]"
>>
>> The fragment identifier should not be part of the scheme definition.
>>
>
> OK -- I think your suggestion is to maybe have a separate section that
> discusses fragments? Is that really necessary? Is that a convention or a
> stylistic preference? Since fragments are optional, I've only included
> them for completeness. What do I gain by a separate section that
> discusses fragments?

I'd recommend not to mention them in the scheme definition and the ABNF.
As you correctly note elsewhere, their syntax is defined by RFC 3986,
and their semantics by the media type.


>> "; 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?
>
> Globally unique -- and I've already made a change suggesting this in the
> specification. Implementers pushed back on UUID as an explicit choice,
> strongly urging merely a note that suggests UUID usage.
>
> Left to me, I'd like to mandate UUID :) But I want this specification to
> be widely adopted, and if implementers have nits about mandating UUID,
> I'll challenge them to come up with something UUID-like in characteristics.

The issue is that unless you mandate a specific syntax, there's no way
to guarantee global uniqueness.

>...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Joseph Holsten
In reply to this post by Arun Ranganathan-4
TL;DR: lock down the opaqueString to be a UUID and all's well.

On May 15, 2011, at 4:33 PM, Arun Ranganathan wrote:

> Greetings Joseph, and thanks for your response :)
>
>
> On 5/13/11 7:03 PM, Joseph Anthony Pasquale Holsten wrote:
>> On May 13, 2011, at 1:05 PM, Arun Ranganathan wrote:
[...]
>> You'll need to consider why you might allow or forbit '@', ':', and '/' as well. It's not that computers have any issues with them, but they're meaningful to humans.
>>
>
> Hmmm.... OK.  Can you be a bit more specific with any use case you have in mind where confusion might arise?

Just that URIs with an authority tend to look like scheme://userinfo@host:port/segment/segment?query. There's no technical reason you  couldn't allow blob:u@h:p/s?q as a valid blob: URI. But people will look at it and assume meaning where there is none.

>> You'll need to justify why this should or shouldn't be a URN. It's true, no one uses urn: URIs. But no one uses blob: URIs today either. One way is shorter, one is already designed for the purpose you're looking for. If you go with a urn: some people will look at you funny. But if you can actually get a urn to be well used, you might pull up a bunch of other opaque identifiers out of obscurity as well.
>>
>
> I honestly did consider URN, but after discussions on the public-webapps listserv, concluded that URNs were not tenable.
>
> Firstly, web developers wrote in saying that the syntax using urn:uuid was simply weird.  Something about "URN" on the open web (of applications) galled the spirit.  Naming is, after all, the second hardest problem in software.  They preferred something that clearly indicated what was going on.  "file:///" is unambiguous with respect to the name of the scheme and what it is trying to do, so we felt that we should have a cleanly named scheme for Blob and Stream access (where a "Stream" may be seen as a dynamic Blob).  

I'm not sure something like blob:550e8400-e29b-41d4-a716-446655440000#aboutABBA could ever clearly indicate what is going on. That said...

> Secondly, implementer opinion was divided between apathy and strong opinions against urn:uuid.  I ignored apathy (though payed attention when major implementers said they had a "slight preference").  For instance, read [2][3][4] on the public-webapps listserv.  I'd hate to call out individual user agents, but I was keen to hear from major browser vendors.  You can follow the relevant thread to see how they stood on urn:uuid vs. a dedicated scheme (such as blob: ).

+1 to implementors' opinions

>> You'll need to think about internationalization. You will not enjoy the process. You might be the one author that finally writes a decent guide to writing the internationalization section of a URI scheme spec. You'll probably just repurpose something from another draft and mould it so it looks plausibly accurate without really understanding what it means.
>>
>
> Phew!  Point well taken.  You've assigned me a veritable Hercules 12 Tasks :-)
>
> More seriously, the specification leaves "opaque string" as an implementation detail (only suggesting UUID informatively), much as I used to leave things as an "exercise to the reader" in mathematics ~p.  Do you think the specification itself should provide guidance, or is an informative note sufficient?  I'm inclined to the latter.  We put in a LOT of thought towards i18n in the Firefox project.  I'm sure other projects do as well.

The simplest thing would be to forbid characters that require encoding, especially percent encoding. If you do this, every valid IRI in UTF-8 is the binary equivalent of its semantically equivalent URI.

If you have IRIs be equivalent to their URIs, an informative note is plenty. If an IRI will require some effort to convert down to a URI, or if ambiguity allows a single URI to be encoded multiple ways, please provide guidance.

>> You're going to get hung up on the validity vs reservedness vs authoritativeness of any string that starts with blob:. Is it a valid blob: URI? Does the blob: URI actually identify a real thing? Can my blob: URI share the same string as yours, but identify different things?
>
> They are actually unique per session, which is why I suggest UUID as being good choices.  Also, scope rules and origin rules in HTML may satisfy these clauses.  But in a nutshell, two blob:URI are not likely to point to the same resource.  After all, a blob:URI is most likely to be used to identify a distinct file on a user's hard drive, which in all likelihood, the user themselves picked.  Also, a blob:URI can point to a web-app generated Blob object using BlobBuilder.  Or, a video-conferencing Stream.  All these resources are pretty much unique in space and time.
>
>> What if I use a blob: URI for a thing that doesn't exist, and then you create a thing that should be identified by that blob: URI? Do I then get to access it? Can I share access to a resource by sharing its blob: URI? What does it all mean?
>>
>
> The short answer is no :)
>
> But the point is well taken.  I'm optimistic that the scope rules, origin rules, and lifetime stipulations cover this.  Do you feel they fall short?

On further study, I think you're fine.

--
http://josephholsten.com


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Arun Ranganathan-4
On 2011-05-16 19:04, Arun Ranganathan wrote:

> ...
>> "blob = scheme ":" opaqueString [fragIdentifier]"
>>
>> The fragment identifier should not be part of the scheme definition.
>>
>
> OK -- I think your suggestion is to maybe have a separate section that
> discusses fragments? Is that really necessary? Is that a convention or a
> stylistic preference? Since fragments are optional, I've only included
> them for completeness. What do I gain by a separate section that
> discusses fragments?
> ...

I just came across
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.3> which
says...:

"4.3. Absolute URI

Some protocol elements allow only the absolute form of a URI without a
fragment identifier. For example, defining a base URI for later use by
relative references calls for an absolute-URI syntax rule that does not
allow a fragment.

    absolute-URI  = scheme ":" hier-part [ "?" query ]

URI scheme specifications must define their own syntax so that all
strings matching their scheme-specific syntax will also match the
<absolute-URI> grammar. Scheme specifications will not define fragment
identifier syntax or usage, regardless of its applicability to resources
identifiable via that scheme, as fragment identification is orthogonal
to scheme definition. However, scheme specifications are encouraged to
include a wide range of examples, including examples that show use of
the scheme's URIs with fragment identifiers when such usage is appropriate."

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Graham Klyne-7
In reply to this post by Arun Ranganathan-4
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 [hidden email] 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 
>
>







Reply | Threaded
Open this post in threaded view
|

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

Arun Ranganathan-4
In reply to this post by Julian Reschke
Greetings URI Listserv,

Firstly, sincere apologies for the delay between responses about the
matter of the File API and the Blob URI scheme.

Secondly, many thanks for all the advice you've sent my way -- it's been
*extremely* useful.  I have updated the File API Editor's Draft:

http://dev.w3.org/2006/webapi/FileAPI/#url

and have informed my edits based on actionable feedback by Joseph A. P.
Holsten [1], Julian Reschke (e.g. see email #[2], amongst others), and
Graham Klyne (both in email# [3] and off list).  My goal is to respond
to concerns raised on this list before moving towards W3C's CR phase;
where feasible, I've responded to your feedback with additional details,
notably justification of choices made as well as some more formalism in
the definition of things.

Thanks again,

-- A*

[1] http://lists.w3.org/Archives/Public/uri/2011May/0012.html
[2] http://lists.w3.org/Archives/Public/uri/2011May/0011.html
[3] http://lists.w3.org/Archives/Public/uri/2011May/0006.html

Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
Arun,

I think you should send the request for reviews on [hidden email] list.  I'm cc'ing this message there.

Several comments.  As a global editorial.  You use the scheme: notation, whereas the 'scheme' or scheme notation is technically clearer.  See RFC Erratum Report 2756 (http://www.rfc-editor.org/errata_search.php?rfc=6196&eid=2756).

Section 6.7.3:

blob = scheme ":" opaqueString [fragIdentifier]

RFC 3986 specified that particular schemes' syntax should not define fragment IDs (also see below).

Section 6.7.3.1:

hexDigit =
         "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
         "a" / "b" / "c" / "d" / "e" / "f" /
         "A" / "B" / "C" / "D" / "E" / "F"

This could be imported from RFC 5234 <HEXDIG> (http://tools.ietf.org/html/rfc5234#appendix-B.1).

Ibid:

UUID is one potential option available to user agents for use with Blob URIs as opaque strings, and their use is strongly encouraged.

What is the generic syntax for opaqueString, except one defined for UUIDs?  I suppose it is RFC 3986 <path-rootless> here, but considering 36 chars min. you may define

opaqueString = 36*pchar

where <pchar> are defined in RFC 3986.  I see there are some limitations on allowed char range, so you may reflect this is the ABNF as well.

Section 6.7.4 isn't necessary.  You MUST NOT describe fragment ID in the scheme's syntax, neither must you define it semantics.

You should be clear about the scheme's semantics, what does a particular 'blob' URI refer to and how it should be resolved.  Section 6.7.7 may lead one to the conclusion that 'blob' URIs are connected with HTTP, but I think clarifying this issue won't be unnecessary.

I see your document lacks IANA considerations, which would request scheme's registration with IANA, as required by RFC 4395.

Thanks,
Mykyta Yevstifeyev

11.08.2011 1:20, Arun Ranganathan wrote:
Greetings URI Listserv,

Firstly, sincere apologies for the delay between responses about the matter of the File API and the Blob URI scheme.

Secondly, many thanks for all the advice you've sent my way -- it's been *extremely* useful.  I have updated the File API Editor's Draft:

http://dev.w3.org/2006/webapi/FileAPI/#url

and have informed my edits based on actionable feedback by Joseph A. P. Holsten [1], Julian Reschke (e.g. see email #[2], amongst others), and Graham Klyne (both in email# [3] and off list).  My goal is to respond to concerns raised on this list before moving towards W3C's CR phase; where feasible, I've responded to your feedback with additional details, notably justification of choices made as well as some more formalism in the definition of things.

Thanks again,

-- A*

[1] http://lists.w3.org/Archives/Public/uri/2011May/0012.html
[2] http://lists.w3.org/Archives/Public/uri/2011May/0011.html
[3] http://lists.w3.org/Archives/Public/uri/2011May/0006.html



Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Arun Ranganathan-4
On 2011-08-11 00:20, Arun Ranganathan wrote:

> Greetings URI Listserv,
>
> Firstly, sincere apologies for the delay between responses about the
> matter of the File API and the Blob URI scheme.
>
> Secondly, many thanks for all the advice you've sent my way -- it's been
> *extremely* useful. I have updated the File API Editor's Draft:
>
> http://dev.w3.org/2006/webapi/FileAPI/#url
>
> and have informed my edits based on actionable feedback by Joseph A. P.
> Holsten [1], Julian Reschke (e.g. see email #[2], amongst others), and
> Graham Klyne (both in email# [3] and off list). My goal is to respond to
> concerns raised on this list before moving towards W3C's CR phase; where
> feasible, I've responded to your feedback with additional details,
> notably justification of choices made as well as some more formalism in
> the definition of things.
> ...

I see that there's now a discussion of URN:UUID:; that's good. I still
think the reasons for inventing a new scheme are unconvincing.

The problem of global uniqueness is still there; unless you have a
REQUIRED syntax for the opaque part, there is no way to guarantee global
uniqueness.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Arun Ranganathan-4
On 8/11/11 12:46 AM, Julian Reschke wrote:

> On 2011-08-11 00:20, Arun Ranganathan wrote:
>> Greetings URI Listserv,
>>
>> Firstly, sincere apologies for the delay between responses about the
>> matter of the File API and the Blob URI scheme.
>>
>> Secondly, many thanks for all the advice you've sent my way -- it's been
>> *extremely* useful. I have updated the File API Editor's Draft:
>>
>> http://dev.w3.org/2006/webapi/FileAPI/#url
>>
>> and have informed my edits based on actionable feedback by Joseph A. P.
>> Holsten [1], Julian Reschke (e.g. see email #[2], amongst others), and
>> Graham Klyne (both in email# [3] and off list). My goal is to respond to
>> concerns raised on this list before moving towards W3C's CR phase; where
>> feasible, I've responded to your feedback with additional details,
>> notably justification of choices made as well as some more formalism in
>> the definition of things.
>> ...
>
> I see that there's now a discussion of URN:UUID:; that's good. I still
> think the reasons for inventing a new scheme are unconvincing.

We'll have to agree to disagree, agreeably :)

>
> The problem of global uniqueness is still there; unless you have a
> REQUIRED syntax for the opaque part, there is no way to guarantee
> global uniqueness.

Actually, since the last time we discussed this, I've strengthened the
requirements considerably, even suggesting character ranges from
Unicode.  I stop just shy of REQUIRING UUID, but you'll note that this
is a substantial change (banning reserved chars, etc.).  Your suggestion
to me was to flesh out the "repertoire" of the opaqueString production,
and I've tried to do just that, but also allowed Chrome's use of blob:
URI labeling (I disagree with it, but not strongly enough to tell them
not to do it).  I think we've probably got a pretty good guarantee of
global uniqueness; not least of all, I REQUIRE global uniqueness, make a
prescription, and leave the actual detail to implementers.  I think this
stands as sufficient.

-- A*

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 2011-08-11 21:08, Arun Ranganathan wrote:

> ...
> Actually, since the last time we discussed this, I've strengthened the
> requirements considerably, even suggesting character ranges from
> Unicode. I stop just shy of REQUIRING UUID, but you'll note that this is
> a substantial change (banning reserved chars, etc.). Your suggestion to
> me was to flesh out the "repertoire" of the opaqueString production, and
> I've tried to do just that, but also allowed Chrome's use of blob: URI
> labeling (I disagree with it, but not strongly enough to tell them not
> to do it). I think we've probably got a pretty good guarantee of global
> uniqueness; not least of all, I REQUIRE global uniqueness, make a
> prescription, and leave the actual detail to implementers. I think this
> stands as sufficient.
> ...

I appreciate the effort :-)

It doesn't change the fact that you can't get reliable global uniqueness
unless you require a *specific* format.

Please remind me: why can't you required a UUID + postfix?

Best regards, Julian