Re: Discussion of Blob URI Scheme for Binary Data Access | IETF

At a quick glance, this proposal seems to be potentially problematic.  The idea
of a URI scheme to access a particular kind of data seems to be questionable
(i.e. at odds with the principles of web architecture).  My initial sense is
that the problem you are addressing should be addressed through content
labelling, not a new URI scheme.

Before asking others to expend time and effort to study what you propose, can
you please explain (or point to an explanation of) what this scheme achieves
that cannot already be achieved using HTTP or other URI schemes?  (You have
partially explained below why file: isn't suitable, but it's not clear from that
what problem/requirement is not addressed by other schemes.)

#g
--

Arun Ranganathan wrote:
> Greetings URI listserv!
> 
> I'm writing to this listserv at the behest of Mark Nottingham, who sent 
> me here from the ietf-http-wg <at> w3.org listserv. This email is about a 
> "new" URI scheme used to access binary data, and we'd like feedback on 
> it, as well as advice on whether any further standardization endeavors 
> are necessary.
> 
> My name is Arun Ranganathan, and I'm the current editor of the File API 
> [1] specification (sometimes called the HTML5 File API, which is 
> unfortunate); I'm also the former Chair of the WebGL Working Group [2] 
> (which brings hardware-accelerated 3D graphics to the web), and have a 
> continued interest in allowing binary data to be securely accessed and 
> manipulated on the web.  I'm sponsored by Mozilla.

Fwd: Last Call for HTML5 in the W3C

Hello all,

17.06.2011 23:46, Mark Nottingham wrote:
> [ with my IETF/W3C Liaison hat on ]
>
> The W3C has announced a Last Call on the HTML5 specification; see:
>   http://www.w3.org/2011/02/htmlwg-pr.html
>
> The IETF has been encouraged to provide feedback, especially regarding HTML's use of and interface with
IETF technologies.
>
> For background on Last Call in their process, see:
>   http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>
> and the specification itself:
>   http://www.w3.org/TR/html5/
> paying special attention to the 'status of this document' section for information about the Last Call and
how to provide feedback.
>
> See also their LC FAQ:
>   http://www.w3.org/2011/05/html5lc-faq.html
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
This document, especially Section 2.6 and some other URI-related stuff, 
may be interesting for people on this list.  Please provide your 
comments to apps-discuss list, preferably copied to Mark Nottingham, who 

Definition of blob URI Scheme

Hi Mark,

I'd like to check with you my understanding of RFC 4395 [1].

The FIle API specification contains the definition of the blob URI
scheme [2]. Following the registration procedure, my understanding is
that:
1- Arun should reformat section 6.7.1 [2] (or include a new section) to
follow the template at [3];
2- Once our specification is in LC, Arun should send an email to
uri-review <at> ietf.org asking for review (and address whatever comments
come out of that);
3- At CR, Arun should request registration from IANA (iana <at> iana.org),
asking for provisional status;
4- At PR (or REC?), Arun should request permanent status from IANA.

Do you concur with those steps?

Philippe

[1] http://tools.ietf.org/html/rfc4395#page-9
[2] http://dev.w3.org/2006/webapi/FileAPI/#ABNFForBlob
[3] http://tools.ietf.org/html/rfc4395#section-5.4

Re: Definition of blob URI Scheme

Re: Definition of blob URI Scheme

Hi Philippe.

On 22/06/2011, at 5:01 AM, Philippe Le Hegaret wrote:

> Hi Mark,
> 
> I'd like to check with you my understanding of RFC 4395 [1].
> 
> The FIle API specification contains the definition of the blob URI
> scheme [2]. Following the registration procedure, my understanding is
> that:
> 1- Arun should reformat section 6.7.1 [2] (or include a new section) to
> follow the template at [3];

FWIW I'd put the template in an appendix.

> 2- Once our specification is in LC, Arun should send an email to
> uri-review <at> ietf.org asking for review (and address whatever comments
> come out of that);

What status are you going for -- permanent or provisional?

> 3- At CR, Arun should request registration from IANA (iana <at> iana.org),
> asking for provisional status;
> 4- At PR (or REC?), Arun should request permanent status from IANA.

I'll check into this.

Cheers,

> 
> Do you concur with those steps?
> 
> Philippe
> 
> [1] http://tools.ietf.org/html/rfc4395#page-9
> [2] http://dev.w3.org/2006/webapi/FileAPI/#ABNFForBlob
> [3] http://tools.ietf.org/html/rfc4395#section-5.4
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Re: Definition of blob URI Scheme

Philippe -

I discussed this with the expert for URI scheme registration. 

Re (1) - It's common practice in the IETF to place the registration template in the document, but this isn't
strictly required; you could just submit the template separate, in the request to IANA.

Re (2) - it isn't necessary to wait until LC to get review on the list.

Re (3) - It's possible to request provision registration as soon as the URI-review feedback has been dealt
with -- no need to wait for CR.

Cheers,

On 22/06/2011, at 5:01 AM, Philippe Le Hegaret wrote:

> Hi Mark,
> 
> I'd like to check with you my understanding of RFC 4395 [1].
> 
> The FIle API specification contains the definition of the blob URI
> scheme [2]. Following the registration procedure, my understanding is
> that:
> 1- Arun should reformat section 6.7.1 [2] (or include a new section) to
> follow the template at [3];
> 2- Once our specification is in LC, Arun should send an email to
> uri-review <at> ietf.org asking for review (and address whatever comments
> come out of that);
> 3- At CR, Arun should request registration from IANA (iana <at> iana.org),
> asking for provisional status;
> 4- At PR (or REC?), Arun should request permanent status from IANA.
> 
> Do you concur with those steps?
> 
> Philippe
> 
> [1] http://tools.ietf.org/html/rfc4395#page-9
> [2] http://dev.w3.org/2006/webapi/FileAPI/#ABNFForBlob
> [3] http://tools.ietf.org/html/rfc4395#section-5.4
> 
> 

--
Mark Nottingham   http://www.mnot.net/