File API "oneTimeOnly" is too poorly defined

I didn't realize this was actually added to the spec:

> The optional options dictionary argument contains a key, oneTimeOnly that
defaults to false. If set to true, then the first time the Blob URI is
dereferenced, user agents MUST automatically revoke that Blob URI without
needing a call to revokeObjectURL() on the Blob URI.

What does "dereferenced" mean?  Where is it defined?  What happens if two
XHR calls open() a blob URL one after the other (causing fetches to be
queued for it in separate task queues, whose order of execution is
undefined)?  What happens if two completely unrelated APIs queue tasks in
different task queues (causing the same problem, but in a way that can't be
worked around within any one spec)?

This feature is dangerously weakly defined.  It should be removed from the
spec until it can be defined properly (or at least marked "not ready for
implementations"), or we may end up with interop failures that could be
hard to fix later.

Again, I'm pretty sure the sanest way to approach this feature is for any
API supporting it to grab a reference to the underlying resource, and
revoke the URL, as soon as the string enters that API (eg. xhr.open() is
called, or img.src is assigned).  That ensures it's always
deterministically--and synchronously--clear who will actually successfully
receive the object, regardless of later complications like separate task
queues across APIs.  It doesn't answer all questions (eg. the issues
mentioned at
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1265.html),
and the actual "dereferencing" action would need to be specified for every
supported API (this would need work to make it easy to do), but it's a lot
closer than what's in there now.

-- 
Glenn Maynard