W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 27 Oct 2009 15:31:56 -0700
Message-ID: <63df84f0910271531x455f8da3h8ab7ecee84955c68@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Oct 27, 2009 at 3:26 PM, Ian Hickson <ian@hixie.ch> 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.

This doesn't seem to be a problem as long as the two specs don't
mandate the exact same uuids.

But again, I'd like feedback from other implementations with different
network stacks.

/ Jonas
Received on Tuesday, 27 October 2009 22:32:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC