Re: [FileAPI] Latest Revision of Editor's Draft

Ian Hickson wrote:
> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>   
>> On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <ian@hixie.ch> wrote:
>>     
>>> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>>>       
>>>> All we're saying is that urn:uuid represents a specific chunk of data
>>>> with a specific mimetype. This seems like something that's already there
>>>> with urn:uuid.
>>>>         
>>> We're also saying that urn:uuid: has special semantics in the same-origin
>>> model, and that it has an expiration model.
>>>       
>> The expiration model is just that when the Document goes away the
>> urn:uuid is changed to no longer represent that chunk of data.
>>
>> The origin is something that at least in gecko we build on top of the 
>> URI, i.e. the URI itself doesn't contain any origin information. If you 
>> consider it to be part of the URI, then why wouldn't each urn:uuids 
>> already have an origin?
>>     
>
> I just mean that if someone else decides that they are going to resolve 
> urn:uuid:s in some way or other, the origin model they would use will 
> almost certainly be quite different to the origin model we are using here.
>   

Yes; that is true, and is a concern.  However, my reading of: 
http://www.ietf.org/rfc/rfc4122 (which describes urn:uuid) suggest that 
namespace resolution for UUIDs, coupled with general stipulations for 
namespace resolution, make this a manageable problem. 

 From RFC4122, Section 3:

"   Process for identifier resolution:      Since UUIDs are not globally 
resolvable, this is not applicable."

Moreover, in http://www.ietf.org/rfc/rfc2141.txt (which describes URN 
syntax), we find that:

"... Namespace registration must include guidance on how to determine 
functional equivalence for that namespace, i.e. when two URNs are 
identical within a namespace."

We're unlikely to have *identical URNs* in the uuid namespace.  One 
reason I chose UUID is because the "identical URN" problem is unlikely.

That leaves the problem of persistence (which is also a stipulation on 
URNs) but I think that we are entitled to define persistence in terms of 
the Document's persistence.

I'd like to hear from implementors, and of course those that disagree 
with my reading of these specifications.  I'm amenable to dropping the 
HTTP responses if that helps.

-- A*

Received on Tuesday, 27 October 2009 22:52:37 UTC