- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 8 Oct 2009 10:48:51 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Larry Masinter <masinter@adobe.com>, public-webapps@w3.org, arun@mozilla.com
On Thu, Oct 8, 2009 at 9:53 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Jonas Sicking wrote: >> >> ... >> I think we'd really like to avoid creating a new scheme if we could >> reuse an existing one. I know Arun was looking for an existing scheme, >> but not sure if he looked at the 'urn' scheme. >> >> Would it need to be urn:somename:uuid though? like urn:fileid:uuid? >> ... > > What's wrong with urn:uuid, which is defined in RFC 4122 and already cited? Ah, now I see what you mean. So the URI would be urn:uuid:<uuid> for example urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 The other thing that needs to be ok is that the lifetime of the URI "working", i.e. the time it actually successfully returns the contents of the File, is limited to the lifetime of the Document the File was created in. I guess you could simply view that as the resource behind the urn changing once the Document goes away. >> Also, Anne pointed out that we probably want fragment identifiers to >> work in whatever URI is returned. Would that be possible if we use >> 'urn'? If I'm reading rfc2141 right, it seems to say it's undefined. > > Fragment identifiers are independent of the URI scheme > (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.5>). Excellent. / Jonas
Received on Thursday, 8 October 2009 17:49:43 UTC