Re: [Uri-review] Discussion of Blob URI Scheme for Binary Data Access | IETF

[Mykyta Yevstifeyev <[e-mail]>]

Arun,

I think you should send the request for reviews on [e-mail] 
list.  I'm cc'ing this message there.

Several comments.  As a global editorial.  You use the *scheme:* 
notation, whereas the *'scheme'* or *scheme* notation is technically 
clearer.  See RFC Erratum Report 2756 
(http://www.rfc-editor.org/errata_search.php?rfc=6196&eid=2756).

Section 6.7.3:

> |blob = scheme ":" opaqueString [fragIdentifier]|

RFC 3986 specified that particular schemes' syntax should not define 
fragment IDs (also see below).

Section 6.7.3.1:

> |hexDigit =
>           "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
>           "a" / "b" / "c" / "d" / "e" / "f" /
>           "A" / "B" / "C" / "D" / "E" / "F"|

This could be imported from RFC 5234 <HEXDIG> 
(http://tools.ietf.org/html/rfc5234#appendix-B.1).

Ibid:

> UUID is one potential option available to user agents for use with 
> Blob URIs as opaque strings, and their use is strongly encouraged.

What is the generic syntax for opaqueString, except one defined for 
UUIDs?  I suppose it is RFC 3986 <path-rootless> here, but considering 
36 chars min. you may define

> |opaqueString = 36*pchar|

where <pchar> are defined in RFC 3986.  I see there are some limitations 
on allowed char range, so you may reflect this is the ABNF as well.

Section 6.7.4 isn't necessary.  You MUST NOT describe fragment ID in the 
scheme's syntax, neither must you define it semantics.

You should be clear about the scheme's semantics, what does a particular 
'blob' URI refer to and how it should be resolved.  Section 6.7.7 may 
lead one to the conclusion that 'blob' URIs are connected with HTTP, but 
I think clarifying this issue won't be unnecessary.

I see your document lacks IANA considerations, which would request 
scheme's registration with IANA, as required by RFC 4395.

Thanks,
Mykyta Yevstifeyev

11.08.2011 1:20, Arun Ranganathan wrote:
> Greetings URI Listserv,
>
> Firstly, sincere apologies for the delay between responses about the 
> matter of the File API and the Blob URI scheme.
>
> Secondly, many thanks for all the advice you've sent my way -- it's 
> been *extremely* useful.  I have updated the File API Editor's Draft:
>
> http://dev.w3.org/2006/webapi/FileAPI/#url
>
> and have informed my edits based on actionable feedback by Joseph A. 
> P. Holsten [1], Julian Reschke (e.g. see email #[2], amongst others), 
> and Graham Klyne (both in email# [3] and off list).  My goal is to 
> respond to concerns raised on this list before moving towards W3C's CR 
> phase; where feasible, I've responded to your feedback with additional 
> details, notably justification of choices made as well as some more 
> formalism in the definition of things.
>
> Thanks again,
>
> -- A*
>
> [1] http://lists.w3.org/Archives/Public/uri/2011May/0012.html
> [2] http://lists.w3.org/Archives/Public/uri/2011May/0011.html
> [3] http://lists.w3.org/Archives/Public/uri/2011May/0006.html
>
>