Relationship between BIND and RFC 3253

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

Relationship between BIND and RFC 3253

Werner Donné

Hi,

I wonder if the BIND spec could include an informal discussion about
the relationship with RFC 3253. There are two cases I see at the moment
that are worth mentioning.

1) When supporting version controlled collections, bindings may be
  introduced in a server without actually issuing the BIND method.
  When a MOVE is performed of a resource from one collection to
  another, both collections should be checked out. An additional binding
  would be the result if one collection would be subsequently checked  
in,
  while the check-out of the other is undone. The resulting situation
  is meaningless if the binding model is not supported.

2) RFC 3253 proposes the version-history feature. It can provide access
  to the version history of a resource, "even after all version-
controlled
  resources for that version history have been deleted". In terms of the
  binding model this means "when all bindings to it in any collection
  version have been deleted". RFC 3253 doesn't propose a way to  
reinstate
  a version history in the URI namespace of a server. With the BIND  
method
  there is a possibility by using a resource-id as the value of the href
  element. In practice, this is a way for an end-user to recover an
  accidentally deleted version-controlled resource.

Best regards,

Werner.
--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm

Point 1 is correct.  

But wrt point 2, RFC3243 does provide a way to reinstate a version history, by specifying a Version in the body of a VERSION-CONTROL request.  Also note that a BIND request would not provide a way to reinstate a version history, because reinstating a version history is done by creating a new version-controlled resource whose VERSION-HISTORY property identifies that version history (and this cannot be done via a BIND operation).

Cheers,
Geoff

Werner wrote on 08/11/2008 08:00:47 AM:
>
> Hi,
>
> I wonder if the BIND spec could include an informal discussion about
> the relationship with RFC 3253. There are two cases I see at the moment
> that are worth mentioning.
>
> 1) When supporting version controlled collections, bindings may be
>   introduced in a server without actually issuing the BIND method.
>   When a MOVE is performed of a resource from one collection to
>   another, both collections should be checked out. An additional binding
>   would be the result if one collection would be subsequently checked  
> in,
>   while the check-out of the other is undone. The resulting situation
>   is meaningless if the binding model is not supported.
>
> 2) RFC 3253 proposes the version-history feature. It can provide access
>   to the version history of a resource, "even after all version-
> controlled
>   resources for that version history have been deleted". In terms of the
>   binding model this means "when all bindings to it in any collection
>   version have been deleted". RFC 3253 doesn't propose a way to  
> reinstate
>   a version history in the URI namespace of a server. With the BIND  
> method
>   there is a possibility by using a resource-id as the value of the href
>   element. In practice, this is a way for an end-user to recover an
>   accidentally deleted version-controlled resource.
Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Geoffrey M Clemm wrote:
>
> Point 1 is correct.  

Indeed.

I think Werner is right in that many do not understand the relation
between BIND and DeltaV, and thus it would be useful to state it.

We already have a "Relationship to WebDAV Access Control Protocol"
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.9>),
so my proposal would be to make that a generic "Relationship to other
WebDAV Specifications", and having one subsection for ACL and DeltaV each.

The DeltaV part could read (this is mainly Werner's text):

"When supporting version controlled collections, bindings may be
introduced in a server without actually issuing the BIND method. For
instance, when a MOVE is performed of a resource from one
version-controlled collection to another, both collections should be
checked out. An additional binding would be the result if the target
collection would be subsequently checked in, while the check-out of the
source collection is undone. The resulting situation is meaningless if
the binding model is not supported."

Note: I changed 2nd last sentence to state which collection is being
checked-in (the target) and which would be reverted (the source).

So, if we have /target, /source and /source/test, all of which
version-controlled, and do:

(1)

   CHECKOUT /source/ HTTP/1.1

(2)

   CHECKOUT /target/ HTTP/1.1

(3)

   MOVE /source/test HTTP/1.1
   Destination: /target/test

(4)

   CHECKIN /target/ HTTP/1.1

(5)

   UNCHECKOUT /source/ HTTP/1.1

we would end up with /source/test and /target/test being bindings to the
same resource.

If we did

(4b)

   UNCHECKOUT /source/ HTTP/1.1

(5b)

   CHECKIN /target/ HTTP/1.1

We would end up with zero bindings, so the resource would be gone (also
interesting, but...)

So, call for consensus:

a) Add that section?

b) Is the proposed text and scenario accurate?

c) Include the expanded example with message exchanges?

BR, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Julian Reschke wrote:

>
> Geoffrey M Clemm wrote:
>>
>> Point 1 is correct.  
>
> Indeed.
>
> I think Werner is right in that many do not understand the relation
> between BIND and DeltaV, and thus it would be useful to state it.
>
> We already have a "Relationship to WebDAV Access Control Protocol"
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.9>),
> so my proposal would be to make that a generic "Relationship to other
> WebDAV Specifications", and having one subsection for ACL and DeltaV each.
>
> The DeltaV part could read (this is mainly Werner's text):
>
> "When supporting version controlled collections, bindings may be
> introduced in a server without actually issuing the BIND method. For
> instance, when a MOVE is performed of a resource from one
> version-controlled collection to another, both collections should be
> checked out. An additional binding would be the result if the target
> collection would be subsequently checked in, while the check-out of the
> source collection is undone. The resulting situation is meaningless if
> the binding model is not supported."
> ...

Hm.

It just occurred to me that a server that implements MOVE as a sequence
of COPY and DELETE would expose a different behavior -- checking in the
destination collection but reverting the source collection would turn
the operation into the equivalent of a COPY, not a BIND...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm

The "Hm" note is correct.  A MOVE will create an additional binding if the MOVE has REBIND semantics, but not if the MOVE has COPY/DELETE semantics.

Cheers,
Geoff

Julian Reschke <[hidden email]> wrote on 08/16/2008 06:31:45 AM:

> Julian Reschke wrote:
> >
> > Geoffrey M Clemm wrote:
> >>
> >> Point 1 is correct.  
> >
> > Indeed.
> >
> > I think Werner is right in that many do not understand the relation
> > between BIND and DeltaV, and thus it would be useful to state it.
> >
> > We already have a "Relationship to WebDAV Access Control Protocol"
> > (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#rfc.section.9>),
> > so my proposal would be to make that a generic "Relationship to other
> > WebDAV Specifications", and having one subsection for ACL and DeltaV each.
> >
> > The DeltaV part could read (this is mainly Werner's text):
> >
> > "When supporting version controlled collections, bindings may be
> > introduced in a server without actually issuing the BIND method. For
> > instance, when a MOVE is performed of a resource from one
> > version-controlled collection to another, both collections should be
> > checked out. An additional binding would be the result if the target
> > collection would be subsequently checked in, while the check-out of the
> > source collection is undone. The resulting situation is meaningless if
> > the binding model is not supported."
> > ...
>
> Hm.
>
> It just occurred to me that a server that implements MOVE as a sequence
> of COPY and DELETE would expose a different behavior -- checking in the
> destination collection but reverting the source collection would turn
> the operation into the equivalent of a COPY, not a BIND...
>
> BR, Julian
Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné
In reply to this post by Geoffrey M Clemm


> But wrt point 2, RFC3243 does provide a way to reinstate a version  
> history, by specifying a Version in the body of a VERSION-CONTROL  
> request.  Also note that a BIND request would not provide a way to  
> reinstate a version history, because reinstating a version history  
> is done by creating a new version-controlled resource whose VERSION-
> HISTORY property identifies that version history (and this cannot be  
> done via a BIND operation).

In RFC 3253 I find in section 14.8 that you can indeed reinstate the  
version
history of a collection in this way, but I can't find anything like  
that for
resources that are not collections.

I see no evidence for the statement that a new version-controlled  
resource
should be created for reinstating a version history. This seems to be  
what
happens when the VERSION-CONTROL method is used, but that is not the  
same
thing.

The usage of BIND I propose is semantically equivalent to an addition to
the version-controlled-binding-set property of the parent collection  
of the
request URI.

Werner.
--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm

The semantics that let you use VERSION-CONTROL to "restore" any resource from its version-history are defined in section 6.7.
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.

Cheers,
Geoff




Werner Donné <[hidden email]> wrote on 08/19/2008 04:23:18 AM:

>
> > But wrt point 2, RFC3243 does provide a way to reinstate a version  
> > history, by specifying a Version in the body of a VERSION-CONTROL  
> > request.  Also note that a BIND request would not provide a way to  
> > reinstate a version history, because reinstating a version history  
> > is done by creating a new version-controlled resource whose VERSION-
> > HISTORY property identifies that version history (and this cannot be  
> > done via a BIND operation).
>
> In RFC 3253 I find in section 14.8 that you can indeed reinstate the  
> version
> history of a collection in this way, but I can't find anything like  
> that for
> resources that are not collections.
>
> I see no evidence for the statement that a new version-controlled  
> resource
> should be created for reinstating a version history. This seems to be  
> what
> happens when the VERSION-CONTROL method is used, but that is not the  
> same
> thing.
>
> The usage of BIND I propose is semantically equivalent to an addition to
> the version-controlled-binding-set property of the parent collection  
> of the
> request URI.
>
> Werner.
> --
> Werner Donné  --  Re                                     http://www.
> pincette.biz
> Engelbeekstraat 8                                              
> http://www.re.be
> BE-3300 Tienen
> tel: (+32) 486 425803   e-mail: [hidden email]
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné

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

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

> Cheers,
> Geoff
>

Werner.

>
>
>
> Werner Donné <[hidden email]> wrote on 08/19/2008 04:23:18 AM:
>
> >
> > > But wrt point 2, RFC3243 does provide a way to reinstate a version
> > > history, by specifying a Version in the body of a VERSION-CONTROL
> > > request.  Also note that a BIND request would not provide a way to
> > > reinstate a version history, because reinstating a version history
> > > is done by creating a new version-controlled resource whose  
> VERSION-
> > > HISTORY property identifies that version history (and this  
> cannot be
> > > done via a BIND operation).
> >
> > In RFC 3253 I find in section 14.8 that you can indeed reinstate the
> > version
> > history of a collection in this way, but I can't find anything like
> > that for
> > resources that are not collections.
> >
> > I see no evidence for the statement that a new version-controlled
> > resource
> > should be created for reinstating a version history. This seems to  
> be
> > what
> > happens when the VERSION-CONTROL method is used, but that is not the
> > same
> > thing.
> >
> > The usage of BIND I propose is semantically equivalent to an  
> addition to
> > the version-controlled-binding-set property of the parent collection
> > of the
> > request URI.
> >
> > Werner.
> > --
> > Werner Donné  --  Re                                     http://www.
> > pincette.biz
> > Engelbeekstraat 8
> > http://www.re.be
> > BE-3300 Tienen
> > tel: (+32) 486 425803   e-mail: [hidden email]
> >
> >
> >
> >
> >

--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm



Werner Donné <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné
In reply to this post by Geoffrey M Clemm

I don't understand how COPY/DELETE semantics for the MOVE could apply
to a version controlled resource. It would destroy the version history.
It may be a valid implementation, but not a very useful one.

Regards,

Werner.

On 16 Aug 2008, at 20:21, Geoffrey M Clemm wrote:

>
> The "Hm" note is correct.  A MOVE will create an additional binding  
> if the MOVE has REBIND semantics, but not if the MOVE has COPY/
> DELETE semantics.
>
> Cheers,
> Geoff
>
> Julian Reschke <[hidden email]> wrote on 08/16/2008 06:31:45  
> AM:
>
> > Julian Reschke wrote:
> > >
> > > Geoffrey M Clemm wrote:
> > >>
> > >> Point 1 is correct.
> > >
> > > Indeed.
> > >
> > > I think Werner is right in that many do not understand the  
> relation
> > > between BIND and DeltaV, and thus it would be useful to state it.
> > >
> > > We already have a "Relationship to WebDAV Access Control Protocol"
> > > (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> > html#rfc.section.9>),
> > > so my proposal would be to make that a generic "Relationship to  
> other
> > > WebDAV Specifications", and having one subsection for ACL and  
> DeltaV each.
> > >
> > > The DeltaV part could read (this is mainly Werner's text):
> > >
> > > "When supporting version controlled collections, bindings may be
> > > introduced in a server without actually issuing the BIND method.  
> For
> > > instance, when a MOVE is performed of a resource from one
> > > version-controlled collection to another, both collections  
> should be
> > > checked out. An additional binding would be the result if the  
> target
> > > collection would be subsequently checked in, while the check-out  
> of the
> > > source collection is undone. The resulting situation is  
> meaningless if
> > > the binding model is not supported."
> > > ...
> >
> > Hm.
> >
> > It just occurred to me that a server that implements MOVE as a  
> sequence
> > of COPY and DELETE would expose a different behavior -- checking  
> in the
> > destination collection but reverting the source collection would  
> turn
> > the operation into the equivalent of a COPY, not a BIND...
> >
> > BR, Julian

--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Geoffrey M Clemm

I change my response to agree with Werner.
RFC 3253 explicitly requires that the versioning metadata have a MOVE "move" semantics, not "copy/delete" semantics (section 3.15), so the "Hm" note does not apply.

Cheers,
Geoff

Werner Donné <[hidden email]> wrote on 08/28/2008 04:41:36 AM:

> I don't understand how COPY/DELETE semantics for the MOVE could apply
> to a version controlled resource. It would destroy the version history.
> It may be a valid implementation, but not a very useful one.
>
> Regards,
>
> Werner.
>
> On 16 Aug 2008, at 20:21, Geoffrey M Clemm wrote:
>
> >
> > The "Hm" note is correct.  A MOVE will create an additional binding  
> > if the MOVE has REBIND semantics, but not if the MOVE has COPY/
> > DELETE semantics.
> >
> > Cheers,
> > Geoff
> >
> > Julian Reschke <[hidden email]> wrote on 08/16/2008 06:31:45  
> > AM:
> >
> > > Julian Reschke wrote:
> > > >
> > > > Geoffrey M Clemm wrote:
> > > >>
> > > >> Point 1 is correct.
> > > >
> > > > Indeed.
> > > >
> > > > I think Werner is right in that many do not understand the  
> > relation
> > > > between BIND and DeltaV, and thus it would be useful to state it.
> > > >
> > > > We already have a "Relationship to WebDAV Access Control Protocol"
> > > > (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> > > html#rfc.section.9>),
> > > > so my proposal would be to make that a generic "Relationship to  
> > other
> > > > WebDAV Specifications", and having one subsection for ACL and  
> > DeltaV each.
> > > >
> > > > The DeltaV part could read (this is mainly Werner's text):
> > > >
> > > > "When supporting version controlled collections, bindings may be
> > > > introduced in a server without actually issuing the BIND method.  
> > For
> > > > instance, when a MOVE is performed of a resource from one
> > > > version-controlled collection to another, both collections  
> > should be
> > > > checked out. An additional binding would be the result if the  
> > target
> > > > collection would be subsequently checked in, while the check-out  
> > of the
> > > > source collection is undone. The resulting situation is  
> > meaningless if
> > > > the binding model is not supported."
> > > > ...
> > >
> > > Hm.
> > >
> > > It just occurred to me that a server that implements MOVE as a  
> > sequence
> > > of COPY and DELETE would expose a different behavior -- checking  
> > in the
> > > destination collection but reverting the source collection would  
> > turn
> > > the operation into the equivalent of a COPY, not a BIND...
> > >
> > > BR, Julian
>
> --
> Werner Donné  --  Re                                     http://www.
> pincette.biz
> Engelbeekstraat 8                                              
> http://www.re.be
> BE-3300 Tienen
> tel: (+32) 486 425803   e-mail: [hidden email]
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Geoffrey M Clemm wrote:
>
> I change my response to agree with Werner.
> RFC 3253 explicitly requires that the versioning metadata have a MOVE
> "move" semantics, not "copy/delete" semantics (section 3.15), so the
> "Hm" note does not apply.
>
> Cheers,
> Geoff

I agree as well.

So, should I spend some energy into integrating the proposal in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0039.html>
into the current version of the draft?

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

OK,

proposed text (see also
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav>):

10.  Relationship to Versioning Extensions to WebDAV

    Servers that implement Version Controlled Collections as defined in
    Section 14 of [RFC3253] already need to implement BIND-like behaviour
    in order to handle UPDATE and UNCHECKOUT semantics.

    Consider the version-controlled, checked-out collections C1 and C2,
    named "/CollX" and "/CollY", and a version-controlled resource R,
    bound to C1 as "/CollX/test":

                          +-------------------------+
                          | Root Collection         |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
                              |                |
                              |                |
                     +---------------+  +---------------+
                     | Collection C1 |  | Collection C2 |
                     | bindings:     |  |               |
                     |     test      |  |               |
                     +---------------+  +---------------+
                              |
                              |
                              |
                             +------------------+
                             |    Resource R    |
                             +------------------+

    Moving "/CollX/test" into "/CollY", checking in C2, but undoing the
    checkout on C1 will undo part of the MOVE request, thus restoring the
    binding from C1 to R, but keeping the new binding from C2 to R:

    >> Request:

    MOVE /CollX/test HTTP/1.1
    Host: www.example.com
    Destination: /CollY/test

    >> Response:

    HTTP/1.1 204 No Content

    >> Request:

    CHECKIN /CollY/ HTTP/1.1
    Host: www.example.com

    >> Response:

    HTTP/1.1 201 Created
    Cache-Control: no-cache
    Location: http://repo.example.com/his/17/ver/42

    >> Request:

    UNCHECKOUT /CollX/ HTTP/1.1
    Host: www.example.com

    >> Response:

    HTTP/1.1 200 OK
    Cache-Control: no-cache

    As a result, both C1 and C2 would have a binding to R:

                          +-------------------------+
                          | Root Collection         |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
                              |                |
                              |                |
                     +---------------+  +---------------+
                     | Collection C1 |  | Collection C2 |
                     | bindings:     |  | bindings:     |
                     |     test      |  |     test      |
                     +---------------+  +---------------+
                              |                |
                              |                |
                              |                |
                             +------------------+
                             |    Resource R    |
                             +------------------+

    The MOVE semantics defined in Section 3.15 of [RFC3253] already
    require that "/CollX/test" and "/CollY/test" will have the same
    version history (as exposed in the DAV:version-history property).
    Furthermore, the UNCHECKOUT semantics (which in this case is similar
    to UPDATE, see Section 14.11 of [RFC3253]) require:

       ...If a new version-controlled member is in a workspace that
       already has a version-controlled resource for that version
       history, then the new version-controlled member MUST be just a
       binding (i.e., another name for) that existing version-controlled
       resource...

    Thus, "/CollX/test" and "/CollY/test" will be bindings to the same
    resource R, and have identical DAV:resource-id properties.



...feedback appreciated.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Julian Reschke wrote:
>
> OK,
>
> proposed text (see also
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav>):

...in the meantime I realized that this is only true if it happens
inside a workspace. New version (changing the intro and the paths):

10.  Relationship to Versioning Extensions to WebDAV

    Servers that implement Workspaces ([RFC3253], Section 6) and Version
    Controlled Collections ([RFC3253], Section 14) already need to
    implement BIND-like behaviour in order to handle UPDATE and
    UNCHECKOUT semantics.

    Consider a workspace "/ws1/", containing the version-controlled,
    checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
    CollY", and a version-controlled resource R, bound to C1 as "/ws1/
    CollX/test":

                          +-------------------------+
                          | Workspace               |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
                              |                |
                              |                |
                     +---------------+  +---------------+
                     | Collection C1 |  | Collection C2 |
                     | bindings:     |  |               |
                     |     test      |  |               |
                     +---------------+  +---------------+
                              |
                              |
                              |
                             +------------------+
                             |    Resource R    |
                             +------------------+

    Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but
    undoing the checkout on C1 will undo part of the MOVE request, thus
    restoring the binding from C1 to R, but keeping the new binding from
    C2 to R:

    >> Request:

    MOVE /ws1/CollX/test HTTP/1.1
    Host: www.example.com
    Destination: /ws1/CollY/test

    >> Response:

    HTTP/1.1 204 No Content

    >> Request:

    CHECKIN /ws1/CollY/ HTTP/1.1
    Host: www.example.com

    >> Response:

    HTTP/1.1 201 Created
    Cache-Control: no-cache
    Location: http://repo.example.com/his/17/ver/42

    >> Request:

    UNCHECKOUT /ws1/CollX/ HTTP/1.1
    Host: www.example.com

    >> Response:

    HTTP/1.1 200 OK
    Cache-Control: no-cache

    As a result, both C1 and C2 would have a binding to R:

                          +-------------------------+
                          | Workspace               |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
                              |                |
                              |                |
                     +---------------+  +---------------+
                     | Collection C1 |  | Collection C2 |
                     | bindings:     |  | bindings:     |
                     |     test      |  |     test      |
                     +---------------+  +---------------+
                              |                |
                              |                |
                              |                |
                             +------------------+
                             |    Resource R    |
                             +------------------+

    The MOVE semantics defined in Section 3.15 of [RFC3253] already
    require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the
    same version history (as exposed in the DAV:version-history
    property).  Furthermore, the UNCHECKOUT semantics (which in this case
    is similar to UPDATE, see Section 14.11 of [RFC3253]) require:

       ...If a new version-controlled member is in a workspace that
       already has a version-controlled resource for that version
       history, then the new version-controlled member MUST be just a
       binding (i.e., another name for) that existing version-controlled
       resource...

    Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the
    same resource R, and have identical DAV:resource-id properties.

BR, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné

Hi Julian,

Why is it only valid inside a workspace?

Best regards,

Werner.

On 07 Oct 2008, at 14:24, Julian Reschke wrote:

> Julian Reschke wrote:
>> OK,
>> proposed text (see also <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav 
>> >):
>
> ...in the meantime I realized that this is only true if it happens  
> inside a workspace. New version (changing the intro and the paths):
>
> 10.  Relationship to Versioning Extensions to WebDAV
>
>   Servers that implement Workspaces ([RFC3253], Section 6) and Version
>   Controlled Collections ([RFC3253], Section 14) already need to
>   implement BIND-like behaviour in order to handle UPDATE and
>   UNCHECKOUT semantics.
>
>   Consider a workspace "/ws1/", containing the version-controlled,
>   checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
>   CollY", and a version-controlled resource R, bound to C1 as "/ws1/
>   CollX/test":
>
>                         +-------------------------+
>                         | Workspace               |
>                         |  bindings:              |
>                         |  CollX          CollY   |
>                         +-------------------------+
>                             |                |
>                             |                |
>                             |                |
>                    +---------------+  +---------------+
>                    | Collection C1 |  | Collection C2 |
>                    | bindings:     |  |               |
>                    |     test      |  |               |
>                    +---------------+  +---------------+
>                             |
>                             |
>                             |
>                            +------------------+
>                            |    Resource R    |
>                            +------------------+
>
>   Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but
>   undoing the checkout on C1 will undo part of the MOVE request, thus
>   restoring the binding from C1 to R, but keeping the new binding from
>   C2 to R:
>
>   >> Request:
>
>   MOVE /ws1/CollX/test HTTP/1.1
>   Host: www.example.com
>   Destination: /ws1/CollY/test
>
>   >> Response:
>
>   HTTP/1.1 204 No Content
>
>   >> Request:
>
>   CHECKIN /ws1/CollY/ HTTP/1.1
>   Host: www.example.com
>
>   >> Response:
>
>   HTTP/1.1 201 Created
>   Cache-Control: no-cache
>   Location: http://repo.example.com/his/17/ver/42
>
>   >> Request:
>
>   UNCHECKOUT /ws1/CollX/ HTTP/1.1
>   Host: www.example.com
>
>   >> Response:
>
>   HTTP/1.1 200 OK
>   Cache-Control: no-cache
>
>   As a result, both C1 and C2 would have a binding to R:
>
>                         +-------------------------+
>                         | Workspace               |
>                         |  bindings:              |
>                         |  CollX          CollY   |
>                         +-------------------------+
>                             |                |
>                             |                |
>                             |                |
>                    +---------------+  +---------------+
>                    | Collection C1 |  | Collection C2 |
>                    | bindings:     |  | bindings:     |
>                    |     test      |  |     test      |
>                    +---------------+  +---------------+
>                             |                |
>                             |                |
>                             |                |
>                            +------------------+
>                            |    Resource R    |
>                            +------------------+
>
>   The MOVE semantics defined in Section 3.15 of [RFC3253] already
>   require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the
>   same version history (as exposed in the DAV:version-history
>   property).  Furthermore, the UNCHECKOUT semantics (which in this  
> case
>   is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
>
>      ...If a new version-controlled member is in a workspace that
>      already has a version-controlled resource for that version
>      history, then the new version-controlled member MUST be just a
>      binding (i.e., another name for) that existing version-controlled
>      resource...
>
>   Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to  
> the
>   same resource R, and have identical DAV:resource-id properties.
>
> BR, Julian

--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Werner Donné wrote:
>
> Hi Julian,
>
> Why is it only valid inside a workspace?
>
> Best regards,
>
> Werner.

The behavior for UNCHECKOUT on versioned collections isn't described in
RFC3253, but the errata list
(<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>) says:

"14_MISSING_ SEMANTICS
       
Editorial
       
Editor
       
The semantics of UNCHECKOUT applied to a version-controlled collection
is undefined.
       
Julian Reschke: message
       
Define UNCHECKOUT semantics to be those of doing an UPDATE to the
DAV:checked-out version."


What's relevant is 14.11 (IMHO), which says:

"...If a new version-controlled member is in a workspace that already
has a version-controlled resource for that version history, then the new
version-controlled member MUST be just a binding (i.e., another name
for) that existing version-controlled resource. Otherwise, the content
and dead properties of the new version-controlled member MUST have been
initialized to be those of the version specified for that version
history by the request..."

So it seems that creating a *different* version controlled resource
would be allowed here.

BR, Julian



Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné

There are indeed no additional semantics for UNCHECKOUT in section 14.
Therefore, I think the semantics of section section 4.5 apply, because
a version-controlled collection is also a version-controlled resource.

Though the introduction of section 14 mentions workspaces, I don't think
the merge feature is limited to workspaces. It is allowed to use a
version-controlled collection as the request URI and a collection  
version
as the source. If both would be associated with the same version  
history,
for example, it would be strange if in such a case new version-
controlled
members would be created as described in section 4.11.

Werner.

On 07 Oct 2008, at 14:45, Julian Reschke wrote:

> Werner Donné wrote:
>> Hi Julian,
>> Why is it only valid inside a workspace?
>> Best regards,
>> Werner.
>
> The behavior for UNCHECKOUT on versioned collections isn't described  
> in RFC3253, but the errata list (<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm 
> >) says:
>
> "14_MISSING_ SEMANTICS
>
> Editorial
>
> Editor
>
> The semantics of UNCHECKOUT applied to a version-controlled  
> collection is undefined.
>
> Julian Reschke: message
>
> Define UNCHECKOUT semantics to be those of doing an UPDATE to the  
> DAV:checked-out version."
>
>
> What's relevant is 14.11 (IMHO), which says:
>
> "...If a new version-controlled member is in a workspace that  
> already has a version-controlled resource for that version history,  
> then the new version-controlled member MUST be just a binding (i.e.,  
> another name for) that existing version-controlled resource.  
> Otherwise, the content and dead properties of the new version-
> controlled member MUST have been initialized to be those of the  
> version specified for that version history by the request..."
>
> So it seems that creating a *different* version controlled resource  
> would be allowed here.
>
> BR, Julian
>

--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Werner Donné wrote:
> There are indeed no additional semantics for UNCHECKOUT in section 14.

Well, we have an erratum for UNCHECKOUT in Section 14, and Geoff has
already proposed a resolution; do you disagree with it?

> Therefore, I think the semantics of section section 4.5 apply, because
> a version-controlled collection is also a version-controlled resource.

Yes, those apply; but how exactly do they help clarifying what the
server needs to do?

> Though the introduction of section 14 mentions workspaces, I don't think
> the merge feature is limited to workspaces. It is allowed to use a
> version-controlled collection as the request URI and a collection version
> as the source. If both would be associated with the same version history,
> for example, it would be strange if in such a case new version-controlled
> members would be created as described in section 4.11.

That's possible (I haven't implemented merge); and maybe that's a
separate erratum.

Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I think
it's sufficient if we describe a case where RFC 3253 *clearly* requires
BIND semantics; so is the currently proposed text correct?

BR, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Werner Donné


On 07 Oct 2008, at 16:09, Julian Reschke wrote:

> Werner Donné wrote:
>> There are indeed no additional semantics for UNCHECKOUT in section  
>> 14.
>
> Well, we have an erratum for UNCHECKOUT in Section 14, and Geoff has  
> already proposed a resolution; do you disagree with it?

>
>> Therefore, I think the semantics of section section 4.5 apply,  
>> because
>> a version-controlled collection is also a version-controlled  
>> resource.
>
> Yes, those apply; but how exactly do they help clarifying what the  
> server needs to do?

For me section 4.5 is complete. It says that the pre-CHECKOUT state  
should be
restored. This means that the checked-in version becomes what it was  
before
the CHECKOUT. The version-controlled binding set of that checked-in  
version
must not have changed, because the corresponding property is protected  
and the
DELETE and VERSION-CONTROL methods have the proper pre-conditions to  
prevent it.

In your original message you raise the question about what should  
happen when
a VCR has been deleted since the last check-out. This is not a  
specific matter
for UNCHECKOUT. When a DELETE is performed on a VCR that corresponds  
to member
in a checked out collection, the server is responsible for making sure  
that
the version-controlled binding sets of all versions of that collection  
are not
affected.

I don't think section 4.11 can apply to the UNCHECKOUT method, because  
it says
what should happen when the checked-in version of a version-controlled  
collection
is modified. A checked out collection is a checked out resource and  
those don't
have the checked-in version property. The property is reintroduced not  
modified.

>
>
>> Though the introduction of section 14 mentions workspaces, I don't  
>> think
>> the merge feature is limited to workspaces. It is allowed to use a
>> version-controlled collection as the request URI and a collection  
>> version
>> as the source. If both would be associated with the same version  
>> history,
>> for example, it would be strange if in such a case new version-
>> controlled
>> members would be created as described in section 4.11.
>
> That's possible (I haven't implemented merge); and maybe that's a  
> separate erratum.
>
> Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I  
> think it's sufficient if we describe a case where RFC 3253 *clearly*  
> requires BIND semantics; so is the currently proposed text correct?
>

I agree that from the view point of the BIND spec this is sufficient  
and the
proposed text is correct.

> BR, Julian


Werner.
--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Relationship between BIND and RFC 3253

Julian Reschke

Werner Donné wrote:

>> Yes, those apply; but how exactly do they help clarifying what the
>> server needs to do?
>
> For me section 4.5 is complete. It says that the pre-CHECKOUT state
> should be
> restored. This means that the checked-in version becomes what it was before
> the CHECKOUT. The version-controlled binding set of that checked-in version
> must not have changed, because the corresponding property is protected
> and the
> DELETE and VERSION-CONTROL methods have the proper pre-conditions to
> prevent it.

But we're talking about the pre-CHECKOUT state of the *collection*, not
its member.

> In your original message you raise the question about what should happen
> when
> a VCR has been deleted since the last check-out. This is not a specific
> matter

Did I? I don't think so, but maybe I'm confused. Can we stick to the
example that I proposed? Is there something wrong with it?

> for UNCHECKOUT. When a DELETE is performed on a VCR that corresponds to
> member
> in a checked out collection, the server is responsible for making sure that
> the version-controlled binding sets of all versions of that collection
> are not
> affected.

Yes.

> I don't think section 4.11 can apply to the UNCHECKOUT method, because
> it says
> what should happen when the checked-in version of a version-controlled
> collection
> is modified. A checked out collection is a checked out resource and
> those don't
> have the checked-in version property. The property is reintroduced not
> modified.

UNCHECKOUT changes the state of the collection to be checked in, so yes,
I would claim that operation affects the DAV:checked-in property.

> ...
>> Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I
>> think it's sufficient if we describe a case where RFC 3253 *clearly*
>> requires BIND semantics; so is the currently proposed text correct?
>>
>
> I agree that from the view point of the BIND spec this is sufficient and
> the
> proposed text is correct.
> ...

Great!

I didn't mean to prevent other discussions, I just want to get things
done step by step...

BR, Julian