tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3253

 
 
 

Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

Part 4 of 4, p. 90 to 118
Prev RFC Part

 


prevText      Top      Up      ToC       Page 90 
13 Activity Feature

   An activity is a resource that selects a set of versions that are on
   a single "line of descent", where a line of descent is a sequence of
   versions connected by successor relationships.  If an activity
   selects versions from multiple version histories, the versions
   selected in each version history must be on a single line of descent.

   A common problem that motivates the use of activities is that it is
   often desirable to perform several different logical changes in a
   single workspace, and then selectively merge a subset of those
   logical changes to other workspaces.  An activity can be used to
   represent a single logical change, where an activity tracks all the
   resources that were modified to effect that single logical change.
   When a version-controlled resource is checked out, the user specifies
   which activity should be associated with a new version that will be
   created when that version-controlled resource is checked in.  It is
   then possible to select a particular logical change for merging into
   another workspace, by specifying the appropriate activity in a MERGE
   request.

   Another common problem is that although a version-controlled resource
   may need to have multiple lines of descent, all work done by members
   of a given team must be on a single line of descent (to avoid merging
   between team members).  An activity resource provides the mechanism
   for addressing this problem.  When a version-controlled resource is
   checked out, a client can request that an existing activity be used
   or that a new activity be created.  Activity semantics then ensure
   that all versions in a given version history that are associated with
   an activity are on a single line of descent.  If all members of a
   team share a common activity (or sub-activities of a common
   activity), then all changes made by members of that team will be on a
   single line of descent.

Top      Up      ToC       Page 91 
   The following diagram illustrates activities.  Version V5 is the
   latest version of foo.html selected by activity Act-2, and version V8
   is the latest version of bar.html selected by activity Act-2.

                  foo.html History       bar.html History

                        +---+                  +---+
                   Act-1|   |V1           Act-1|   |V6
                        +---+                  +---+
                          |                      |
                          |                      |
                        +---+                  +---+
                   Act-1|   |V2           Act-2|   |V7
                        +---+                  +---+
                       /     \                   |
                      /       \                  |
                 +---+         +---+           +---+
            Act-1|   |V3  Act-2|   |V4    Act-2|   |V8
                 +---+         +---+           +---+
                                 |               |
                                 |               |
                               +---+           +---+
                          Act-2|   |V5    Act-3|   |V9
                               +---+           +---+

   Activities appear under a variety of names in existing versioning
   systems.  When an activity is used to capture a logical change, it is
   commonly called a "change set".  When an activity is used to capture
   a line of descent, it is commonly called a "branch".  When a system
   supports both branches and change sets, it is often useful to require
   that a particular change set occur on a particular branch.  This
   relationship can be captured by making the change set activity be a
   "subactivity" of the branch activity.

13.1 Activity Properties

   The DAV:resourcetype of an activity MUST be DAV:activity.

   The activity feature introduces the following REQUIRED properties for
   an activity.

13.1.1 DAV:activity-version-set (computed)

   This property identifies each version whose DAV:activity-set property
   identifies this activity.  Multiple versions of a single version
   history can be selected by an activity's DAV:activity-version-set

Top      Up      ToC       Page 92 
   property, but all DAV:activity-version-set versions from a given
   version history must be on a single line of descent from the root
   version of that version history.

   <!ELEMENT activity-version-set (href*)>

13.1.2 DAV:activity-checkout-set (computed)

   This property identifies each checked-out resource whose
   DAV:activity-set identifies this activity.

   <!ELEMENT activity-checkout-set (href*)>

13.1.3 DAV:subactivity-set

   This property identifies each activity that forms a part of the
   logical change being captured by this activity.  An activity behaves
   as if its DAV:activity-version-set is extended by the DAV:activity-
   version-set of each activity identified in the DAV:subactivity-set.
   In particular, the versions in this extended set MUST be on a single
   line of descent, and when an activity selects a version for merging,
   the latest version in this extended set is the one that will be
   merged.

   A server MAY reject attempts to modify the DAV:subactivity-set of an
   activity.

   <!ELEMENT subactivity-set (href*)>

13.1.4 DAV:current-workspace-set (computed)

   This property identifies each workspace whose DAV:current-activity-
   set identifies this activity.

   <!ELEMENT current-workspace-set (href*)>

13.2 Additional Version Properties

   The activity feature introduces the following REQUIRED property for a
   version.

Top      Up      ToC       Page 93 
13.2.1 DAV:activity-set

   This property identifies the activities that determine to which
   logical changes this version contributes, and on which lines of
   descent this version appears.  A server MAY restrict the
   DAV:activity-set to identify a single activity.  A server MAY refuse
   to allow the value of the DAV:activity-set property of a version to
   be modified.

   <!ELEMENT activity-set (href*)>

13.3 Additional Checked-Out Resource Properties

   The activity feature introduces the following REQUIRED properties for
   a checked-out resource.

13.3.1 DAV:unreserved

   This property of a checked-out resource indicates whether the
   DAV:activity-set of another checked-out resource associated with the
   version history of this version-controlled resource can have an
   activity that is in the DAV:activity-set property of this checked-out
   resource.

   A result of the requirement that an activity must form a single line
   of descent through a given version history is that if multiple
   checked-out resources for a given version history are checked out
   unreserved into a single activity, only the first CHECKIN will
   succeed.  Before another of these checked-out resources can be
   checked in, the user will first have to merge into that checked-out
   resource the latest version selected by that activity from that
   version history, and then modify the DAV:predecessor-set of that
   checked-out resource to identify that version.

   <!ELEMENT unreserved (#PCDATA)>
   PCDATA value: boolean

13.3.2 DAV:activity-set

   This property of a checked-out resource determines the DAV:activity-
   set property of the version that results from checking in this
   resource.

13.4 Additional Workspace Properties

   The activity feature introduces the following REQUIRED property for a
   workspace.

Top      Up      ToC       Page 94 
13.4.1 DAV:current-activity-set

   This property identifies the activities that currently are being
   performed in this workspace.  When a member of this workspace is
   checked out, if no activity is specified in the checkout request, the
   DAV:current-activity-set will be used.  This allows an activity-
   unaware client to update a workspace in which activity tracking is
   required.  The DAV:current-activity-set MAY be restricted to identify
   at most one activity.

   <!ELEMENT current-activity-set (href*)>

13.5 MKACTIVITY Method

   A MKACTIVITY request creates a new activity resource.  A server MAY
   restrict activity creation to particular collections, but a client
   can determine the location of these collections from a DAV:activity-
   collection-set OPTIONS request.

   Marshalling:

      If a request body is included, it MUST be a DAV:mkactivity XML
      element.

      <!ELEMENT mkactivity ANY>

      If a response body for a successful request is included, it MUST
      be a DAV:mkactivity-response XML element.

      <!ELEMENT mkactivity-response ANY>

      The response MUST include a Cache-Control:no-cache header.

   Preconditions:

      (DAV:resource-must-be-null): A resource MUST NOT exist at the
      request-URL.

      (DAV:activity-location-ok): The request-URL MUST identify a
      location where an activity can be created.

   Postconditions:

      (DAV:initialize-activity): A new activity exists at the request-
      URL.  The DAV:resourcetype of the activity MUST be DAV:activity.

Top      Up      ToC       Page 95 
13.5.1 Example - MKACTIVITY

   >>REQUEST

     MKACTIVITY /act/test-23 HTTP/1.1
     Host: repo.webdav.org
     Content-Length: 0

   >>RESPONSE

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

   In this example, a new activity is created at
   http://repo.webdav.org/act/test-23.

13.6 DAV:latest-activity-version Report

   The DAV:latest-activity-version report can be applied to a version
   history to identify the latest version that is selected from that
   version history by a given activity.

   Marshalling:

      The request body MUST be a DAV:latest-activity-version XML
      element.

      <!ELEMENT latest-activity-version (href)>

      The response body for a successful request MUST be a DAV:latest-
      activity-version-report XML element.

      <!ELEMENT latest-activity-version-report (href)>

      The DAV:href of the response body MUST identify the version of the
      given version history that is a member of the DAV:activity-
      version-set of the given activity and has no descendant that is a
      member of the DAV:activity-version-set of that activity.

   Preconditions:

      (DAV:must-be-activity): The DAV:href in the request body MUST
      identify an activity.

Top      Up      ToC       Page 96 
13.7 Additional OPTIONS Semantics

   If the server supports the activity feature, it MUST include
   "activity" as a field in the DAV response header from an OPTIONS
   request on any resource that supports any versioning properties,
   reports, or methods.

   A DAV:activity-collection-set element MAY be included in the request
   body to identify collections that may contain activity resources.

   Additional Marshalling:

      If an XML request body is included, it MUST be a DAV:options XML
      element.

      <!ELEMENT options ANY>
      ANY value: A sequence of elements with at most one
      DAV:activity-collection-set element.

      If an XML response body for a successful request is included, it
      MUST be a DAV:options-response XML element.

      <!ELEMENT options-response ANY>
      ANY value: A sequence of elements with at most one
      DAV:activity-collection-set element.

      <!ELEMENT activity-collection-set (href*)>

      If DAV:activity-collection-set is included in the request body,
      the response body for a successful request MUST contain a
      DAV:activity-collection-set element identifying collections that
      may contain activities.  An identified collection MAY be the root
      collection of a tree of collections, all of which may contain
      activities.  Since different servers can control different parts
      of the URL namespace, different resources on the same host MAY
      have different DAV:activity-collection-set values.  The identified
      collections MAY be located on different hosts from the resource.

13.8 Additional DELETE Semantics

   Additional Postconditions:

      (DAV:delete-activity-reference): If an activity is deleted, any
      reference to that activity in a DAV:activity-set,
      DAV:subactivity-set, or DAV:current-activity-set MUST be removed.

Top      Up      ToC       Page 97 
13.9 Additional MOVE Semantics

   Additional Postconditions:

      (DAV:update-checked-out-reference): If a checked-out resource is
      moved, any reference to that resource in a DAV:activity-checkout-
      set property MUST be updated to refer to the new location of that
      resource.

      (DAV:update-activity-reference): If the request-URL identifies an
      activity, any reference to that activity in a DAV:activity-set,
      DAV:subactivity-set, or DAV:current-activity-set MUST be updated
      to refer to the new location of that activity.

      (DAV:update-workspace-reference): If the request-URL identifies a
      workspace, any reference to that workspace in a DAV:current-
      workspace-set property MUST be updated to refer to the new
      location of that workspace.

13.10 Additional CHECKOUT Semantics

   A CHECKOUT request MAY specify the DAV:activity-set for the checked-
   out resource.

   Additional Marshalling:

      <!ELEMENT checkout ANY> ANY value: A sequence of elements with at
      most one DAV:activity-set and at most one DAV:unreserved.

      <!ELEMENT activity-set (href+ | new)>
      <!ELEMENT new EMPTY>
      <!ELEMENT unreserved EMPTY>

   Additional Preconditions:

      (DAV:one-checkout-per-activity-per-history): If there is a request
      activity set, unless DAV:unreserved is specified, another checkout
      from a version of that version history MUST NOT select an activity
      in that activity set.

      (DAV:linear-activity): If there is a request activity set, unless
      DAV:unreserved is specified, the selected version MUST be a
      descendant of all other versions of that version history that
      select that activity.

Top      Up      ToC       Page 98 
   Additional Postconditions:

      (DAV:initialize-activity-set): The DAV:activity-set of the
      checked-out resource is set as follows:

      -  If DAV:new is specified as the DAV:activity-set in the request
         body, then a new activity created by the server is used.
      -  Otherwise, if activities are specified in the request body,
         then those activities are used.
      -  Otherwise, if the version-controlled resource is a member of a
         workspace and the DAV:current-activity-set of the workspace is
         set, then those activities are used.
      -  Otherwise, the DAV:activity-set of the DAV:checked-out version
         is used.

      (DAV:initialize-unreserved): If DAV:unreserved was specified in
      the request body, then the DAV:unreserved property of the
      checked-out resource MUST be "true".

13.10.1 Example - CHECKOUT with an activity

   >>REQUEST

     CHECKOUT /ws/public/foo.html HTTP/1.1
     Host: www.webdav.org
     Content-Type: text/xml; charset="utf-8"
     Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <D:checkout xmlns:D="DAV:">
       <D:activity-set>
         <D:href>http://repo.webdav.org/act/fix-bug-23</D:href>
       </D:activity-set>
     </D:checkout>

   >>RESPONSE

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

   In this example, the CHECKOUT is being performed in the
   http://repo.webdav.org/act/fix-bug-23 activity.

Top      Up      ToC       Page 99 
13.11 Additional CHECKIN Semantics

   Additional Preconditions:

      (DAV:linear-activity): Any version which is in the version history
      of the checked-out resource and whose DAV:activity-set identifies
      an activity from the DAV:activity-set of the checked-out resource
      MUST be an ancestor of the checked-out resource.

      (DAV:atomic-activity-checkin): If the request-URL identifies an
      activity, the server MAY fail the request if any of the checked-
      out resources in the DAV:activity-checkout-set of either that
      activity or any subactivity of that activity cannot be checked in.

   Additional Postconditions:

      (DAV:initialize-activity-set): The DAV:activity-set of the new
      version MUST have been initialized to be the same as the
      DAV:activity-set of the checked-out resource.

      (DAV:activity-checkin): If the request-URL identified an activity,
      the server MUST have successfully applied the CHECKIN request to
      each checked-out resource in the DAV:activity-checkout-set of both
      that activity and any subactivity of that activity.

13.12 Additional MERGE Semantics

   If the DAV:source element of the request body identifies an activity,
   then for each version history containing a version selected by that
   activity, the latest version selected by that activity is a merge
   source.  Note that the versions selected by an activity are the
   versions in its DAV:activity-version-set unioned with the versions
   selected by the activities in its DAV:subactivity-set.

   Additional Marshalling:

      <!ELEMENT checkin-activity EMPTY>

   Additional Postconditions:

      (DAV:checkin-activity): If DAV:checkin-activity is specified in
      the request body, and if the DAV:source element in the request
      body identifies an activity, a CHECKIN request MUST have been
      successfully applied to that activity before the merge sources
      were determined.

Top      Up      ToC       Page 100 
14 Version-Controlled-Collection Feature

   As with any versionable resource, when a collection is put under
   version control, a version history resource is created to contain
   versions for that version-controlled collection.  In order to
   preserve standard versioning semantics (a version of a collection
   should not be modifiable), a collection version only records
   information about the version-controlled bindings of that collection.

   In order to cleanly separate a modification to the namespace from a
   modification to content or dead properties, a version of a collection
   has no members, but instead records in its DAV:version-controlled-
   binding-set property the binding name and version history resource of
   each version-controlled internal member of that collection.  If,
   instead, a collection version contained bindings to other versions,
   creating a new version of a resource would require creating a new
   version of all the collection versions that contain that resource,
   which would cause activities to become entangled.  For example,
   suppose a "feature-12" activity created a new version of /x/y/a.html.
   If a collection version contained bindings to versions of its
   members, a new version of /x/y would have to be created to contain
   the new version of /x/y/a.html, and a new version of /x would have to
   be created to contain the new version of /x/y.  Now suppose a
   "bugfix-47" activity created a new version of /x/z/b.html.  Again, a
   new version of /x/z and a new version of /x would have to be created
   to contain the new version of /x/y/b.html.  But now it is impossible
   to merge just "bugfix-47" into another workspace without "feature-
   12", because the version of /x that contains the desired version of
   /x/z/b.html also contains version of /x/y/a.html created for
   "feature-12".  If, instead, a collection version just records the
   binding name and version history resource of each version-controlled
   internal member, changing the version selected by a member of that
   collection would not require a new version of the collection.  The
   new version is still in the same version history so no new collection
   version is required, and "feature-12" and "bugfix-47" would not
   become entangled.

   In the following example, there are three version histories, named
   VH14, VH19, and VH24, where VH14 contains versions of a collection.
   The version-controlled collection /x has version V2 of version
   history VH14 as its DAV:checked-in version.  Since V2 has recorded
   two version controlled bindings, one with binding name "a" to version
   history VH19, and the other with binding name "b" to version history
   VH24, /x MUST have two version-controlled bindings, one named "a" to
   a version-controlled resource for history VH19, and the other named
   "b" to a version-controlled resource for history VH24.  The version-

Top      Up      ToC       Page 101 
   controlled resource /x/a currently has V4 of VH19 as its
   DAV:checked-in version, while /x/b has V8 of VH24 as its
   DAV:checked-in version.

                                                          VH19
                                                       +---------+
                                                       | +---+   |
                                                       | |   |V4 |
                                                       | +---+   |
                                                       |   |     |
                                                       |   |     |
                                                       | +---+   |
                                                       | |   |V5 |
                                            VH14       | +---+   |
                                        +---------+    |   |     |
                                        | +---+   |    |   |     |
               a  +---+                 | |   |V1 |    | +---+   |
             ---->|   |checked-in=V4    | +---+   | a  | |   |V6 |
            /     +---+                 |   |   ------>| +---+   |
           /                            |   |  /  |    +---------+
      +---+                             | +---+   |
   /x |   |checked-in=V2                | |   |V2 |
      +---+                             | +---+   |       VH24
           \                            |   |  \  | b  +---------+
            \  b  +---+                 |   |   ------>| +---+   |
             ---->|   |checked-in=V8    | +---+   |    | |   |V7 |
                  +---+                 | |   |V3 |    | +---+   |
                                        | +---+   |    |   |     |
                                        +---------+    |   |     |
                                                       | +---+   |
                                                       | |   |V8 |
                                                       | +---+   |
                                                       |   |     |
                                                       |   |     |
                                                       | +---+   |
                                                       | |   |V9 |
                                                       | +---+   |
                                                       +---------+

   For any request (e.g., DELETE, MOVE, COPY) that modifies a version-
   controlled binding of a checked-in version-controlled collection, the
   request MUST fail unless the version-controlled collection has a
   DAV:auto-version property that will automatically check out the
   version-controlled collection when it is modified.

   Although a collection version only records the version-controlled
   bindings of a collection, a version-controlled collection MAY contain
   both version-controlled and non-version-controlled bindings.  Non-

Top      Up      ToC       Page 102 
   version-controlled bindings are not under version control, and
   therefore can be added or deleted without checking out the version-
   controlled collection.

   Note that a collection version captures only a defined subset of the
   state of a collection.  In particular, a version of a collection
   captures its dead properties and its bindings to version-controlled
   resources, but not its live properties or bindings to non-version-
   controlled resources.

   When a server supports the working-resource feature, a client can
   check out a collection version to create a working collection.
   Unlike a version-controlled collection, which contains bindings to
   version-controlled resources and non-version-controlled resources, a
   working collection contains bindings to version history resources and
   non-version-controlled resources.  In particular, a working
   collection is initialized to contain bindings to the version history
   resources specified by the DAV:version-controlled-binding-set of the
   checked out collection version.  The members of a working collection
   can then be deleted or moved to another working collection.  Non-
   version-controlled resources can be added to a working collection
   with methods such as PUT, COPY, and MKCOL.  When a working collection
   is checked in, a VERSION-CONTROL request is automatically applied to
   every non-version-controlled member of the working collection, and
   each non-version-controlled member is replaced by its newly created
   version history.  The DAV:version-controlled-binding-set of the new
   version resulting from checking in a working collection contains the
   binding name and version history URL for each member of the working
   collection.

14.1 Version-Controlled Collection Properties

   A version-controlled collection has all the properties of a
   collection and of a version-controlled resource.  In addition, the
   version-controlled-collection feature introduces the following
   REQUIRED property for a version-controlled collection.

14.1.1 DAV:eclipsed-set (computed)

   This property identifies the non-version-controlled internal members
   of the collection that currently are eclipsing a version-controlled
   internal member of the collection.

   !ELEMENT eclipsed-set (binding-name*)>
   <!ELEMENT binding-name (#PCDATA)>
   PCDATA value: URL segment

Top      Up      ToC       Page 103 
   An UPDATE or MERGE request can give a version-controlled collection a
   version-controlled internal member that has the same name as an
   existing non-version-controlled internal member.  In this case, the
   non-version-controlled internal member takes precedence and is said
   to "eclipse" the new versioned-controlled internal member.  If the
   non-version-controlled internal member is removed (e.g., by a DELETE
   or MOVE), the version-controlled internal member is exposed.

14.2 Collection Version Properties

   A collection version has all the properties of a version.  In
   addition, the version-controlled-collection feature introduces the
   following REQUIRED property for a collection version.

14.2.1 DAV:version-controlled-binding-set (protected)

   This property captures the name and version-history of each version-
   controlled internal member of a collection.

   <!ELEMENT version-controlled-binding-set
    (version-controlled-binding*)>
   <!ELEMENT version-controlled-binding
    (binding-name, version-history)>
   <!ELEMENT binding-name (#PCDATA)>
   PCDATA value: URL segment
   <!ELEMENT version-history (href)>

14.3 Additional OPTIONS Semantics

   If the server supports the version-controlled-collection feature, it
   MUST include "version-controlled-collection" as a field in the DAV
   response header from an OPTIONS request on any resource that supports
   any versioning properties, reports, or methods.

14.4 Additional DELETE Semantics

   Additional Preconditions:

      (DAV:cannot-modify-checked-in-parent): If the request-URL
      identifies a version-controlled resource, the DELETE MUST fail
      when the collection containing the version-controlled resource is
      a checked-in version-controlled collection, unless DAV:auto-
      version semantics will automatically check out the version-
      controlled collection.

Top      Up      ToC       Page 104 
14.5 Additional MKCOL Semantics

   Additional Preconditions:

      If the request creates a new resource that is automatically placed
      under version control, all preconditions for VERSION-CONTROL apply
      to the request.

   Additional Postconditions:

      If the new collection is automatically put under version control,
      all postconditions for VERSION-CONTROL apply to the request.

14.6 Additional COPY Semantics

   Additional Preconditions:

      (DAV:cannot-copy-collection-version): If the source of the request
      is a collection version, the request MUST fail.

14.7 Additional MOVE Semantics

   Additional Preconditions:

      (DAV:cannot-modify-checked-in-parent): If the source of the
      request is a version-controlled resource, the request MUST fail
      when the collection containing the source is a checked-in
      version-controlled collection, unless DAV:auto-version semantics
      will automatically check out that version-controlled collection.

      (DAV:cannot-modify-destination-checked-in-parent): If the source
      of the request is a version-controlled resource, the request MUST
      fail when the collection containing the destination is a checked-
      in version-controlled collection, unless DAV:auto-version
      semantics will automatically check out that version-controlled
      collection.

14.8 Additional VERSION-CONTROL Semantics

   Additional Preconditions:

      (DAV:cannot-modify-checked-in-parent): If the parent of the
      request-URL is a checked-in version-controlled collection, the
      request MUST fail unless DAV:auto-version semantics will
      automatically check out that version-controlled collection.

Top      Up      ToC       Page 105 
   Additional Postconditions:

      (DAV:new-version-controlled-collection): If the request body
      identified a collection version, the collection at the request-URL
      MUST contain a version-controlled internal member for each
      DAV:version-controlled-binding specified in the DAV:version-
      controlled-binding-set of the collection version, where the name
      and DAV:version-history of the internal member MUST be the
      DAV:binding-name and the DAV:version-history specified by the
      DAV:version-controlled-binding.  If the internal member is a
      member of a workspace, and there is another member of the
      workspace for the same version history, those two members MUST
      identify the same version-controlled resource; otherwise, a
      VERSION-CONTROL request with a server selected version of the
      version history MUST have been applied to the URL for that
      internal member.

14.9 Additional CHECKOUT Semantics

   Additional Postconditions:

      (DAV:initialize-version-history-bindings): If the request has been
      applied to a collection version, the new working collection MUST
      be initialized to contain a binding to each of the history
      resources identified in the DAV:version-controlled-binding-set of
      that collection version.

14.10 Additional CHECKIN Semantics

   Additional Postconditions:

      (DAV:initialize-version-controlled-bindings): If the request-URL
      identified a version-controlled collection, then the DAV:version-
      controlled-binding-set of the new collection version MUST contain
      a DAV:version-controlled-binding that identifies the binding name
      and version history for each version-controlled binding of the
      version- controlled collection.

      (DAV:version-control-working-collection-members): If the request-
      URL identified a working collection, a VERSION-CONTROL request
      MUST have been automatically applied to every non-version-
      controlled member of the working collection, and each non-
      version-controlled member MUST have been replaced by its newly
      created version history.  If a working collection member was a
      non-version-controlled collection, every member of the non-
      version-controlled collection MUST have been placed under version

Top      Up      ToC       Page 106 
      control before the non-version-controlled collection was placed
      under version control.  The DAV:version-controlled-binding-set of
      the new collection version MUST contain a DAV:version-controlled-
      binding that identifies the binding name and the version history
      URL for each member of the working collection.

14.11 Additional UPDATE and MERGE Semantics

   Additional Postconditions:

      (DAV:update-version-controlled-collection-members): If the request
      modified the DAV:checked-in version of a version-controlled
      collection, then the version-controlled members of that version-
      controlled collection MUST have been updated.  In particular:

      -  A version-controlled internal member MUST have been deleted if
         its version history is not identified by the DAV:version-
         controlled-binding-set of the new DAV:checked-in version.
      -  A version-controlled internal member for a given version
         history MUST have been renamed if its binding name differs from
         the DAV:binding-name for that version history in the
         DAV:version-controlled-binding-set of the new DAV:checked-in
         version.
      -  A new version-controlled internal member MUST have been created
         when a version history is identified by the DAV:version-
         controlled-binding-set of the DAV:checked-in version, but there
         was no member of the version-controlled collection for that
         version history.  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.  If no version is specified for
         that version history by the request, the version selected is
         server defined.

15 Internationalization Considerations

   This specification has been designed to be compliant with the IETF
   Policy on Character Sets and Languages [RFC2277].  Specifically,
   where human-readable strings exist in the protocol, either their
   charset is explicitly stated, or XML mechanisms are used to specify
   the charset used.  Additionally, these human-readable strings all
   have the ability to express the natural language of the string.

Top      Up      ToC       Page 107 
   Most of the human-readable strings in this protocol appear in
   properties, such as DAV:creator-displayname.  As defined by RFC 2518,
   properties have their values marshaled as XML.  XML has explicit
   provisions for character set tagging and encoding, and requires that
   XML processors read XML elements encoded, at minimum, using the UTF-8
   [RFC2279] encoding of the ISO 10646 multilingual plane.  The charset
   parameter of the Content-Type header, together with the XML
   "encoding" attribute, provide charset identification information for
   MIME and XML processors.  Proper use of the charset header with XML
   is described in RFC 3023.  XML also provides a language tagging
   capability for specifying the language of the contents of a
   particular XML element.  XML uses either IANA registered language
   tags (see RFC 3066) or ISO 639 language tags in the "xml:lang"
   attribute of an XML element to identify the language of its content
   and attributes.

   DeltaV applications, since they build upon WebDAV, are subject to the
   internationalization requirements specified in RFC 2518, Section 16.
   In brief, these requirements mandate the use of XML character set
   tagging, character set encoding, and language tagging capabilities.
   Additionally, they strongly recommend reading RFC 3023 for
   instruction on the use of MIME media types for XML transport and the
   use of the charset header.

   Within this specification, a label is a human-readable string that is
   marshaled in the Label header and as XML in request entity bodies.
   When used in the Label header, the value of the label is URL-escaped
   and encoded using UTF-8.

16 Security Considerations

   All of the security considerations of WebDAV discussed in RFC 2518,
   Section 17 also apply to WebDAV versioning.  Some aspects of the
   versioning protocol help address security risks introduced by WebDAV,
   but other aspects can increase these security risks.  These issues
   are detailed below.

16.1 Auditing and Traceability

   WebDAV increases the ease with which a remote client can modify
   resources on a web site, but this also increases the risk of
   important information being overwritten and lost, either through user
   error or user maliciousness.  The use of WebDAV versioning can help
   address this problem by guaranteeing that previous information is
   saved in the form of immutable versions, and therefore is easily
   available for retrieval or restoration.  In addition, the version
   history provides a log of when changes were made, and by whom.  When
   requests are appropriately authenticated, the history mechanism

Top      Up      ToC       Page 108 
   provides a clear audit trail for changes to web resources.  This can
   often significantly improve the ability to identify the source of the
   security problem, and thereby help guard against it in the future.

16.2 Increased Need for Access Control

   WebDAV versioning provides a variety of links between related pieces
   of information.  This can increase the risk that authentication or
   authorization errors allow a client to locate sensitive information.
   For example, if version history is not appropriately protected by
   access control, a client can use the version history of a public
   resource to identify later versions of that resource that the user
   intended to keep private.  This increases the need for reliable
   authentication and accurate authorization.

   A WebDAV versioning client should be designed to handle a mixture of
   200 (OK) and 403 (Forbidden) responses on attempts to access the
   properties and reports that are supported by a resource.  For
   example, a particular user may be authorized to access the content
   and dead properties of a version-controlled resource, but not be
   authorized to access the DAV:checked-in, DAV:checked-out, or
   DAV:version-history properties of that resource.

16.3 Security Through Obscurity

   While it is acknowledged that "obscurity" is not an effective means
   of security, it is often a good technique to keep honest people
   honest.  Within this protocol, version URLs, version history URLs,
   and working resource URLs are generated by the server and can be
   properly obfuscated so as not to draw attention to them.  For
   example, a version of "http://foobar.com/reviews/salaries.html" might
   be assigned a URL such as "http://foobar.com/repo/4934943".

16.4 Denial of Service

   The auto-versioning mechanism provided by WebDAV can result in a
   large number of resources being created on the server, since each
   update to a resource could potentially result in the creation of a
   new version resource.  This increases the risk of a denial of service
   attack that exhausts the storage capability of a server.  This risk
   is especially significant because it can be an unintentional result
   of something like an aggressive auto-save feature provided by an
   editing client.  A server can decrease this risk by using delta
   storage techniques to minimize the cost of additional versions, and
   by limiting auto-versioning to a locking client, and thereby
   decreasing the number of inadvertent version creations.

Top      Up      ToC       Page 109 
17 IANA Considerations

   This document uses the namespace defined by RFC 2518 for XML
   elements.  All other IANA considerations from RFC 2518 are also
   applicable to WebDAV Versioning.

18 Intellectual Property

   The following notice is copied from RFC 2026, Section 10.4, and
   describes the position of the IETF concerning intellectual property
   claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   procedures of the IETF with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

19 Acknowledgements

   This protocol is the collaborative product of the authors and the
   rest of the DeltaV design team: Boris Bokowski, Bruce Cragun
   (Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa
   Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale
   (Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI),
   Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric
   Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta
   (Rational).  We would like to acknowledge the foundation laid for us
   by the authors of the WebDAV and HTTP protocols upon which this
   protocol is layered, and the invaluable feedback from the WebDAV and
   DeltaV working groups.

Top      Up      ToC       Page 110 
20 References

   [ISO639]  ISO, "Code for the representation of names of languages",
             ISO 639:1988, 1998.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
             Languages", BCP 18, RFC 2277, January 1998.

   [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
             RFC 2279, January 1998.

   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

   [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
             Jensen, "HTTP Extensions for Distributed Authoring -
             WEBDAV", RFC 2518, February 1999.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
             L., Leach, P. and T.Berners-Lee, "Hypertext Transfer
             Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
             RFC 3023, January 2001.

   [RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
             BCP 47, RFC 3066, January 2001.

Top      Up      ToC       Page 111 
Appendix A - Resource Classification

   This document introduces several different kinds of versioning
   resources, such as version-controlled resources, versions, checked-
   out resources, and version history resources.  As clients discover
   resources on a server, they may find it useful to classify those
   resources (for example, to make UI decisions on choice of icon and
   menu options).

   Clients should classify a resource by examining the values of the
   DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live-
   property-set (see Section 3.1.4) properties of that resource.

   The following list shows the supported live properties and methods
   for each kind of versioning resource.  Where an optional feature
   introduces a new kind of versioning resource, that feature is noted
   in parentheses following the name of that kind of versioning
   resource.  If a live property or method is optional for a kind of
   versioning resource, the feature that introduces that live property
   or method is noted in parentheses following the live property or
   method name.

A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)

   Supported methods:

   -  PUT [RFC2616]
   -  MKCOL [RFC2518]
   -  MKACTIVITY (activity)
   -  VERSION-CONTROL (workspace)
   -  MKWORKSPACE (workspace)

A.2 DeltaV-Compliant Resource

   Supported live properties:

   -  DAV:comment
   -  DAV:creator-displayname
   -  DAV:supported-method-set
   -  DAV:supported-live-property-set
   -  DAV:supported-report-set
   -  all properties defined in WebDAV [RFC2518].

Top      Up      ToC       Page 112 
   Supported methods:

   -  REPORT
   -  all methods defined in WebDAV [RFC2518]
   -  all methods defined in HTTP/1.1 [RFC2616].

A.3 DeltaV-Compliant Collection

   Supported live properties:

   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  BASELINE-CONTROL (baseline)
   -  all DeltaV-compliant resource methods.

A.4 Versionable Resource

   Supported live properties:

   -  DAV:workspace (workspace)
   -  DAV:version-controlled-configuration (baseline)
   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  VERSION-CONTROL
   -  all DeltaV-compliant resource methods.

A.5 Version-Controlled Resource

   Supported live properties:

   -  DAV:auto-version
   -  DAV:version-history  (version-history)
   -  DAV:workspace (workspace)
   -  DAV:version-controlled-configuration (baseline)
   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  VERSION-CONTROL
   -  MERGE (merge)
   -  all DeltaV-compliant resource methods.

Top      Up      ToC       Page 113 
A.6 Version

   Supported live properties:

   -  DAV:predecessor-set
   -  DAV:successor-set
   -  DAV:checkout-set
   -  DAV:version-name
   -  DAV:checkout-fork (in-place-checkout or working resource)
   -  DAV:checkin-fork (in-place-checkout or working resource)
   -  DAV:version-history  (version-history)
   -  DAV:label-name-set (label)
   -  DAV:activity-set (activity)
   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  LABEL (label)
   -  CHECKOUT (working-resource)
   -  all DeltaV-compliant resource methods.

A.7 Checked-In Version-Controlled Resource

   Supported live properties:

   -  DAV:checked-in
   -  all version-controlled resource properties.

   Supported methods:

   -  CHECKOUT (checkout-in-place)
   -  UPDATE (update)
   -  all version-controlled resource methods.

A.8 Checked-Out Resource

   Supported live properties:

   -  DAV:checked-out
   -  DAV:predecessor-set
   -  DAV:checkout-fork (in-place-checkout or working resource)
   -  DAV:checkin-fork (in-place-checkout or working resource)
   -  DAV:merge-set (merge)
   -  DAV:auto-merge-set (merge)
   -  DAV:unreserved (activity)
   -  DAV:activity-set (activity)

Top      Up      ToC       Page 114 
   Supported methods:

   -  CHECKIN (checkout-in-place or working-resource)
   -  all DeltaV-compliant resource methods.

A.9 Checked-Out Version-Controlled Resource (checkout-in-place)

   Supported live properties:

   -  all version-controlled resource properties.
   -  all checked-out resource properties.

   Supported methods:

   -  UNCHECKOUT
   -  all version-controlled resource methods.
   -  all checked-out resource methods.

A.10 Working Resource (working-resource)

   Supported live properties:

   -  all DeltaV-compliant resource properties
   -  all checked-out resource properties
   -  DAV:auto-update.

   Supported methods:

   -  all checked-out resource methods.

A.11 Version History (version-history)

   Supported live properties:

   -  DAV:version-set
   -  DAV:root-version
   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  all DeltaV-compliant resource methods.

Top      Up      ToC       Page 115 
A.12 Workspace (workspace)

   Supported live properties:

   -  DAV:workspace-checkout-set
   -  DAV:baseline-controlled-collection-set (baseline)
   -  DAV:current-activity-set (activity)
   -  all DeltaV-compliant collection properties.

   Supported methods:

   -  all DeltaV-compliant collection methods.

A.13 Activity (activity)

   Supported live properties:

   -  DAV:activity-version-set
   -  DAV:activity-checkout-set
   -  DAV:subactivity-set
   -  DAV:current-workspace-set
   -  all DeltaV-compliant resource properties.

   Supported methods:

   -  all DeltaV-compliant resource methods.

A.14 Version-Controlled Collection (version-controlled-collection)

   Supported live properties:

   -  DAV:eclipsed-set
   -  all version-controlled resource properties.

   Supported methods:

   -  all version-controlled resource methods.

A.15 Collection Version (version-controlled-collection)

   Supported live properties:

   -  DAV:version-controlled-binding-set
   -  all version properties.

   Supported methods:

   -  all version methods.

Top      Up      ToC       Page 116 
A.16 Version-Controlled Configuration (baseline)

   Supported live properties:

   -  DAV:baseline-controlled-collection
   -  all version-controlled resource properties.

   Supported methods:

   -  all version-controlled resource methods.

A.17 Baseline (baseline)

   Supported live properties:

   -  DAV:baseline-collection
   -  DAV:subbaseline-set
   -  all version properties.

   Supported methods:

   -  all version methods.

A.18 Checked-Out Version-Controlled Configuration (baseline)

   Supported live properties:

   -  DAV:subbaseline-set
   -  all version-controlled configuration properties.

   Supported methods:

   -  all version-controlled configuration methods.

Top      Up      ToC       Page 117 
Authors' Addresses

   Geoffrey Clemm
   Rational Software
   20 Maguire Road, Lexington, MA 02421

   EMail: geoffrey.clemm@rational.com


   Jim Amsden
   IBM
   3039 Cornwallis, Research Triangle Park, NC 27709

   EMail: jamsden@us.ibm.com


   Tim Ellison
   IBM
   Hursley Park, Winchester, UK S021 2JN

   EMail: tim_ellison@uk.ibm.com


   Christopher Kaler
   Microsoft
   One Microsoft Way, Redmond, WA 90852

   EMail: ckaler@microsoft.com


   Jim Whitehead
   UC Santa Cruz, Dept. of Computer Science
   1156 High Street, Santa Cruz, CA 95064

   EMail: ejw@cse.ucsc.edu

Top      Up      ToC       Page 118 
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.