W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Interoperability for DAV:ishidden?

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>
Message-ID: <JIEGINCHMLABHJBIGKBCCEMGFEAA.julian.reschke@gmx.de>

> 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.


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.

- 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*

If we really need a reverse-lookup (from resource id to valid HTTP URL), I'd
make that a REPORT.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 6 September 2002 04:36:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC