Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <OF37CC663A.58EE5659-ON852574A7.0064C086-852574A7.0064E0E9@us.ibm.com>
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

Julian Reschke <[email protected]> wrote on 08/16/2008 06:31:45 AM:

> Julian Reschke wrote:
> > 
> > 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."
> > ...
> 
> 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
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.