- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 6 Sep 2002 10:35:31 +0200
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, September 06, 2002 12:53 AM > To: w3c-dist-auth@w3.org > Subject: RE: Interoperability for DAV:ishidden? > > > > I like the idea of having a URI namespace for unique identifiers for > resources. Since we use the DAV: namespace exclusively for protocol Well, that's a property of *all* URIs :-) > elements, I tihnk it's a bad idea to reuse the DAV: URI space for this > purpose. But, a "guid:" URI scheme could be very useful to us, > and to other > working groups too, I imagine. Yes. I think a UUID based URI scheme is what we need, and we should NOT define this in a WebDAV RFC (like it happened for "opaquelocktoken:"). Instead, a separate RFC should be authored, finally defining the URN "uuid" namespace. Note that "urn:uuid:..:" is already in use by published software, yet the URN namespace has *not* been registered (see http://uri.net). > Now, a "guid:" URI is just an identifier, and is not explicitly defined to > be a locator, like a URL. However, we could easily say that each > DAV server > understands how to resolve a subset of the overall GUID space, and if you > somehow know one of the GUIDs a server can resolve, a GET request on that > "guid:" URI will respond with the correct state, etc. I don't understand that. How do you apply an HTTP method to a non HTTP-URL? > Just to make sure we're all on the same page, I'm proposing that > in addition > to the current situation where there can be multiple URLs mapped > to a single > resource: > > URL (n)-->(1) resource > > We would additionally have a 1 to 1 mapping of guid: URI to resource: > > guid: (1)-->(1) resource I'm not sure what this is good for. The binding draft requires a unique URI for each resource that will never change and will never be assigned again. IMHO, - servers should be completely free in choosing a URI scheme for that URI, as long as it has the desired properties - in particular (like Geoff said), a server can choose to generate URIs with these properties inside it's own URL namespace, in which case HTTP methods can be applied to that URI -- but I don't think it makes sense to *require* this If we really need a reverse-lookup (from resource id to valid HTTP URL), I'd make that a REPORT. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 6 September 2002 04:36:05 UTC