- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 29 Jun 2010 20:09:34 +0200
- To: arun@mozilla.com
- CC: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
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 reference) - "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