W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2010

Binding Extensions to Web Distributed Authoring and Versioning

From: Andrew McMillan <andrew@morphoss.com>
Date: Fri, 19 Mar 2010 21:05:12 +1300
To: WebDAV <w3c-dist-auth@w3.org>
Message-ID: <1268985912.21087.3746.camel@happy.home.mcmillan.net.nz>

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

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.

					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

Received on Friday, 19 March 2010 08:05:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:44 UTC