RFC 3253
Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
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.
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
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.
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: boolean13.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.
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.
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.
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.
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.
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.
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.
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-
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-
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
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.
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.
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
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.
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
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.
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.
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.
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].
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.
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)
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.
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.
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.
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
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.