Re: Relationship between BIND and RFC 3253

[Julian Reschke <[e-mail]>]

Geoffrey M Clemm wrote:
> 
> Point 1 is correct.  

Indeed.

I think Werner is right in that many do not understand the relation 
between BIND and DeltaV, and thus it would be useful to state it.

We already have a "Relationship to WebDAV Access Control Protocol" 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.9>), 
so my proposal would be to make that a generic "Relationship to other 
WebDAV Specifications", and having one subsection for ACL and DeltaV each.

The DeltaV part could read (this is mainly Werner's text):

"When supporting version controlled collections, bindings may be 
introduced in a server without actually issuing the BIND method. For 
instance, when a MOVE is performed of a resource from one 
version-controlled collection to another, both collections should be 
checked out. An additional binding would be the result if the target 
collection would be subsequently checked in, while the check-out of the 
source collection is undone. The resulting situation is meaningless if 
the binding model is not supported."

Note: I changed 2nd last sentence to state which collection is being 
checked-in (the target) and which would be reverted (the source).

So, if we have /target, /source and /source/test, all of which 
version-controlled, and do:

(1)

   CHECKOUT /source/ HTTP/1.1

(2)

   CHECKOUT /target/ HTTP/1.1

(3)

   MOVE /source/test HTTP/1.1
   Destination: /target/test

(4)

   CHECKIN /target/ HTTP/1.1

(5)

   UNCHECKOUT /source/ HTTP/1.1

we would end up with /source/test and /target/test being bindings to the 
same resource.

If we did

(4b)

   UNCHECKOUT /source/ HTTP/1.1

(5b)

   CHECKIN /target/ HTTP/1.1

We would end up with zero bindings, so the resource would be gone (also 
interesting, but...)

So, call for consensus:

a) Add that section?

b) Is the proposed text and scenario accurate?

c) Include the expanded example with message exchanges?

BR, Julian