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
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
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*)>
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
A server MAY reject attempts to modify the DAV:subactivity-set of an
<!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
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
<!ELEMENT activity-set (href*)>
13.3 Additional Checked-Out Resource Properties
The activity feature introduces the following REQUIRED properties for
a checked-out resource.
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
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
This property of a checked-out resource determines the DAV:activity-
set property of the version that results from checking in this
13.4 Additional Workspace Properties
The activity feature introduces the following REQUIRED property for a
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.
If a request body is included, it MUST be a DAV:mkactivity XML
<!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.
(DAV:resource-must-be-null): A resource MUST NOT exist at the
(DAV:activity-location-ok): The request-URL MUST identify a
location where an activity can be created.
(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
MKACTIVITY /act/test-23 HTTP/1.1
HTTP/1.1 201 Created
In this example, a new activity is created at
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.
The request body MUST be a DAV:latest-activity-version XML
<!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.
(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.
If an XML request body is included, it MUST be a DAV:options XML
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
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
<!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
(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
(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
(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-
<!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>
(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.
(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
(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
CHECKOUT /ws/public/foo.html HTTP/1.1
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
HTTP/1.1 200 OK
In this example, the CHECKOUT is being performed in the
13.11 Additional CHECKIN Semantics
(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.
(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.
<!ELEMENT checkin-activity EMPTY>
(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
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
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-
version-controlled bindings are not under version control, and
therefore can be added or deleted without checking out the version-
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-
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
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 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
(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-
14.5 Additional MKCOL Semantics
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
If the new collection is automatically put under version control,
all postconditions for VERSION-CONTROL apply to the request.
14.6 Additional COPY Semantics
(DAV:cannot-copy-collection-version): If the source of the request
is a collection version, the request MUST fail.
14.7 Additional MOVE Semantics
(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
14.8 Additional VERSION-CONTROL Semantics
(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.
(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
14.9 Additional CHECKOUT Semantics
(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
(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
(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
- 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
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
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
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.
[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,
[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
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
A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)
- PUT [RFC2616]
- MKCOL [RFC2518]
- MKACTIVITY (activity)
- VERSION-CONTROL (workspace)
- MKWORKSPACE (workspace)
A.2 DeltaV-Compliant Resource
Supported live properties:
- all properties defined in WebDAV [RFC2518].
20 Maguire Road, Lexington, MA 02421
3039 Cornwallis, Research Triangle Park, NC 27709
Hursley Park, Winchester, UK S021 2JN
One Microsoft Way, Redmond, WA 90852
UC Santa Cruz, Dept. of Computer Science
1156 High Street, Santa Cruz, CA 95064
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
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.
Funding for the RFC Editor function is currently provided by the