- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Oct 2008 14:24:03 +0200
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- CC: Werner Donné <werner.donne@re.be>, w3c-dist-auth@w3.org
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
Received on Tuesday, 7 October 2008 12:24:46 UTC