Subject: Re: Relationship between BIND and RFC 3253

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Oct 2008 19:02:49 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Oct 2008 14:24:03 +0200

> <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):

    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               |

    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

    >> Request:

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

    HTTP/1.1 204 No Content

    >> Request:

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

    HTTP/1.1 201 Created
    Cache-Control: no-cache

    >> Request:

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

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

                          | Workspace               |

    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:

    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

---

From: Werner Donné <[email-masked]>
Date: Tue, 7 Oct 2008 14:34:43 +0200

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 
>> >):
>

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Oct 2008 14:45:20 +0200

> Why is it only valid inside a workspace?

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

---

From: Werner Donné <[email-masked]>
Date: Tue, 7 Oct 2008 15:50:06 +0200

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:

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Oct 2008 16:09:29 +0200

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

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

> 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

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

---

From: Werner Donné <[email-masked]>
Date: Tue, 7 Oct 2008 17:18:02 +0200

> Yes, those apply; but how exactly do they help clarifying what the  

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.

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

Werner.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Oct 2008 17:33:24 +0200

Werner Donné wrote:
> 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

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

Yes.

> have the checked-in version property. The property is reintroduced not 

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

> ...
> I agree that from the view point of the BIND spec this is sufficient and 
> the
> ...

Great!

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

BR, Julian