RE: Proposal: BIND method

Nice description, Jim!

If we do go this route, my preference would be to *replace* direct
references with bindings.  Otherwise, we are getting to have too many
flavors of reference-like things, and becoming too complicated.  In
addition, one of the motivations for thinking about bindings is that they
give straightforward answers to some of the sticky issues we face about
direct references -- the default behavior of COPY and LOCK, etc.  If we have
bindings in addition to direct references, we still have to answer the
sticky questions for direct references.

Now, should we replace direct references with bindings? I've just been
reviewing the referencing requirements and thinking about some document
management systems that I know and their needs.  My own opinion is that we
can live with the constraints that bindings impose, as long as we have
redirect references as well.  What do others think? Let me point out where
there seem to be gaps:

It would not be possible to store properties on bindings.  There is a
requirement to be able to store properties on references.  DMA supports
this.  How important do people think this requirement is?

The distinction between strong and weak references could not be made for
bindings.  We could not allow clients to choose whether referential
integrity is to be enforced for a binding.  The server MUST fix up all
bindings affected by a MOVE or DELETE operation.  It would not be possible
to bind to a nonexistent resource or to keep a binding when a resource
temporarily disappears.  On the one hand this saves us as designers a lot of
headaches; on the other it violates the requirement that it be possible when
creating a reference to specify that the server is *not* to enforce
referential integrity for that reference.  (It would still be possible to
use redirect references if you want that sort of choice.)

Presumably it would not be possible to create a binding to a resource on a
different server.  (You would have to use a redirect reference if you wanted
to go off-server.)

Observation: I believe that an UNBIND method is essential.  The whole point
of referencing is to allow resources to be shared, and that means that it
must at least be possible to stop sharing without destroying the resource
for everybody else who is sharing it.  If we have UNBIND, we need to specify
its interaction with LOCK.  Presumably we at least want to prevent an UNBIND
on the URL that was used to create the LOCK, but it might be easier (since
it's the resource that's locked) to prevent any UNBINDs to a resource while
the resource is locked.

Judith A. Slein
XR&T/Xerox Architecture Center
jslein@crt.xerox.com
8*222-5169


> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Tuesday, April 06, 1999 8:17 PM
> To: WEBDAV WG
> Subject: Proposal: BIND method
> 
> 
> Within the author's group for Advanced Collections, we've 
> been exploring the
> idea of creating a mechanism for adding new URL to resource bindings,
> possibly in addition to Direct References, perhaps to replace Direct
> References.
> 
> Since the goal of a Direct Reference is to create a new 
> location in the HTTP
> namespace which can be used to access the reference's target 
> resource, the
> basic idea behind the mapping concept is to have a mechanism 
> for creating a
> new URL for a resource which acts, in every possible way, 
> just like any
> existing URL does for any existing resource.
> 
> This would remove some of the limitations of Direct 
> References which result
> from a Direct Reference creating a resource for the direct 
> reference, in
> addition to the resource which is the target of the 
> reference.  This extra
> resource creates problems for methods which have a source and 
> a destination
> like COPY and MOVE -- which resource do they apply to by default, the
> reference or the target?  The two resources also create 
> problems for LOCK --
> lock really needs to lock both to preserve RFC 2518 semantics.
> 
> Current best understanding of how a URL relates to a resource 
> is given in
> RFC 2396 (http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt).
> 
> I like to visualize the relationships between URI, resources, 
> and underlying
> chunks of state with the followng diagram:
> 
> 
>     uri1    uri2     uri3
>       \       |        |
>        \      |        |
>         \     |        |
>          \    |        |
>         +-------------------+
>         |   resource R      |
>         +-------------------+
>                   |
>                   |
>                   |
>         +---------------------+
>         | chunk of state      |
>         | (e.g., a file,      |
>         |  or multiple files, |
>         |  or a EEPROM memory |
>         |  or database record |
>         |  or DMS object, ...)|
>         +---------------------+
> 
> That is, there is a mapping of one or more URIs to a 
> resource, which is an
> abstraction maintained by a server which models a chunk of 
> state.  Note that
> the same chunk of state can be mapped to more than one 
> resource (and each
> resource can be mapped to several URI).
> 
> In a nutshell, the proposed BIND method would take two URIs 
> as input.  The
> first one will be the new URI through which the resource will 
> be accessible
> once the operation has completed.  The other URI will be an 
> existing URI by
> which the resource is accessible.  When the server performs 
> the operation,
> it performs a lookup on uri3, finds the resource to which it has been
> mapped, and then creates a new mapping of uri4 to that resource.
> 
> So, a bind operation with uri4 (new URI) and uri3 (existing 
> URI) as inputs
> on the resource in the previous diagram, would produce the following:
> 
> 
>     uri1    uri2     uri3     uri4
>       \       |        |       /
>        \      |        |      /
>         \     |        |     /
>          \    |        |    /
>         +-------------------+
>         |   resource R      |
>         +-------------------+
>                   |
>                   |
>                   |
>         +---------------------+
>         | chunk of state      |
>         | (e.g., a file,      |
>         |  or multiple files, |
>         |  or a EEPROM memory |
>         |  or database record |
>         |  etc.)              |
>         +---------------------+
> 
> That is, after the operation, a GET on uri4 will produce the 
> same response
> as a GET on uri3, uri2, or uri1.  No new resource is created. 
>  The chunk of
> state has not been modified.
> 
> To preserve namespace consistency, the proposed BIND method 
> would have some
> side effects.  Creating a binding would have the side effect 
> of adding the
> new URI into its parent collection (take the new URI, whack 
> off the last
> path segment, then resolve this URI to a collection and add 
> the new URI to
> this collection.)  If the parent collection doesn't exist, 
> BIND would fail.
> 
> BIND can create a binding to a collection resource.  The new 
> collection
> would behave exactly as would a current DAV collection.  This 
> could create
> loops, and servers would need to check for these during 
> "Depth: infinity"
> operations.
> 
> In the example above (a new URI, uri4 has been bound to 
> resource R), the
> effect of methods on the new URI is exactly the behavior 
> these methods would
> have if this binding had been created by another HTTP method, 
> such as PUT
> (which creates the resource, and also creates a binding from 
> a URI to the
> resource).
> 
> GET uri4: return an entity response for R
> 
> HEAD uri4: return the protocol metadata for the GET entity 
> response for R
> 
> PUT uri4: if overwrite active, overwrites R, affecting the GET entity
> response for uri1, uri2, and uri3
> 
> POST uri4: this method can do anything
> 
> OPTIONS uri4: return the same as OPTIONS on uri1, uri2, or uri3
> 
> DELETE uri4: my read of RFC 2068 is it deletes R, and removes 
> the bindings
> for uri1, uri2, uri3, and uri4  (we might want to introduce an UNBIND
> operation which only removes the binding)
> 
> COPY uri4, uriX: duplicate R in new resource T, then create a 
> mapping of
> uriX to T.  Mappings of uri1, uri2, uri3, and uri4 are unaffected.
> 
> MOVE uri4, uriX: duplicate R in new resource T, then create a 
> mapping of
> uriX to T.  Perform fix-up stage, which is currently 
> under-specified in RFC
> 2518, but which in this case would mean re-mapping uri1, 
> uri2, and uri3 to
> T.  One of the things that would be required by introducing BIND is to
> specify well this "fix-up" stage.
> 
> LOCK uri4:  Resource R is locked, and the lock is visible via 
> uri1, uri2,
> and uri3.
> 
> UNLOCK uri4: remove the lock from R, and the lock is no 
> longer visible via
> uri1, uri2, and uri3.
> 
> PROPFIND uri4: retrieve properties on R
> 
> PROPPATCH uri4: set or delete properties on R
> 
> MKCOL uri4: fails, since there is already a resource bound to 
> uri4.  But, if
> no resource were bound to uri4, it would create a collection 
> resource, and
> bind it to uri4.
> 
> - Jim
> 
> 
>

Received on Wednesday, 7 April 1999 11:12:56 UTC