Subject: Binding Extensions to Web Distributed Authoring and Versioning

From: Andrew McMillan <[email-masked]>
Date: Fri, 19 Mar 2010 21:05:12 +1300

Hi,

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.

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?

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.

Am I correct that support for the UNBIND and REBIND methods is optional?

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 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).

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.

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 :-)

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.

Thanks,
					Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
       The truth is rarely pure, and never simple. -- Oscar Wilde
------------------------------------------------------------------------

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Mar 2010 08:43:07 -0400

> 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).

> will actually be implemented, and if so, what purpose they serve, over

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.

> 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.

> might apply to a bound instance, and which might apply to the base

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.

> 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.

> to ownership or access must be associated with the underlying resource.

Yes.

> 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.

> specification to use, which meets a few specific needs in my case.

Great!

Cheers,
Geoff