Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3253

Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

Pages: 118
Proposed Standard
Errata
Part 4 of 4 – Pages 90 to 118
First   Prev   None

Top   ToC   RFC3253 - Page 90   prevText

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