Re: Relationship between BIND and RFC 3253

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

Received on Saturday, 4 October 2008 17:03:48 UTC