Subject: Relationship between BIND and RFC 3253

From: Werner Donné <[email-masked]>
Date: Mon, 11 Aug 2008 14:00:47 +0200

Hi,

I wonder if the BIND spec could include an informal discussion about
the relationship with RFC 3253. There are two cases I see at the moment
that are worth mentioning.

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

2) RFC 3253 proposes the version-history feature. It can provide access
  to the version history of a resource, "even after all version- 
controlled
  resources for that version history have been deleted". In terms of the
  binding model this means "when all bindings to it in any collection
  version have been deleted". RFC 3253 doesn't propose a way to  
reinstate
  a version history in the URI namespace of a server. With the BIND  
method
  there is a possibility by using a resource-id as the value of the href
  element. In practice, this is a way for an end-user to recover an
  accidentally deleted version-controlled resource.

Best regards,

Werner.
--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 12 Aug 2008 01:11:52 -0400

Point 1 is correct. 

But wrt point 2, RFC3243 does provide a way to reinstate a version 
history, by specifying a Version in the body of a VERSION-CONTROL request. 
 Also note that a BIND request would not provide a way to reinstate a 
version history, because reinstating a version history is done by creating 
a new version-controlled resource whose VERSION-HISTORY property 
identifies that version history (and this cannot be done via a BIND 
operation).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 16 Aug 2008 11:29:32 +0200

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 16 Aug 2008 12:31:45 +0200

Julian Reschke wrote:
> ...

Hm.

It just occurred to me that a server that implements MOVE as a sequence 
of COPY and DELETE would expose a different behavior -- checking in the 
destination collection but reverting the source collection would turn 
the operation into the equivalent of a COPY, not a BIND...

BR, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 16 Aug 2008 14:21:51 -0400

The "Hm" note is correct.  A MOVE will create an additional binding if the 
MOVE has REBIND semantics, but not if the MOVE has COPY/DELETE semantics.

Cheers,
Geoff

---

From: Werner Donné <[email-masked]>
Date: Tue, 19 Aug 2008 10:23:18 +0200

> history, by specifying a Version in the body of a VERSION-CONTROL  
> request.  Also note that a BIND request would not provide a way to  
> reinstate a version history, because reinstating a version history  
> is done by creating a new version-controlled resource whose VERSION- 
> HISTORY property identifies that version history (and this cannot be  
> done via a BIND operation).

In RFC 3253 I find in section 14.8 that you can indeed reinstate the  
version
history of a collection in this way, but I can't find anything like  
that for
resources that are not collections.

I see no evidence for the statement that a new version-controlled  
resource
should be created for reinstating a version history. This seems to be  
what
happens when the VERSION-CONTROL method is used, but that is not the  
same
thing.

The usage of BIND I propose is semantically equivalent to an addition to
the version-controlled-binding-set property of the parent collection  
of the
request URI.

Werner.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 19 Aug 2008 09:04:42 -0400

The semantics that let you use VERSION-CONTROL to "restore" any resource 
from its version-history are defined in section 6.7.
Section 14.8 is just the extended semantics of VERSION-CONTROL when 
restoring version-controlled-collections.

You cannot use BIND to "restore" a version history, because the child of a 
version-controlled-folder is a version-controlled-resource, not a 
version-history, whereas BIND is defined to make the specified resource a 
child of the specified collection.

Cheers,
Geoff

---

From: Werner Donné <[email-masked]>
Date: Tue, 19 Aug 2008 15:17:09 +0200

> The semantics that let you use VERSION-CONTROL to "restore" any  
> resource from its version-history are defined in section 6.7.

This is part of the workspace feature, which is optional. Shouldn't  
this be
part of the general VERSION-CONTROL semantics? I don't think you need  
the
workspace feature for this behaviour.

> You cannot use BIND to "restore" a version history, because the  
> child of a version-controlled-folder is a version-controlled- 
> resource, not a version-history, whereas BIND is defined to make the  
> specified resource a child of the specified collection.
>

I have not suggested that the version history become the child of a
version-controlled folder. The request URI of the BIND would be the  
child
and from the resource-id the version history would be inferred.

Werner.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 20 Aug 2008 18:35:35 -0400

Werner Donné <[email-masked]> wrote on 08/19/2008 09:17:09 AM:

> the workspace feature for this behaviour.

The partitioning of functions into a few "features" always has arbitrary
aspects, so the current spec just captured the rough consensus of the
design group.  A particular server is always free to implement parts of a
feature if the functionality it wants to provide does not allign exactly
with the feature partitioning of the spec.  We can define new "feature
groupings", but we should not define alternative syntax/mechanisms for
functions that are already defined in the specification.

> and from the resource-id the version history would be inferred.

I don't believe that is compatible with the current semantics defined for
BIND (I'd need to see an example of what you have in mind to comment more
precisely).  But more importantly, since that functionality is already
provided by RFC-3253 with the VERSION-CONTROL method, there's no reason to
provide an alternative mechanism via the BIND method.

Cheers,
Geoff

---

From: Werner Donné <[email-masked]>
Date: Thu, 28 Aug 2008 10:41:36 +0200

I don't understand how COPY/DELETE semantics for the MOVE could apply
to a version controlled resource. It would destroy the version history.
It may be a valid implementation, but not a very useful one.

Regards,

Werner.

On 16 Aug 2008, at 20:21, Geoffrey M Clemm wrote:

>
> The "Hm" note is correct.  A MOVE will create an additional binding  
> if the MOVE has REBIND semantics, but not if the MOVE has COPY/ 
> DELETE semantics.
>
> Cheers,
> Geoff
>
> For

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 28 Aug 2008 09:38:25 -0400

I change my response to agree with Werner.
RFC 3253 explicitly requires that the versioning metadata have a MOVE 
"move" semantics, not "copy/delete" semantics (section 3.15), so the "Hm" 
note does not apply.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Aug 2008 15:51:51 +0200

Geoffrey M Clemm wrote:
> "move" semantics, not "copy/delete" semantics (section 3.15), so the 
> "Hm" note does not apply.
> 
> Cheers,
> Geoff

I agree as well.

So, should I spend some energy into integrating the proposal in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0039.html> 
into the current version of the draft?

BR, Julian