Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <OF548CC95D.9FC9E21F-ON852574AA.00469D23-852574AA.0047D79B@us.ibm.com>
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




Werner Donné <[email protected]> wrote on 08/19/2008 04:23:18 AM:

> 
> > 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).
> 
> 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.
> --
> Werner Donné  --  Re                                     http://www.
> pincette.biz
> Engelbeekstraat 8 
> http://www.re.be
> BE-3300 Tienen
> tel: (+32) 486 425803   e-mail: [email protected]
> 
> 
> 
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.