W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Bindings and Locks (was: bind draft issues)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 4 Mar 2003 15:55:11 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Brian Korver'" <briank@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEFCGKAA.julian.reschke@gmx.de>

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Tuesday, March 04, 2003 5:09 AM
> To: 'Julian Reschke'; 'Brian Korver'; 'WebDAV'
> Subject: RE: Bindings and Locks (was: bind draft issues)
> > Of course does RFC2518 have a notion of bindings. What it
> > doesn't have is a
> > method to *create* multiple bindings, and the live properties
> > to inspect
> > them.
> >
> > Bindings always have been there implicitly. All the BIND spec
> > adds is the
> > machinery to create them, and to discover some more
> > information about them.
> >
> You can say that RFC2518 supports bindings, but only if you cover one

RFC2518 extends HTTP, and HTTP allows multiple URLs to be mapped to the same

> eye when you look at it.  RFC2518 contains definitions for operations
> that apply to resources and operations that apply to URLs.  RFC2518 is
> in fact very ambiguous on this kind of thing, without a fixed model of
> how implementors must represent everything under the covers. A lot of

Well, yes. The RFCs should describe server behaviour, not their internals.

> the text is descriptive.


> For example, the definition of DELETE for a non-collection talks as if
> it applies to a binding:
> "If the DELETE method is issued to a non-collection resource whose URIs
> are an internal member of one or more collections, then during DELETE
> processing a server MUST remove any URI for the resource identified by
> the Request-URI from collections which contain it as a member."
> However, the definition of DELETE for a collection talks as if it
> applies to a set of underlying resources:
> "DELETE instructs that the collection specified in the Request-URI and
> all resources identified by its internal member URIs are to be deleted.
> "
> Locks apply more to URLs than to resources, yet property operations
> apply more to resources than to URLs, and neither locks nor properties
> are 100% pure.

Locks apply both to resources and URLs (as clarified by GULP), and always

Property operations *always* apply to resources, and there really is no
exception to that rule.

> Really, what this means is that implementors of several kinds of systems
> can support RFC2518 simply by supporting a consistent behavior.  For
> example, systems that model URLs as links to underlying resources, as
> well as systems that model URLs as properties of resources. There may be
> other kinds too.

The URL can only be a property of a resource if the system explicitly
restricts itself to only single bindings. You can't have both multiple
bindings, and also treat the URL as a property of the resource at the same


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 09:55:44 UTC

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