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

On 2011-05-16 19:04, Arun Ranganathan wrote:
> ...
>> - You *could* define HTTP semantics for file:, so that doesn't seem a
>> compelling reason not to use it. Actually, browsers do so in XHR
>> already, no?
>>
>
> Not really :) Defining HTTP semantics for the file URI scheme would be a
> late-breaking change to a scheme that's already well understood (and
> dusty with age). Also, an important distinction here is that the file://
> URI is best used for the underlying file system, and can more or less
> identify directories, files, and resources that have *at least* a
> semi-permanent structure in that they are stored on disk. But Blob
> resources are typically short lived, and identify a binary resource *in
> memory* for the lifetime of the Document (or sooner!). Moreover, a Blob
> resource may at times *only* live in memory, and may not stem from a
> file resource (which could be identified with the "file://" URI scheme).
> Consider the use of the BlobBuilder API [1], or even the Blob.slice API
> [2].
> ...

Understood; but most of the things you just mentioned have nothing to do 
with the "HTTP semantics" part.

> ...
>> "blob = scheme ":" opaqueString [fragIdentifier]"
>>
>> The fragment identifier should not be part of the scheme definition.
>>
>
> OK -- I think your suggestion is to maybe have a separate section that
> discusses fragments? Is that really necessary? Is that a convention or a
> stylistic preference? Since fragments are optional, I've only included
> them for completeness. What do I gain by a separate section that
> discusses fragments?

I'd recommend not to mention them in the scheme definition and the ABNF. 
As you correctly note elsewhere, their syntax is defined by RFC 3986, 
and their semantics by the media type.


>> "; opaqueString could be a UUID in its canonical form
>> ; opaqueString tokens MUST be unique"
>>
>> Unique or globally unique? If the latter, how can you be sure without
>> mandating a specific format?
>
> Globally unique -- and I've already made a change suggesting this in the
> specification. Implementers pushed back on UUID as an explicit choice,
> strongly urging merely a note that suggests UUID usage.
>
> Left to me, I'd like to mandate UUID :) But I want this specification to
> be widely adopted, and if implementers have nits about mandating UUID,
> I'll challenge them to come up with something UUID-like in characteristics.

The issue is that unless you mandate a specific syntax, there's no way 
to guarantee global uniqueness.

>...

Best regards, Julian

Received on Monday, 16 May 2011 20:20:16 UTC