Re: Binding Extensions to Web Distributed Authoring and Versioning

Andrew McMillan wrote on 03/19/2010 04:05:12 AM:
> I've been implementing support for some parts of the binding extensions,
> and have some curiosity about the draft...
> 
> It appears from several readings that the UNBIND and REBIND methods are
> optional.  Furthermore, it seems that DELETE would achieve all that
> UNBIND could, and similarly MOVE would achieve all that REBIND does, and
> that in a correct implementation these are two are not optional.

UNBIND and REBIND have stricter semantics than DELETE and MOVE.  So any 
implementation of UNBIND is a valid implementation of DELETE, but the 
converse is not true ... a valid implementation of DELETE is not 
necessarily a valid implementation of UNBIND (for example, a "best effort" 
deletion of a tree of resources is valid for DELETE, but not for UNBIND). 
The same is true for REBIND and MOVE (for example, MOVE can be implemented 
as a COPY/DELETE sequence, while REBIND cannot).

> So it makes me wonder if it is expected that UNBIND and REBIND methods
> will actually be implemented, and if so, what purpose they serve, over
> and above DELETE / MOVE?

If a client wants the stricter semantics of UNBIND/REBIND, they would need 
to invoke UNBIND/REBIND, since they cannot count on those semantics being 
provided by DELETE/MOVE.

> On the other hand I can't see anything saying that the BIND method MUST
> be implemented either, although obviously it is decidely not the same as
> COPY, and so there is an implied REQUIRED in that case.

I'm not sure what you mean by REQUIRED.  A server can decide to support 
(or not support) whatever method they want.  If they support a particular 
method, then the specification defines what the behavior of that method 
MUST be.

> For my own case I have been implementing this within the context of a
> CalDAV server, and I have some uncertainty regarding which properties
> might apply to a bound instance, and which might apply to the base
> instance.

I'm not sure what you mean by a "bound instance".  Do you must mean a 
resource binding created by the BIND operation?  If so, then it is just 
another URL that can be used to locate the original resource, and 
therefore all properties that are not related to the URL for that resource 
should be the same no matter what URL is used.

> I have assumed, for example, that DAV::displayname is something that is
> per-instance (along with anything else that is unrelated to server
> operation), whereas DAV::resourcetype is not (since I do allow this to
> be modified by PROPPATCH within certain narrow circumstances).

It's not whether or not the property can be modified ... it is whether the 
property value logically depends on the URL used to locate the resource.

> How 'DAV::owner', and perhaps as a consequence things like
> 'DAV::principal-URL', should behave seem somewhat less clear to me,
> although I guess there is an implicit continuation of ownership coming
> from the reference in section 10, so I can assume that anything related
> to ownership or access must be associated with the underlying resource.

Yes.

> In the case of principal-URL, this has unfortunate side-effects in some
> CalDAV clients, where they appear to request this property and then
> wander off requesting calendar-home-set for that principal and get kind
> of lost and confused, so I have had to provide a separate per-bind
> owner, etc., while enforcing the underlying ownership and restrictions
> on the object.  I'll file a bug with that particular client when I can
> work out how it should read :-)

You'll probably need to identify the problem somewhat more precisely.  The 
principal-URL is supposed to be a URL that can be used to locate the 
principal for that resource, which means it would be valid for a client to 
use that URL to obtain information about the principal.

> Other than those minor points, it has been very useful for me to have a
> specification to use, which meets a few specific needs in my case.

Great!

Cheers,
Geoff