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

Re: Interoperability for DAV:ishidden?

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Thu, 5 Sep 2002 11:12:28 -0700
Message-ID: <003901c25507$cbf4df30$9b114498@esedlar>
To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>

> > One property that keeps coming up (also in the Microsoft proposal) is
> > resource-ID property, to uniquely identify a resource (generally a
> > I'm constantly getting requests from internal groups for this,
> > and I know a
> > lot of the JSR-170 people are interested in this for content management
> > apps.
> As Geoff pointed out, this will be available as part of the BIND spec. It
> could be used on systems even when they don't specifically support the
> method.
> > Of course another related requirement is the ability to fetch resources
> > ID.  This could be done either by fully utilizing the DAV: namespace,
> > DAV:<resourceID> as the URL or by waiting for DASL.
> First of all, the "unique resource ID" just is a URI. Which URI scheme is
> used is up to the server. So it's completely free to assign an HTTP URI,
> this obviously could then be used to fetch the ressource. If the
> isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.
> Re: locating a WebDAV ressource by resourceid -- this won't work with the
> current DASL spec (at least not with the DAV:basicsearch grammar), as I
> expect the property to have DAV:href content -- something in which you
> search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> appropriate...

What is needed is an interoperable way, given a resource ID, to operate on a
resource with that ID on the server.  If the mapping between resource-ID and
implementation is server-defined, we can't do that.  Requiring the DAV:
namespace to respond to these requests is probably the easiest thing to do,
since this will work with other methods, like LOCK and so forth.  REPORT
doesn't handle that case.

Received on Thursday, 5 September 2002 14:22:03 UTC

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