On 29.06.2010 20:40, Arun Ranganathan wrote:
...
I may sound like a broken record, but it's still not clear to me why
you need a custom URI scheme here. If you plan to actually register it
with IANA (you do, right?), you will have to explain why it's needed.
Both you and I may sound like broken records, since we've definitely
been down this road before :)
I know :-)
I do plan to register it via IANA.
Note that we started off with a URN scheme (urn:uuid). This was chosen
initially to bypass a cycle with IANA, but this wasn't adequate. No
browser implementation really uses URN schemes; they aren't used in web
pages; implementers, including Firefox, cited a preference for URLs with
A URN is a URI. blob is a would-be URI as well. No web page uses "blob"
right now, so I'm not sure what point you're trying to make.
a scheme (for instance, nightly builds of Firefox use moz-filedata: as a
scheme). Moreover, we wanted something that could be used in all places
on the web platform that URLs are used today, including Web APIs like
XMLHttpRequest, and for elements (like <img src..>). Lastly, while a URN
scheme could have been used with an attribute called URL, that seemed
wrong.
I don't see why you can't do these things with urn:uuid:.
We have file URIs ("file://") on the web platform today, and some
implementations actually support use such as that mentioned above. But a
scheme that referred to individual Blobs or Files that could be used
with response codes was the best course of action (with no path, etc.).
All true & understood; but I still don't see why this needs a new URI
scheme.
...
- How do you guarantee uniqueness if opaqueString is free form? Is
this just "unique per producer"? Are you sure that never ever two blob
URIs from different producers will get into the same context? If
you're sure about that, why do you need a URI scheme in the first place?
It is likely to be unique per producer. In fact, Chrome folks may wish
to use origin tokens in the URI scheme, and even if they didn't, the use
of UUID would result in differences per producer. If by different
producers, you mean that a Blob URI coined by Chrome may have no meaning
in Firefox, you're likely to be right.
So if a blob URI produced by Firefox leaks into Chrome, what happens? If
this *can* happen, you may need to require more than per-producer
uniqueness.
While the *format* that the URI takes may vary per producer, it seems
wise to at least define a scheme that can be used commonly by user
agents. Authors may never interact with the URI itself, but only with
the Blob.url property -- that is true. But at least a scheme gets us
something that's better than total arbitrariness. Do you disagree
strongly? I also think that leaving things undefined isn't desirable in
general.
I actually do not see what benefit this scheme brings.
- You don't need to make statements about fragment identifiers; they
are not part of the URI scheme itself
That's right. I want to emphasize that they are allowed. I took this
from the RFC on WWW URIs, cited in the text. Maybe I can add a
non-normative section on the use of fragment identifiers? Is that your
suggestion?
The semantics of fragment identifiers follow from RFC 3986, Section 3.5
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>) and
the media type that is being retrieved. So normative statements would be
incorrect, but explaining what's going on wouldn't hurt.
- That being said, if you do you should point out how they work (do
they depend on the media type of a representation?)
Right -- I do in the spec. They depend entirely on the media type of a
Blob. Is the existing text insufficient?
I didn't see it. Most is accurate. I'd rephrase
"This scheme can allow for fragment identifiers for well-defined format
types...."
though. The scheme can't allow or disallow anything; it really only
depends on the media types of the representations you get upon deref.
> ...
Best regards, Julian
