Re: Relationship between BIND and RFC 3253

Werner Donné <werner.donne@re.be> wrote on 08/19/2008 09:17:09 AM:

> > The semantics that let you use VERSION-CONTROL to "restore" any
> > resource from its version-history are defined in section 6.7.
>
> This is part of the workspace feature, which is optional. Shouldn't
> this be
> part of the general VERSION-CONTROL semantics? I don't think you need
> the workspace feature for this behaviour.

The partitioning of functions into a few "features" always has arbitrary
aspects, so the current spec just captured the rough consensus of the
design group.  A particular server is always free to implement parts of a
feature if the functionality it wants to provide does not allign exactly
with the feature partitioning of the spec.  We can define new "feature
groupings", but we should not define alternative syntax/mechanisms for
functions that are already defined in the specification.

> > Section 14.8 is just the extended semantics of VERSION-CONTROL when
> > restoring version-controlled-collections.
> >
> > You cannot use BIND to "restore" a version history, because the
> > child of a version-controlled-folder is a version-controlled-
> > resource, not a version-history, whereas BIND is defined to make the
> > specified resource a child of the specified collection.
> >
>
> I have not suggested that the version history become the child of a
> version-controlled folder. The request URI of the BIND would be the
> child
> and from the resource-id the version history would be inferred.

I don't believe that is compatible with the current semantics defined for
BIND (I'd need to see an example of what you have in mind to comment more
precisely).  But more importantly, since that functionality is already
provided by RFC-3253 with the VERSION-CONTROL method, there's no reason to
provide an alternative mechanism via the BIND method.

Cheers,
Geoff

Received on Thursday, 21 August 2008 02:56:23 UTC