Re: [File API] Recent Updates To Specification + Co-Editor

On 6/29/10 11:09 AM, Julian Reschke wrote:
> Hi Arun,
>
> On 28.06.2010 23:20, Arun Ranganathan wrote:
>> ...
>> 2. I've updated the URL scheme for Blobs using an ABNF that calls for an
>> "opaque string" which is a term I define in the specification. There was
>> much discussion about this aspect of the File API specification, and I
>> think the existing scheme does allow for user agents to tack on origin
>> information in the URL (this is not something the spec. says you should
>> do). The actual choice of opaque string is left to implementations,
>> though the specification suggests UUID in its canonical form (and
>> provides an ABNF for this). I think this is the most any specification
>> has said on the subject of URLs.
>> ...
>
> 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 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 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.

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.).
>
> That being said, nits below:
>
> - it's a URI scheme, not a URL scheme
>
Duly noted; this is a mistake on my part.
> - you want to use RFC 5234, not 2234 for ABNF (that just changes the 
> reference)
>

Duly noted; I'll fix this.

> - "MAY" use UUIDs doesn't make sense if it's really opaque. I'll 
> assume that opaqueString will allow all characters used in UUIDs, so 
> you really don't need a BCP 14 keyword here. Just state that it might 
> be a good choice.

Hmm... fair enough.

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

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.

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

> - 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 recommend to do another round of edits on this, and then include the 
> URI review mailing list into further discussions.
>

Good suggestion, thanks Julian.

-- A*

Received on Tuesday, 29 June 2010 18:41:23 UTC