Ian Hickson wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <i...@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*

Reply via email to