- From: Lisa Dusseault <lisa@xythos.com>
- Date: Mon, 3 Mar 2003 20:09:20 -0800
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Brian Korver'" <briank@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> 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 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 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. 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. Lisa
Received on Monday, 3 March 2003 23:09:22 UTC