Re: Relationship between BIND and RFC 3253

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

Werner wrote on 08/11/2008 08:00:47 AM:
> 
> 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.