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