Binding Extensions to Web Distributed Authoring and Versioning

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Binding Extensions to Web Distributed Authoring and Versioning

Andrew McMillan-5
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
------------------------------------------------------------------------


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Binding Extensions to Web Distributed Authoring and Versioning

Geoffrey M Clemm

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