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

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.

That being said, nits below:

- it's a URI scheme, not a URL scheme

- you want to use RFC 5234, not 2234 for ABNF (that just changes the 

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

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

- You don't need to make statements about fragment identifiers; they are 
not part of the URI scheme itself

- That being said, if you do you should point out how they work (do they 
depend on the media type of a representation?)

I recommend to do another round of edits on this, and then include the 
URI review mailing list into further discussions.

Best regards, Julian

Received on Tuesday, 29 June 2010 18:10:14 UTC