W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2008

Re: Relationship between BIND and RFC 3253

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 07 Oct 2008 14:24:03 +0200
Message-ID: <48EB54E3.4000509@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT