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*
