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
