- 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>
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 ------------------------------------------------------------------------
Received on Friday, 19 March 2010 08:05:48 UTC