As per Relevance of the word addition, we have this rfc below:
Network Working Group G.
Request for Comments: 3253 Rational
Category: Standards Track J.
T.
C.
J.
U.C. Santa
March 2002
Versioning Extensions to
(Web Distributed Authoring and Versioning
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document specifies a set of methods, headers, and resource
that define the WebDAV (Web Distributed Authoring and Versioning
versioning extensions to the HTTP/1.1 protocol. WebDAV
will minimize the complexity of clients that are capable
interoperating with a variety of versioning repository managers,
facilitate widespread deployment of applications capable of
the WebDAV Versioning services. WebDAV versioning includes
versioning for versioning-unaware clients, version
management, workspace management, baseline management,
management, and URL namespace versioning
Table of
1 Introduction.................................................... 6
1.1 Relationship to WebDAV........................................ 7
1.2 Notational Conventions........................................ 8
1.3 Terms......................................................... 8
1.4 Property Values............................................... 11
1.4.1 Initial Property Value..................................... 11
Clemm, et al. Standards Track [Page 1]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.4.2 Protected Property Value................................... 12
1.4.3 Computed Property Value.................................... 12
1.4.4 Boolean Property Value..................................... 12
1.4.5 DAV:href Property Value.................................... 12
1.5 DAV Namespace XML Elements.................................... 12
1.6 Method Preconditions and Postconditions....................... 12
1.6.1 Example - CHECKOUT request................................. 13
1.7 Clarification of COPY Semantics with Overwrite:T.............. 13
1.8 Versioning Methods and Write Locks............................ 14
2 Basic Versioning Features....................................... 14
2.1 Basic Versioning Packages..................................... 14
2.2 Basic Versioning Semantics.................................... 16
2.2.1 Creating a Version-Controlled Resource..................... 16
2.2.2 Modifying a Version-Controlled Resource.................... 17
2.2.3 Reporting.................................................. 19
3 Version-Control Feature......................................... 20
3.1 Additional Resource Properties................................ 20
3.1.1 DAV:comment................................................ 20
3.1.2 DAV:creator-displayname.................................... 20
3.1.3 DAV:supported-method-set (protected)....................... 20
3.1.4 DAV:supported-live-property-set (protected)................ 21
3.1.5 DAV:supported-report-set (protected)....................... 21
3.2 Version-Controlled Resource Properties........................ 21
3.2.1 DAV:checked-in (protected)................................. 21
3.2.2 DAV:auto-version........................................... 22
3.3 Checked-Out Resource Properties............................... 22
3.3.1 DAV:checked-out (protected)................................ 23
3.3.2 DAV:predecessor-set........................................ 23
3.4 Version Properties............................................ 23
3.4.1 DAV:predecessor-set (protected)............................ 23
3.4.2 DAV:successor-set (computed)............................... 23
3.4.3 DAV:checkout-set (computed)................................ 23
3.4.4 DAV:version-name (protected)............................... 24
3.5 VERSION-CONTROL Method........................................ 24
3.5.1 Example - VERSION-CONTROL.................................. 25
3.6 REPORT Method................................................. 25
3.7 DAV:version-tree Report....................................... 26
3.7.1 Example - DAV:version-tree Report.......................... 27
3.8 DAV:expand-property Report.................................... 29
3.8.1 Example - DAV:expand-property.............................. 30
3.9 Additional OPTIONS Semantics.................................. 31
3.10 Additional PUT Semantics..................................... 31
3.11 Additional PROPFIND Semantics................................ 32
3.12 Additional PROPPATCH Semantics............................... 33
3.13 Additional DELETE Semantics.................................. 33
3.14 Additional COPY Semantics.................................... 34
3.15 Additional MOVE Semantics.................................... 34
3.16 Additional UNLOCK Semantics.................................. 35
Clemm, et al. Standards Track [Page 2]
RFC 3253 Versioning Extensions to WebDAV March 2002
4 Checkout-In-Place Feature....................................... 35
4.1 Additional Version Properties................................. 35
4.1.1 DAV:checkout-fork.......................................... 36
4.1.2 DAV:checkin-fork........................................... 36
4.2 Checked-Out Resource Properties............................... 36
4.2.1 DAV:checkout-fork.......................................... 36
4.2.2 DAV:checkin-fork........................................... 37
4.3 CHECKOUT Method............................................... 37
4.3.1 Example - CHECKOUT......................................... 38
4.4 CHECKIN Method................................................ 38
4.4.1 Example - CHECKIN.......................................... 40
4.5 UNCHECKOUT Method............................................. 40
4.5.1 Example - UNCHECKOUT....................................... 41
4.6 Additional OPTIONS Semantics.................................. 42
5 Version-History Feature......................................... 42
5.1 Version History Properties.................................... 42
5.1.1 DAV:version-set (protected)................................ 42
5.1.2 DAV:root-version (computed)................................ 42
5.2 Additional Version-Controlled Resource Properties............. 42
5.2.1 DAV:version-history (computed)............................. 43
5.3 Additional Version Properties................................. 43
5.3.1 DAV:version-history (computed)............................. 43
5.4 DAV:locate-by-history Report.................................. 43
5.4.1 Example - DAV:locate-by-history Report..................... 44
5.5 Additional OPTIONS Semantics.................................. 45
5.6 Additional DELETE Semantics................................... 46
5.7 Additional COPY Semantics..................................... 46
5.8 Additional MOVE Semantics..................................... 46
5.9 Additional VERSION-CONTROL Semantics.......................... 46
5.10 Additional CHECKIN Semantics................................. 47
6 Workspace Feature............................................... 47
6.1 Workspace Properties.......................................... 48
6.1.1 DAV:workspace-checkout-set (computed)...................... 48
6.2 Additional Resource Properties................................ 48
6.2.1 DAV:workspace (protected).................................. 48
6.3 MKWORKSPACE Method............................................ 48
6.3.1 Example - MKWORKSPACE...................................... 49
6.4 Additional OPTIONS Semantics.................................. 49
6.4.1 Example - OPTIONS.......................................... 51
6.5 Additional DELETE Semantics................................... 51
6.6 Additional MOVE Semantics..................................... 52
6.7 Additional VERSION-CONTROL Semantics.......................... 52
6.7.1 Example - VERSION-CONTROL.................................. 53
7 Update Feature.................................................. 53
7.1 UPDATE Method................................................. 53
7.1.1 Example - UPDATE........................................... 55
7.2 Additional OPTIONS Semantics.................................. 55
8 Label Feature................................................... 56
Clemm, et al. Standards Track [Page 3]
RFC 3253 Versioning Extensions to WebDAV March 2002
8.1 Additional Version Properties................................. 56
8.1.1 DAV:label-name-set (protected)............................. 56
8.2 LABEL Method.................................................. 56
8.2.1 Example - Setting a label.................................. 58
8.3 Label Header.................................................. 58
8.4 Additional OPTIONS Semantics.................................. 59
8.5 Additional GET Semantics...................................... 59
8.6 Additional PROPFIND Semantics................................. 59
8.7 Additional COPY Semantics..................................... 60
8.8 Additional CHECKOUT Semantics................................. 60
8.9 Additional UPDATE Semantics................................... 61
9 Working-Resource Feature........................................ 62
9.1 Additional Version Properties................................. 62
9.1.1 DAV:checkout-fork.......................................... 62
9.1.2 DAV:checkin-fork........................................... 63
9.2 Working Resource Properties................................... 63
9.2.1 DAV:auto-update (protected)................................ 63
9.2.2 DAV:checkout-fork.......................................... 63
9.2.3 DAV:checkin-fork........................................... 63
9.3 CHECKOUT Method (applied to a version)........................ 63
9.3.1 Example - CHECKOUT of a version............................ 65
9.4 CHECKIN Method (applied to a working resource)................ 65
9.4.1 Example - CHECKIN of a working resource.................... 66
9.5 Additional OPTIONS Semantics.................................. 67
9.6 Additional COPY Semantics..................................... 67
9.7 Additional MOVE Semantics..................................... 67
10 Advanced Versioning Features.................................. 67
10.1 Advanced Versioning Packages................................. 68
10.2 Advanced Versioning Terms.................................... 68
11 MERGE Feature................................................. 70
11.1 Additional Checked-Out Resource Properties................... 70
11.1.1 DAV:merge-set............................................. 70
11.1.2 DAV:auto-merge-set........................................ 71
11.2 MERGE Method................................................. 71
11.2.1 Example - MERGE........................................... 74
11.3 DAV:merge-preview Report..................................... 75
11.3.1 Example - DAV:merge-preview Report........................ 76
11.4 Additional OPTIONS Semantics................................. 77
11.5 Additional DELETE Semantics.................................. 77
11.6 Additional CHECKIN Semantics................................. 77
12 Baseline Feature.............................................. 77
12.1 Version-Controlled Configuration Properties.................. 78
12.1.1 DAV:baseline-controlled-collection (protected)............ 78
12.2 Checked-Out Configuration Properties......................... 78
12.2.1 DAV:subbaseline-set....................................... 78
12.3 Baseline Properties.......................................... 78
12.3.1 DAV:baseline-collection (protected)....................... 79
12.3.2 DAV:subbaseline-set (protected)........................... 79
Clemm, et al. Standards Track [Page 4]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.4 Additional Resource Properties............................... 79
12.4.1 DAV:version-controlled-configuration (computed)........... 79
12.5 Additional Workspace Properties.............................. 80
12.5.1 DAV:baseline-controlled-collection-set (computed)......... 80
12.6 BASELINE-CONTROL Method...................................... 80
12.6.1 Example - BASELINE-CONTROL................................ 82
12.7 DAV:compare-baseline Report.................................. 84
12.7.1 Example - DAV:compare-baseline Report..................... 85
12.8 Additional OPTIONS Semantics................................. 86
12.9 Additional MKCOL Semantics................................... 86
12.10 Additional COPY Semantics................................... 86
12.11 Additional CHECKOUT Semantics............................... 86
12.12 Additional CHECKIN Semantics................................ 86
12.13 Additional UPDATE Semantics................................. 87
12.14 Additional MERGE Semantics.................................. 89
13 Activity Feature.............................................. 90
13.1 Activity Properties.......................................... 91
13.1.1 DAV:activity-version-set (computed)....................... 91
13.1.2 DAV:activity-checkout-set (computed)...................... 92
13.1.3 DAV:subactivity-set....................................... 92
13.1.4 DAV:current-workspace-set (computed)...................... 92
13.2 Additional Version Properties................................ 92
13.2.1 DAV:activity-set.......................................... 93
13.3 Additional Checked-Out Resource Properties................... 93
13.3.1 DAV:unreserved............................................ 93
13.3.2 DAV:activity-set.......................................... 93
13.4 Additional Workspace Properties.............................. 93
13.4.1 DAV:current-activity-set.................................. 94
13.5 MKACTIVITY Method............................................ 94
13.5.1 Example - MKACTIVITY...................................... 95
13.6 DAV:latest-activity-version Report........................... 95
13.7 Additional OPTIONS Semantics................................. 96
13.8 Additional DELETE Semantics.................................. 96
13.9 Additional MOVE Semantics.................................... 97
13.10 Additional CHECKOUT Semantics............................... 97
13.10.1 Example - CHECKOUT with an activity...................... 98
13.11 Additional CHECKIN Semantics................................ 99
13.12 Additional MERGE Semantics.................................. 99
14 Version-Controlled-Collection Feature.........................100
14.1 Version-Controlled Collection Properties.....................102
14.1.1 DAV:eclipsed-set (computed)...............................102
14.2 Collection Version Properties................................103
14.2.1 DAV:version-controlled-binding-set (protected)............103
14.3 Additional OPTIONS Semantics.................................103
14.4 Additional DELETE Semantics..................................103
14.5 Additional MKCOL Semantics...................................104
14.6 Additional COPY Semantics....................................104
14.7 Additional MOVE Semantics....................................104
Clemm, et al. Standards Track [Page 5]
RFC 3253 Versioning Extensions to WebDAV March 2002
14.8 Additional VERSION-CONTROL Semantics.........................104
14.9 Additional CHECKOUT Semantics................................105
14.10 Additional CHECKIN Semantics................................105
14.11 Additional UPDATE and MERGE Semantics.......................106
15 Internationalization Considerations...........................106
16 Security Considerations.......................................107
16.1 Auditing and Traceability....................................107
16.2 Increased Need for Access Control............................108
16.3 Security Through Obscurity...................................108
16.4 Denial of Service............................................108
17 IANA Considerations...........................................109
18 Intellectual Property.........................................109
19 Acknowledgements..............................................109
20 References....................................................110
Appendix A - Resource Classification..............................111
A.1 DeltaV-Compliant Unmapped URL.................................111
A.2 DeltaV-Compliant Resource.....................................111
A.3 DeltaV-Compliant Collection...................................112
A.4 Versionable Resource..........................................112
A.5 Version-Controlled Resource...................................112
A.6 Version.......................................................113
A.7 Checked-In Version-Controlled Resource........................113
A.8 Checked-Out Resource..........................................113
A.9 Checked-Out Version-Controlled Resource.......................114
A.10 Working Resource.............................................114
A.11 Version History..............................................114
A.12 Workspace....................................................115
A.13 Activity.....................................................115
A.14 Version-Controlled Collection................................115
A.15 Collection Version...........................................115
A.16 Version-Controlled Configuration.............................116
A.17 Baseline.....................................................116
A.18 Checked-Out Version-Controlled Configuration.................116
Authors' Addresses................................................117
Full Copyright Statement..........................................118
1
This document specifies a set of methods, headers, and
that define the WebDAV (Web Distributed Authoring and Versioning
versioning extensions to the HTTP/1.1 protocol. Versioning
concerned with tracking and accessing the history of important
of a web resource, such as a standalone web page. The benefits
versioning in the context of the worldwide web include
Clemm, et al. Standards Track [Page 6]
RFC 3253 Versioning Extensions to WebDAV March 2002
- A resource has an explicit history and a persistent
across the various states it has had during the course of
history. It allows browsing through past and alternative
of a resource. Frequently the modification and authorship
of a resource is critical information in itself
- Resource states (versions) are given stable names that can
externally stored links for annotation and link server support
Both annotation and link servers frequently need to store
references to portions of resources that are not under
direct control. By providing stable states of resources,
control systems allow not only stable pointers into
resources, but also well defined methods to determine
relationships of those states of a resource
WebDAV Versioning defines both basic and advanced
functionality
Basic versioning allows users to
- Put a resource under version
- Determine whether a resource is under version
- Determine whether a resource update will automatically be
as a new
- Create and access distinct versions of a
Advanced versioning provides additional functionality for
development and configuration management of sets of web resources
This document will first define the properties and method
for the basic versioning features, and then define the
properties and method semantics for the advanced versioning features
An implementer that is only interested in basic versioning
skip the advanced versioning sections (Section 10 to Section 14).
1.1 Relationship to
To maximize interoperability and the use of existing
functionality, versioning support is designed as extensions to
WebDAV protocol [RFC2518], which itself is an extension to the
protocol [RFC2616]. All method marshalling and
defined by RFC 2518 and RFC 2616 continue to hold, to ensure
versioning unaware clients can interoperate successfully
versioning servers. Although the versioning extensions are
to be orthogonal to most aspects of the WebDAV and HTTP protocols,
clarification to RFC 2518 is required for effective
versioning. This clarification is described in Section 1.7.
Clemm, et al. Standards Track [Page 7]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.2 Notational
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
The term "protected" is placed in parentheses following
definition of a protected property (see Section 1.4.2).
The term "computed" is placed in parentheses following the
of a computed property (see Section 1.4.3).
When an XML element type in the "DAV:" namespace is referenced
this document outside of the context of an XML fragment, the
"DAV:" will be prefixed to the element type
When a method is defined in this document, a list of
and postconditions will be defined for that method. If the
of an existing method is being extended, a list of
preconditions and postconditions will be defined. A precondition
postcondition is prefixed by a parenthesized XML element type
identifies that precondition or postcondition (see Section 1.6).
1.3
This document uses the terms defined in RFC 2616, in RFC 2518, and
this section. Section 2.2 defines the semantic versioning
underlying this terminology
Version Control, Checked-In, Checked-
"Version control" is a set of constraints on how a resource can
updated. A resource under version control is either in
"checked-in" or "checked-out" state, and the version
constraints apply only while the resource is in the checked-
state
Versionable
A "versionable resource" is a resource that can be put
version control
Version-Controlled
When a versionable resource is put under version control,
becomes a "version-controlled resource". A version-
resource can be "checked out" to allow modification of its
or dead properties by standard HTTP and WebDAV methods
Clemm, et al. Standards Track [Page 8]
RFC 3253 Versioning Extensions to WebDAV March 2002
Checked-Out
A "checked-out resource" is a resource under version control
is in the checked-out state
Version
A "version resource", or simply "version", is a resource
contains a copy of a particular state (content and
properties) of a version-controlled resource. A version
created by "checking in" a checked-out resource. The
allocates a distinct new URL for each new version, and this
will never be used to identify any resource other than
version. The content and dead properties of a version
change
Version History
A "version history resource", or simply "version history", is
resource that contains all the versions of a particular version
controlled resource
Version
A "version name" is a string chosen by the server to
one version of a version history from the other versions of
version history. Versions from different version histories
have the same version name
Predecessor, Successor, Ancestor,
When a version-controlled resource is checked out and
subsequently checked in, the version that was checked out
a "predecessor" of the version created by the checkin. A
can specify multiple predecessors for a new version if the
version is logically a merge of those predecessors. When
version is connected to another version by traversing one or
predecessor relations, it is called an "ancestor" of that version
The inverse of the predecessor and ancestor relations are
"successor" and "descendant" relations. Therefore, if X is
predecessor of Y, then Y is a successor of X, and if X is
ancestor of Y, then Y is a descendant of X
Root Version
The "root version resource", or simply "root version", is
version in a version history that is an ancestor of every
version in that version history
Clemm, et al. Standards Track [Page 9]
RFC 3253 Versioning Extensions to WebDAV March 2002
Workspace
A "workspace resource", or simply "workspace", is a
that contains at most one version-controlled resource for a
version history (see Section 6).
Working
A "working resource" is a checked-out resource created by
server at a server-defined URL when a version (instead of
version-controlled resource) is checked out. Unlike a checked-
version-controlled resource, a working resource is deleted when
is checked in
Fork,
When a second successor is added to a version, this creates
"fork" in the version history. When a version is created
multiple predecessors, this creates a "merge" in the
history. A server may restrict the version history to be
(with no forks or merges), but an interoperable versioning
should be prepared to deal with both forks and merges in
version history
Clemm, et al. Standards Track [Page 10]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates several of the
definitions. Each box represents a version and each line between
boxes represents a predecessor/successor relationship. For example
it shows V3 is a predecessor of V5, V7 is a successor of V5, V1 is
ancestor of V4, and V7 is a descendant of V4. It also shows
there is a fork at version V2 and a merge at version V7.
History of foo.
+---+
Root Version -------> | | V
+---+ ^
| |
| |
+---+ |
Version Name ----> V2 | | |
+---+ |
/ \ |
/ \ |
+---+ +---+
| | V3 | | V
^ +---+ +---+
| | | |
Predecessor | | | |
+---+ +---+ |
| | V5 | | V6 |
+---+ +---+ |
Successor | \ / |
| \ / |
v +---+
| | V
+---+
A "label" is a name that can be used to select a version from
version history. A label can be assigned by either a client
the server. The same label can be used in different
histories
1.4 Property
1.4.1 Initial Property
Unless an initial value of a property of a given type is defined
this document, the initial value of a property of that type
implementation dependent
Clemm, et al. Standards Track [Page 11]
RFC 3253 Versioning Extensions to WebDAV March 2002
1.4.2 Protected Property
When a property of a specific kind of resource is "protected",
property value cannot be updated on that kind of resource except by
method explicitly defined as updating that specific property.
particular, a protected property cannot be updated with a
request. Note that a given property can be protected on one kind
resource, but not protected on another kind of resource
1.4.3 Computed Property
When a property is "computed", its value is defined in terms of
computation based on the content and other properties of
resource, or even of some other resource. When the semantics of
method is defined in this document, the effect of that method
non-computed properties will be specified; the effect of that
on computed properties will not be specified, but can be
from the computation defined for those properties. A
property is always a protected property
1.4.4 Boolean Property
Some properties take a Boolean value of either "false" or "true".
1.4.5 DAV:href Property
The DAV:href XML element is defined in RFC 2518, Section 12.3.
1.5 DAV Namespace XML Elements in Request and Response
Although WebDAV request and response bodies can be extended
arbitrary XML elements, which can be ignored by the
recipient, an XML element in the DAV namespace MUST NOT be used
the request or response body of a versioning method unless that
element is explicitly defined in an IETF RFC
1.6 Method Preconditions and
A "precondition" of a method describes the state of the server
must be true for that method to be performed. A "postcondition" of
method describes the state of the server that must be true after
method has been completed. If a method precondition or
for a request is not satisfied, the response status of the
MUST be either 403 (Forbidden) if the request should not be
because it will always fail, or 409 (Conflict) if it is expected
the user might be able to resolve the conflict and resubmit
request
Clemm, et al. Standards Track [Page 12]
RFC 3253 Versioning Extensions to WebDAV March 2002
In order to allow better client handling of 403 and 409 responses,
distinct XML element type is associated with each method
and postcondition of a request. When a particular precondition
not satisfied or a particular postcondition cannot be achieved,
appropriate XML element MUST be returned as the child of a top-
DAV:error element in the response body, unless otherwise
by the request. In a 207 Multi-Status response, the DAV:
element would appear in the appropriate DAV:
element
1.6.1 Example - CHECKOUT request with DAV:must-be-checked-in
>>
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.
>>
HTTP/1.1 409
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
In this example, the request to CHECKOUT /foo.html fails
/foo.html is not checked in
1.7 Clarification of COPY Semantics with Overwrite:
RFC 2518, Section 8.8.4 states
"If a resource exists at the destination and the Overwrite header
"T" then prior to performing the copy the server MUST perform
DELETE with "Depth: infinity" on the destination resource."
The purpose of this sentence is to ensure that following a COPY,
destination resources have the same content and dead properties
the corresponding resources identified by the request-URL (where
resource with a given name relative to the Destination
"corresponds" to a resource with the same name relative to
request-URL). If at the time of the request, there already is
resource at the destination that has the same resource type as
corresponding resource at the request-URL, that resource MUST NOT
deleted, but MUST be updated to have the content and dead
Clemm, et al. Standards Track [Page 13]
RFC 3253 Versioning Extensions to WebDAV March 2002
of its corresponding member. If a client wishes all resources at
destination to be deleted prior to the COPY, it MUST explicitly
a DELETE request
The difference between updating a resource and replacing a
with a new resource is especially important when resource history
being maintained (the former adds to an existing history, while
latter creates a new history). In addition, locking and
control constraints might allow you to update a resource, but
allow you to delete it and create a new one in its place
Note that this clarification does not apply to a MOVE request.
MOVE request with Overwrite:T MUST perform the DELETE
"Depth:infinity" on the destination resource prior to performing
MOVE
1.8 Versioning Methods and Write
If a write-locked resource has a non-computed property defined
this document, the property value MUST NOT be changed by a
unless the appropriate lock token is included in the request.
every method introduced in this document other than REPORT
at least one property defined by this document, every
method other than REPORT is affected by a write lock. In particular
the method MUST fail with a 423 (Locked) status if the resource
write-locked and the appropriate token is not specified in an
request header
2 Basic Versioning
Each basic versioning feature defines extensions to existing HTTP
WebDAV methods, as well as new resource types, live properties,
methods
2.1 Basic Versioning
A server MAY support any combination of versioning features
However, in order to minimize the complexity of a WebDAV
versioning client, a WebDAV basic versioning server SHOULD
one of the following three "packages" (feature sets):
- Core-Versioning Package: version-
- Basic-Server-Workspace Package: version-control, workspace
version-history,
- Basic-Client-Workspace Package: version-control, working
resource, update,
Clemm, et al. Standards Track [Page 14]
RFC 3253 Versioning Extensions to WebDAV March 2002
The core-versioning package supports linear versioning by
versioning-aware and versioning-unaware clients. A versioning-
client can use reports and properties to access previous versions
a version-controlled resource
The basic workspace packages support parallel development
version-controlled resources. Each client has its own
of the shared version-controlled resources, and can make changes
its configuration without disturbing that of another client
In the basic-server-workspace package, all persistent state
maintained on the server. Each client has its own workspace
allocated on the server, where each workspace identifies
configuration of the shared version-controlled resources.
client makes changes to its workspace, and can transfer changes
appropriate from one workspace to another. The server
package is appropriate for clients with no local persistent state,
for clients that wish to expose their working configurations to
clients
In the basic-client-workspace package, each client maintains in
persistent storage the state for its configuration of the
version-controlled resources. When a client is ready to make
changes visible to other clients, it allocates a set of "
resources" on the server, updates the content and dead properties
these working resources, and then uses the set of working
to update the version-controlled resources. The working
are used, instead of directly updating the version-
resources, so that sets of consistent updates can be prepared
parallel by multiple clients. Also, a working resource allows
client to prepare a single update that requires multiple
requests (e.g. updating both the content and dead properties of
resource requires both a PUT and a PROPPATCH). The client
package simplifies the server implementation by requiring each
to maintain its own namespace, but this requires that the
have local persistent state, and does not allow clients to
their working configurations to other clients
A server that supports both basic workspace packages
interoperate with all basic versioning clients
Clemm, et al. Standards Track [Page 15]
RFC 3253 Versioning Extensions to WebDAV March 2002
2.2 Basic Versioning
2.2.1 Creating a Version-Controlled
In order to track the history of the content and dead properties of
versionable resource, a user can put the resource under
control with a VERSION-CONTROL request. A VERSION-CONTROL
performs three distinct operations
1) It creates a new "version history resource". In basic versioning
a version history resource is not assigned a URL, and hence is
visible in the http scheme URL space. However, when the version
history feature (see Section 5) is supported, this changes,
each version history resource is assigned a new distinct
unique server-defined URL
2) It creates a new "version resource" and adds it to the new
history resource. The body and dead properties of the new
resource are a copy of those of the versionable resource
The server assigns the new version resource a new distinct
unique URL
3) It converts the versionable resource into a "version-
resource". The version-controlled resource continues to
identified by the same URL that identified it as a
resource. As part of this conversion, it adds a DAV:checked-
property, whose value contains the URL of the new
resource
Note that a versionable resource and a version-controlled
are not new types of resources (i.e. they introduce no
DAV:resourcetype), but rather they are any type of resource
supports the methods and live properties defined for them in
document, in addition to all the methods and live properties
by their DAV:resourcetype. For example, a collection (
DAV:resourcetype is DAV:collection) is a versionable resource if
supports the VERSION-CONTROL method, and is a version-
resource if it supports the version-controlled resource methods
live properties
In the following example, foo.html is a versionable resource that
put under version control. After the VERSION-CONTROL
succeeds, there are two additional resources: a new version
resource and a new version resource in that version history.
versionable resource is converted into a version-controlled resource
whose DAV:checked-in property identifies the new version resource
Clemm, et al. Standards Track [Page 16]
RFC 3253 Versioning Extensions to WebDAV March 2002
The content and dead properties of a resource are represented by
symbol appearing inside the box for that resource (e.g., "S1" in
following example).
===VERSION-CONTROL==>
| +----+
| version- | |
versionable | controlled +----+
resource | resource |
/foo.html | /foo.html |
|
+----+ | +----+ checked-in +----+
| S1 | | | S1 |----------->| S1 |
+----+ | +----+ +----+ /his/73/ver/1
Thus, whereas before the VERSION-CONTROL request there was only one
non-version-controlled resource, after VERSION-CONTROL there
three separate, distinct resources, each containing its own state
properties: the version-controlled resource, the version resource
and the version history resource. Since the version-
resource and the version resource are separate, distinct resources
when a method is applied to a version-controlled resource, it is
applied to that version-controlled resource, and is not applied
the version resource that is currently identified by
DAV:checked-in property of that version-controlled resource
Although the content and dead properties of a checked-in version
controlled resource are required to be the same as those of
current DAV:checked-in version, its live properties may differ.
implementation may optimize storage by retrieving the content
dead properties of a checked-in version-controlled resource from
current DAV:checked-in version rather than storing them in
version-controlled resource, but this is just an
optimization
Normally, a resource is placed under version control with an
VERSION-CONTROL request. A server MAY automatically place every
versionable resource under version control. In this case,
resulting state on the server MUST be the same as if the client
explicitly applied a VERSION-CONTROL request to the
resource
2.2.2 Modifying a Version-Controlled
In order to use methods like PUT and PROPPATCH to directly modify
content or dead properties of a version-controlled resource,
version-controlled resource must first be checked out. When
checked-out resource is checked in, a new version is created in
Clemm, et al. Standards Track [Page 17]
RFC 3253 Versioning Extensions to WebDAV March 2002
version history of that version-controlled resource. The
that was checked out is remembered as the predecessor of the
version
The DAV:auto-version property (see Sections 3.2.2) of a checked-
version-controlled resource determines how it responds to a
that attempts to modify its content or dead properties.
responses include
- Fail the request. The resource requires an explicit
request for it to be modified (see Sections 4 and 9.2.1).
- Automatically checkout the resource, perform the modification,
automatically checkin the resource. This ensures that every
of the resource is tracked by the server, but can result in
excessive number of versions being created
- Automatically checkout the resource, perform the modification,
then if the resource is not write-locked, automatically
the resource. If the resource is write-locked, it
checked-out until the write-lock is removed (either
through a subsequent UNLOCK request or implicitly through a time
out of the write-lock). This helps a locking client avoid
proliferation of versions, while still allowing a non-
client to update the resource
- Automatically checkout the resource, perform the modification,
then leave the resource checked out. If the resource is write
locked, it will be automatically checked in when the write-lock
removed, but an explicit CHECKIN operation (see Section 4.4)
required for a non-write-locked resource. This minimizes
number of new versions that will be created by a
unaware client, but only a versioning aware client can create
versions of a non-write-locked resource
- Fail the request unless the resource is write-locked. If it
write-locked, automatically checkout the resource and perform
modification. The resource is automatically checked in when
write-lock is removed. This minimizes the number of new
that will be created by a versioning unaware client, but
automatically checks out a resource that will not subsequently
automatically checked in
Clemm, et al. Standards Track [Page 18]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates the effect of the checkout/
process on a version-controlled resource and its version history
The symbol inside a box (S1, S2, S3) represents the current
and dead properties of the resource represented by that box.
symbol next to a box (V1, V2, V3) represents the URL for
resource
===checkout==> ===PUT==> ===checkin==>
/foo.html (version-controlled resource
+----+ | +----+ | +----+ | +----+
| S2 | | | S2 | | | S3 | | | S3 |
+----+ | +----+ | +----+ | +----+
Checked-In=V2|Checked-Out=V2|Checked-Out=V2|Checked-In=V
/his/73 (version history for /foo.html
+----+ | +----+ | +----+ | +----+
| S1 | V1 | | S1 | V1 | | S1 | V1 | | S1 | V
+----+ | +----+ | +----+ | +----+
| | | | | | |
| | | | | | |
+----+ | +----+ | +----+ | +----+
| S2 | V2 | | S2 | V2 | | S2 | V2 | | S2 | V
+----+ | +----+ | +----+ | +----+
| | | |
| | | |
| | | +----+
| | | | S3 | V
| | | +----+
Note that a version captures only a defined subset of the state of
resource. In particular, a version of a basic resource captures
content and dead properties, but not its live properties
2.2.3
Some versioning information about a resource requires that
be specified along with that request for information. Included
basic versioning is the required support for an extensible
mechanism, which includes a REPORT method as well as a live
for determining what reports are supported by a particular resource
The REPORT method is required by versioning, but it can be used
non-versioning WebDAV extensions
Clemm, et al. Standards Track [Page 19]
RFC 3253 Versioning Extensions to WebDAV March 2002
To allow a client to query the properties of all versions in
version history of a specified version-controlled resource,
versioning provides the DAV:version-tree report (see Section 3.7).
more powerful version history reporting mechanism is provided
applying the DAV:expand-property report (see Section 3.8) to
version history resource (see Section 5).
3 Version-Control
The version-control feature provides support for putting a
under version control, creating an associated version-
resource and version history resource as described in Section 2.2.1.
A server indicates that it supports the version-control feature
including the string "version-control" as a field in the DAV
in the response to an OPTIONS request. The version-control
MUST be supported if any other versioning feature is supported
3.1 Additional Resource
The version-control feature introduces the following
properties for any WebDAV resource
3.1.1 DAV:
This property is used to track a brief comment about a resource
is suitable for presentation to a user. The DAV:comment of a
can be used to indicate why that version was created
PCDATA value:
3.1.2 DAV:creator-
This property contains a description of the creator of the
that is suitable for presentation to a user. The DAV:creator
displayname of a version can be used to indicate who created
version
PCDATA value:
3.1.3 DAV:supported-method-set (protected
This property identifies the methods that are supported by
resource. A method is supported by a resource if there is some
of that resource for which an application of that method
Clemm, et al. Standards Track [Page 20]
RFC 3253 Versioning Extensions to WebDAV March 2002
successfully satisfy all postconditions of that method, including
additional postconditions added by the features supported by
resource
supported-method-set (supported-method*)>
supported-method ANY
supported-method name NMTOKEN #REQUIRED
name value: a method
3.1.4 DAV:supported-live-property-set (protected
This property identifies the live properties that are supported
the resource. A live property is supported by a resource if
property has the semantics defined for that property. The value
this property MUST identify all live properties defined by
document that are supported by the resource, and SHOULD identify
live properties that are supported by the resource
supported-live-property-set (supported-live-property*)>
supported-live-property name
ANY value: a property element
3.1.5 DAV:supported-report-set (protected
This property identifies the reports that are supported by
resource
supported-report-set (supported-report*)>
supported-report report
ANY value: a report element
3.2 Version-Controlled Resource
The version-control feature introduces the following
properties for a version-controlled resource
3.2.1 DAV:checked-in (protected
This property appears on a checked-in version-controlled resource
and identifies a version that has the same content and
properties as the version-controlled resource. This property
removed when the resource is checked out, and then added
(identifying a new version) when the resource is checked back in
Clemm, et al. Standards Track [Page 21]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.2.2 DAV:auto-
If the DAV:auto-version value is DAV:checkout-checkin, when
modification request (such as PUT/PROPPATCH) is applied to
checked-in version-controlled resource, the request is
preceded by a checkout and followed by a checkin operation
If the DAV:auto-version value is DAV:checkout-unlocked-checkin,
a modification request is applied to a checked-in version-
resource, the request is automatically preceded by a
operation. If the resource is not write-locked, the request
automatically followed by a checkin operation
If the DAV:auto-version value is DAV:checkout, when a
request is applied to a checked-in version-controlled resource,
request is automatically preceded by a checkout operation
If the DAV:auto-version value is DAV:locked-checkout, when
modification request is applied to a write-locked checked-
version-controlled resource, the request is automatically preceded
a checkout operation
If an update to a write-locked checked-in resource is
preceded by a checkout of that resource, the checkout is
with the write lock. When this write lock is removed (e.g. from
UNLOCK or a lock timeout), if the resource has not yet been
in, the removal of the write lock is automatically preceded by
checkin operation
A server MAY refuse to allow the value of the DAV:auto-
property to be modified, or MAY only support values from a subset
the valid values
| checkout | locked-checkout)? >
3.3 Checked-Out Resource
The version-control feature introduces the following
properties for a checked-out resource
Clemm, et al. Standards Track [Page 22]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.3.1 DAV:checked-out (protected
This property identifies the version that was identified by
DAV:checked-in property at the time the resource was checked out
This property is removed when the resource is checked in
3.3.2 DAV:predecessor-
This property determines the DAV:predecessor-set property of
version that results from checking in this resource
A server MAY reject attempts to modify the DAV:predecessor-set of
version-controlled resource
3.4 Version
The version-control feature introduces the following
properties for a version
3.4.1 DAV:predecessor-set (protected
This property identifies each predecessor of this version.
for the root version, which has no predecessors, each version has
least one predecessor
3.4.2 DAV:successor-set (computed
This property identifies each version whose DAV:predecessor-
identifies this version
3.4.3 DAV:checkout-set (computed
This property identifies each checked-out resource
DAV:checked-out property identifies this version
Clemm, et al. Standards Track [Page 23]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.4.4 DAV:version-name (protected
This property contains a server-defined string that is different
each version in a given version history. This string is intended
display for a user, unlike the URL of a version, which is
only used by a client and not displayed for a user
PCDATA value:
3.5 VERSION-CONTROL
A VERSION-CONTROL request can be used to create a version-
resource at the request-URL. It can be applied to a
resource or to a version-controlled resource
If the request-URL identifies a versionable resource, a new
history resource is created, a new version is created whose
and dead properties are copied from the versionable resource, and
resource is given a DAV:checked-in property that is initialized
identify this new version
If the request-URL identifies a version-controlled resource,
resource just remains under version-control. This allows a client
be unaware of whether or not a server automatically puts a
under version control when it is created
If a VERSION-CONTROL request fails, the server state preceding
request MUST be restored
Marshalling
If a request body is included, it MUST be a DAV:version-
XML element
If a response body for a successful request is included, it
be a DAV:version-control-response XML element. Note that
document does not define any elements for the VERSION-
response body, but the DAV:version-control-response element
defined to ensure interoperability between future extensions
do define elements for the VERSION-CONTROL response body
response ANY
Clemm, et al. Standards Track [Page 24]
RFC 3253 Versioning Extensions to WebDAV March 2002
Postconditions
(DAV:put-under-version-control): If the request-URL identified
versionable resource at the time of the request, the request
have created a new version history and MUST have created a
version resource in that version history. The resource MUST
a DAV:checked-in property that identifies the new version.
content, dead properties, and DAV:resourcetype of the new
MUST be the same as those of the resource. Note that
implementation can choose to locate the version history
version resources anywhere that it wishes. In particular,
could locate them on the same host and server as the version
controlled resource, on a different virtual host maintained by
same server, on the same host maintained by a different server,
on a different host maintained by a different server
(DAV:must-not-change-existing-checked-in-out): If the request-
identified a resource already under version control at the time
the request, the request MUST NOT change the DAV:checked-in
DAV:checked-out property of that version-controlled resource
3.5.1 Example - VERSION-
>>
VERSION-CONTROL /foo.html HTTP/1.1
Host: www.webdav.
Content-Length: 0
>>
HTTP/1.1 200
In this example, /foo.html is put under version control. A
version history is created for it, and a new version is created
has a copy of the content and dead properties of /foo.html.
DAV:checked-in property of /foo.html identifies this new version
3.6 REPORT
A REPORT request is an extensible mechanism for obtaining
about a resource. Unlike a resource property, which has a
value, the value of a report can depend on additional
specified in the REPORT request body and in the REPORT
headers
Clemm, et al. Standards Track [Page 25]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling
The body of a REPORT request specifies which report is
requested, as well as any additional information that will be
to customize the report
The request MAY include a Depth header. If no Depth header
included, Depth:0 is assumed
The response body for a successful request MUST contain
requested report
If a Depth request header is included, the response MUST be a 207
Multi-Status. The request MUST be applied separately to
collection itself and to all members of the collection
satisfy the Depth value. The DAV:prop element of a DAV:
for a given resource MUST contain the requested report for
resource
Preconditions
(DAV:supported-report): The specified report MUST be supported
the resource identified by the request-URL
Postconditions
(DAV:no-modification): The REPORT method MUST NOT have changed
content or dead properties of any resource
3.7 DAV:version-tree
The DAV:version-tree report describes the requested properties of
the versions in the version history of a version. If the report
requested for a version-controlled resource, it is redirected to
DAV:checked-in or DAV:checked-out version
The DAV:version-tree report MUST be supported by all
resources and all version-controlled resources
Marshalling
The request body MUST be a DAV:version-tree XML element
ANY value: a sequence of zero or more elements, with at most
DAV:prop element
prop: see RFC 2518, Section 12.11
Clemm, et al. Standards Track [Page 26]
RFC 3253 Versioning Extensions to WebDAV March 2002
The response body for a successful request MUST be
DAV:multistatus XML element
multistatus: see RFC 2518, Section 12.9
The response body for a successful DAV:version-tree REPORT
MUST contain a DAV:response element for each version in
version history of the version identified by the request-URL
3.7.1 Example - DAV:version-tree
The version history drawn below would produce the following
tree report
foo.html
+---+
| | V
+---+
/ \
/ \
+---+ +---+
| | V2 | | V2.1.1
+---+ +---+
>>
REPORT /foo.html HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
Clemm, et al. Standards Track [Page 27]
RFC 3253 Versioning Extensions to WebDAV March 2002
>>
HTTP/1.1 207 Multi-
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
response
http://repo.webdav.org/his/23/ver/V1
V1
Fred
http://repo.webdav.org/his/23/ver/V2
http://repo.webdav.org/his/23/ver/V2.1.1
HTTP/1.1 200 OK
response
response
http://repo.webdav.org/his/23/ver/V2
V2
Fred
HTTP/1.1 200 OK
response
response
http://repo.webdav.org/his/23/ver/V2.1.1
V2.1.1
Sally
HTTP/1.1 200 OK
response
Clemm, et al. Standards Track [Page 28]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.8 DAV:expand-property
Many property values are defined as a DAV:href, or a set of DAV:
elements. The DAV:expand-property report provides a mechanism
retrieving in one request the properties from the
identified by those DAV:href elements. This report not
decreases the number of requests required, but also allows the
to minimize the number of separate read transactions required on
underlying versioning store
The DAV:expand-property report SHOULD be supported by all
that support the REPORT method
Marshalling
The request body MUST be a DAV:expand-property XML element
property (property*)>
property (property*)>
property name NMTOKEN #REQUIRED
name value: a property element
property namespace NMTOKEN "DAV:">
namespace value: an XML
The response body for a successful request MUST be
DAV:multistatus XML element
multistatus: see RFC 2518, Section 12.9
The properties reported in the DAV:prop elements of
DAV:multistatus element MUST be those identified by
DAV:property elements in the DAV:expand-property element.
there are DAV:property elements nested within a DAV:
element, then every DAV:href in the value of the
property is replaced by a DAV:response element whose DAV:
elements report the values of the properties identified by
nested DAV:property elements. The nested DAV:property
can in turn contain DAV:property elements, so that multiple
of DAV:href expansion can be requested
Note that a validating parser MUST be aware that the DAV:expand
property report effectively modifies the DTD of every property
replacing every occurrence of "href" in the DTD with "href |
response".
Clemm, et al. Standards Track [Page 29]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.8.1 Example - DAV:expand-
This example describes how to query a version-controlled resource
determine the DAV:creator-display-name and DAV:activity-set of
version in the version history of that version-controlled resource
This example assumes that the server supports the version-
feature (see Section 5).
>>
REPORT /foo.html HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
property xmlns:D="DAV:">
property name="version-history">
property name="version-set">
property name="creator-displayname"/>
property name="activity-set"/>
property
property
property
>>
HTTP/1.1 207 Multi-
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
response
http://www.webdav.org/foo.html
response
http://repo.webdav.org/his/23
response
http://repo.webdav.org/his/23/ver/1
Fred
Clemm, et al. Standards Track [Page 30]
RFC 3253 Versioning Extensions to WebDAV March 2002
activity-set>
http://www.webdav.org/ws/dev/
activity-set>
HTTP/1.1 200 OK
response
response
http://repo.webdav.org/his/23/ver/2
Sally
activity-set
http://repo.webdav.org/act/add-refresh-cmd
activity-set>
HTTP/1.1 200 OK
response
HTTP/1.1 200 OK
response
HTTP/1.1 200 OK
response
In this example, the DAV:creator-displayname and DAV:activity-
properties of the versions in the DAV:version-set of
DAV:version-history of http://www.webdav.org/foo.html are reported
3.9 Additional OPTIONS
If the server supports the version-control feature, it MUST
"version-control" as a field in the DAV response header from
OPTIONS request on any resource that supports any
properties, reports, or methods
3.10 Additional PUT
Additional Preconditions
(DAV:cannot-modify-version-controlled-content): If the request-
identifies a resource with a DAV:checked-in property, the
MUST fail unless DAV:auto-version semantics will
check out the resource
(DAV:cannot-modify-version): If the request-URL identifies
version, the request MUST fail
Clemm, et al. Standards Track [Page 31]
RFC 3253 Versioning Extensions to WebDAV March 2002
If the request creates a new resource that is automatically
under version control, all preconditions for VERSION-CONTROL
to the request
Additional Postconditions
(DAV:auto-checkout): If the resource was a checked-in version
controlled resource whose DAV:auto-version property indicates
should be automatically checked out but not automatically
in for a modification request, then the server MUST
automatically checked out the resource prior to executing
request. In particular, the value of the DAV:checked-out
of the resource MUST be that of the DAV:checked-in property
to the request, the DAV:checked-in property MUST have
removed, and the DAV:predecessor-set property MUST be
to be the same as the DAV:checked-out property. If any part
the checkout/update sequence failed, the status from the
part of the request MUST be returned, and the server
preceding the request sequence MUST be restored
(DAV:auto-checkout-checkin): If the resource was a checked-
version-controlled resource whose DAV:auto-version
indicates it should be automatically checked out and
checked in for a modification request, then the server MUST
automatically checked out the resource prior to executing
request and automatically checked it in after the request.
particular, the DAV:checked-in property of the resource
identify a new version whose content and dead properties are
same as those of the resource. The DAV:predecessor-set of the
version MUST identify the version identified by the DAV:checked-
property prior to the request. If any part of
checkout/update/checkin sequence failed, the status from
failed part of the request MUST be returned, and the server
preceding the request sequence MUST be restored
If the request creates a new resource, the new resource MAY
automatically been placed under version control, and
postconditions for VERSION-CONTROL apply to the request
3.11 Additional PROPFIND
A DAV:allprop PROPFIND request SHOULD NOT return any of
properties defined by this document. This allows a versioning
to perform efficiently when a naive client, which does not
the cost of asking a server to compute all possible live properties
issues a DAV:allprop PROPFIND request
Clemm, et al. Standards Track [Page 32]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions
(DAV:supported-live-property): If the request attempts to access
property defined by this document, the semantics of that
MUST be supported by the server
3.12 Additional PROPPATCH
Additional Preconditions
(DAV:cannot-modify-version-controlled-property): If the
attempts to modify a dead property, same semantics as PUT (
Section 3.10).
(DAV:cannot-modify-version): If the request attempts to modify
dead property, same semantics as PUT (see Section 3.10).
(DAV:cannot-modify-protected-property): An attempt to modify
property that is defined by this document, as being protected
that kind of resource, MUST fail
(DAV:supported-live-property): An attempt to modify a
defined by this document, but whose semantics are not enforced
the server, MUST fail. This helps ensure that a client will
notified when it is trying to use a property whose semantics
not supported by the server
Additional Postconditions
(DAV:auto-checkout): If the request modified a dead property,
semantics as PUT (see Section 3.10).
(DAV:auto-checkout-checkin): If the request modified a
property, same semantics as PUT (see Section 3.10).
3.13 Additional DELETE
Additional Preconditions
(DAV:no-version-delete): A server MAY fail an attempt to DELETE
version
Additional Postconditions
(DAV:update-predecessor-set): If a version was deleted, the
MUST have replaced any reference to that version in
DAV:predecessor-set by a copy of the DAV:predecessor-set of
deleted version
Clemm, et al. Standards Track [Page 33]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.14 Additional COPY
Additional Preconditions
If the request creates a new resource that is automatically
under version control, all preconditions for VERSION-CONTROL
to the request
Additional Postconditions
(DAV:must-not-copy-versioning-property): A property defined
this document MUST NOT have been copied to the new
created by this request, but instead that property of the
resource MUST have the default initial value it would have had
the new resource had been created by a non-versioning method
as PUT or a MKCOL
(DAV:auto-checkout): If the destination is a version-
resource, same semantics as PUT (see Section 3.10).
(DAV:auto-checkout-checkin): If the destination is a version
controlled resource, same semantics as PUT (see Section 3.10).
(DAV:copy-creates-new-resource): If the source of a COPY is
version-controlled resource or version, and if there is
resource at the destination of the COPY, then the COPY creates
new non-version-controlled resource at the destination of
COPY. The new resource MAY automatically be put under
control, but the resulting version-controlled resource MUST
associated with a new version history created for that
version-controlled resource, and all postconditions
VERSION-CONTROL apply to the request
3.15 Additional MOVE
Additional Preconditions
(DAV:cannot-rename-version): If the request-URL identifies
version, the request MUST fail
Additional Postconditions
(DAV:preserve-versioning-properties): When a resource is
from a source URL to a destination URL, a property defined by
document MUST have the same value at the destination URL as it
at the source URL
Clemm, et al. Standards Track [Page 34]
RFC 3253 Versioning Extensions to WebDAV March 2002
3.16 Additional UNLOCK
Note that these semantics apply both to an explicit UNLOCK request
as well as to the removal of a lock because of a lock timeout. If
precondition or postcondition cannot be satisfied, the lock
MUST NOT occur
Additional Preconditions
(DAV:version-history-is-tree): If the request-URL identifies
checked-out version-controlled resource that will be
checked in when the lock is removed, then the versions
by the DAV:predecessor-set of the checked-out resource MUST
descendants of the root version of the version history for
DAV:checked-out version
Additional Postconditions
(DAV:auto-checkin): If the request-URL identified a checked-
version-controlled resource that had been automatically
out because of its DAV:auto-version property, the request
have created a new version in the version history of
DAV:checked-out version. The request MUST have allocated a
for the version that MUST NOT have previously identified any
resource, and MUST NOT ever identify a resource other than
version. The content, dead properties, DAV:resourcetype,
DAV:predecessor-set of the new version MUST be copied from
checked-out resource. The DAV:version-name of the new
MUST be set to a server-defined value distinct from all
DAV:version-name values of other versions in the same
history. The request MUST have removed the DAV:checked-
property of the version-controlled resource, and MUST have added
DAV:checked-in property that identifies the new version
4 CHECKOUT-IN-PLACE
With the version-control feature, WebDAV locking can be used to
the proliferation of versions that would result if every
to a version-controlled resource produced a new version.
checkout-in-place feature provides an alternative mechanism
allows a client to explicitly check out and check in a resource
create a new version
4.1 Additional Version
The checkout-in-place feature introduces the following
properties for a version
Clemm, et al. Standards Track [Page 35]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.1.1 DAV:checkout-
This property controls the behavior of CHECKOUT when a
already is checked out or has a successor. If the DAV:checkout-
of a version is DAV:forbidden, a CHECKOUT request MUST fail if
would result in that version appearing in the DAV:predecessor-set
DAV:checked-out property of more than one version or checked-
resource. If DAV:checkout-fork is DAV:discouraged, such a
request MUST fail unless DAV:fork-ok is specified in the
request body
A server MAY reject attempts to modify the DAV:checkout-fork of
version
ANY value: A sequence of elements with at most one DAV:
or DAV:forbidden element
4.1.2 DAV:checkin-
This property controls the behavior of CHECKIN when a version
has a successor. If the DAV:checkin-fork of a version
DAV:forbidden, a CHECKIN request MUST fail if it would result in
version appearing in the DAV:predecessor-set of more than
version. If DAV:checkin-fork is DAV:discouraged, such a
request MUST fail unless DAV:fork-ok is specified in the
request body
A server MAY reject attempts to modify the DAV:checkout-fork of
version
ANY value: A sequence of elements with at most one DAV:
or DAV:forbidden element
4.2 Checked-Out Resource
The checkout-in-place feature introduces the following
properties for a checked-out resource
4.2.1 DAV:checkout-
This property determines the DAV:checkout-fork property of
version that results from checking in this resource
Clemm, et al. Standards Track [Page 36]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.2.2 DAV:checkin-
This property determines the DAV:checkin-fork property of the
that results from checking in this resource
4.3 CHECKOUT Method (applied to a version-controlled resource
A CHECKOUT request can be applied to a checked-in version-
resource to allow modifications to the content and dead properties
that version-controlled resource
If a CHECKOUT request fails, the server state preceding the
MUST be restored
Marshalling
If a request body is included, it MUST be a DAV:checkout
element
ANY value: A sequence of elements with at most one DAV:fork-
element
If a response body for a successful request is included, it
be a DAV:checkout-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:must-be-checked-in): If a version-controlled resource
being checked out, it MUST have a DAV:checked-in property
(DAV:checkout-of-version-with-descendant-is-forbidden): If
DAV:checkout-fork property of the version being checked out
DAV:forbidden, the request MUST fail if a version identifies
version in its DAV:predecessor-set
(DAV:checkout-of-version-with-descendant-is-discouraged): If
DAV:checkout-fork property of the version being checked out
DAV:discouraged, the request MUST fail if a version
that version in its DAV:predecessor-set unless DAV:fork-ok
specified in the request body
Clemm, et al. Standards Track [Page 37]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:checkout-of-checked-out-version-is-forbidden): If
DAV:checkout-fork property of the version being checked out
DAV:forbidden, the request MUST fail if a checked-out
identifies that version in its DAV:checked-out property
(DAV:checkout-of-checked-out-version-is-discouraged): If
DAV:checkout-fork property of the version being checked out
DAV:discouraged, the request MUST fail if a checked-out
identifies that version in its DAV:checked-out property
DAV:fork-ok is specified in the request body
Postconditions
(DAV:is-checked-out): The checked-out resource MUST have
DAV:checked-out property that identifies the DAV:checked-
version preceding the checkout. The version-controlled
MUST NOT have a DAV:checked-in property
(DAV:initialize-predecessor-set): The DAV:predecessor-set
of the checked-out resource MUST be initialized to be
DAV:checked-out version
4.3.1 Example - CHECKOUT of a version-controlled
>>
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.
Content-Length: 0
>>
HTTP/1.1 200
Cache-Control: no-
In this example, the version-controlled resource /foo.html is
out
4.4 CHECKIN Method (applied to a version-controlled resource
A CHECKIN request can be applied to a checked-out version-
resource to produce a new version whose content and dead
are copied from the checked-out resource
If a CHECKIN request fails, the server state preceding the
MUST be restored
Clemm, et al. Standards Track [Page 38]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling
If a request body is included, it MUST be a DAV:checkin
element
ANY value: A sequence of elements with at most
DAV:keep-checked-out element and at most one DAV:fork-ok element
If a response body for a successful request is included, it
be a DAV:checkin-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:must-be-checked-out): The request-URL MUST identify
resource with a DAV:checked-out property
(DAV:version-history-is-tree) The versions identified by
DAV:predecessor-set of the checked-out resource MUST
descendants of the root version of the version history for
DAV:checked-out version
(DAV:checkin-fork-forbidden): A CHECKIN request MUST fail if
would cause a version whose DAV:checkin-fork is DAV:forbidden
appear in the DAV:predecessor-set of more than one version
(DAV:checkin-fork-discouraged): A CHECKIN request MUST fail if
would cause a version whose DAV:checkin-fork is DAV:discouraged
appear in the DAV:predecessor-set of more than one version,
DAV:fork-ok is specified in the request body
Postconditions
(DAV:create-version): The request MUST have created a new
in the version history of the DAV:checked-out version.
request MUST have allocated a distinct new URL for the
Clemm, et al. Standards Track [Page 39]
RFC 3253 Versioning Extensions to WebDAV March 2002
version, and that URL MUST NOT ever identify any resource
than that version. The URL for the new version MUST be returned
a Location response header
(DAV:initialize-version-content-and-properties): The content,
properties, DAV:resourcetype, and DAV:predecessor-set of the
version MUST be copied from the checked-out resource.
DAV:version-name of the new version MUST be set to a server
defined value distinct from all other DAV:version-name values
other versions in the same version history
(DAV:checked-in): If the request-URL identifies a version
controlled resource and DAV:keep-checked-out is not specified
the request body, the DAV:checked-out property of the version
controlled resource MUST have been removed and a DAV:checked-
property that identifies the new version MUST have been added
(DAV:keep-checked-out): If DAV:keep-checked-out is specified
the request body, the DAV:checked-out property of the checked-
resource MUST have been updated to identify the new version
4.4.1 Example -
>>
CHECKIN /foo.html HTTP/1.1
Host: www.webdav.
Content-Length: 0
>>
HTTP/1.1 201
Location: http://repo.webdav.org/his/23/ver/32
Cache-Control: no-
In this example, version-controlled resource /foo.html is checked in
and a new version is created at http://repo.webdav.org/his/23/ver/32.
4.5 UNCHECKOUT
An UNCHECKOUT request can be applied to a checked-out version
controlled resource to cancel the CHECKOUT and restore the pre
CHECKOUT state of the version-controlled resource
If an UNCHECKOUT request fails, the server MUST undo any
effects of the UNCHECKOUT request
Clemm, et al. Standards Track [Page 40]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling
If a request body is included, it MUST be a DAV:uncheckout
element
If a response body for a successful request is included, it
be a DAV:uncheckout-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:must-be-checked-out-version-controlled-resource):
request-URL MUST identify a version-controlled resource with
DAV:checked-out property
Postconditions
(DAV:cancel-checked-out): The value of the DAV:checked-in
is that of the DAV:checked-out property prior to the request,
the DAV:checked-out property has been removed
(DAV:restore-content-and-dead-properties): The content and
properties of the version-controlled resource are copies of
DAV:checked-in version
4.5.1 Example -
>>
UNCHECKOUT /foo.html HTTP/1.1
Host: www.webdav.
Content-Length: 0
>>
HTTP/1.1 200
Cache-Control: no-
In this example, the content and dead properties of the version
controlled resource identified by http://www.webdav.org/foo.html
restored to their values preceding the most recent CHECKOUT of
version-controlled resource
Clemm, et al. Standards Track [Page 41]
RFC 3253 Versioning Extensions to WebDAV March 2002
4.6 Additional OPTIONS
If a server supports the checkout-in-place feature, it MUST
"checkout-in-place" as a field in the DAV response header from
OPTIONS request on any resource that supports any
properties, reports, or methods
5 Version-History
It is often useful to have access to a version history even after
version-controlled resources for that version history have
deleted. A server can provide this functionality by
version history resources. A version history resource is a
that exists in a server defined namespace and therefore is
by any deletion or movement of version-controlled resources.
version history resource is an appropriate place to add a
that logically applies to all states of a resource. The DAV:expand
property report (see Section 3.8) can be applied to the DAV:version
set of a version history resource to provide a variety of
reports on all versions in that version history
5.1 Version History
The DAV:resourcetype of a version history MUST be DAV:version
history
The version-history feature introduces the following
properties for a version history
5.1.1 DAV:version-set (protected
This property identifies each version of this version history
5.1.2 DAV:root-version (computed
This property identifies the root version of this version history
5.2 Additional Version-Controlled Resource
The version-history feature introduces the following
property for a version-controlled resource
Clemm, et al. Standards Track [Page 42]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.2.1 DAV:version-history (computed
This property identifies the version history resource for
DAV:checked-in or DAV:checked-out version of this version-
resource
5.3 Additional Version
The version-history feature introduces the following
property for a version
5.3.1 DAV:version-history (computed
This property identifies the version history that contains
version
5.4 DAV:locate-by-history
Many properties identify a version from some version history. It
often useful to be able to efficiently locate a version-
resource for that version history. The DAV:locate-by-history
can be applied to a collection to locate the collection member
is a version-controlled resource for a specified version
resource
Marshalling
The request body MUST be a DAV:locate-by-history XML element
prop: see RFC 2518, Section 12.11
The response body for a successful request MUST be
DAV:multistatus XML element containing every version-
resource that is a member of the collection identified by
request-URL, and whose DAV:version-history property identifies
of the version history resources identified by the request body
The DAV:prop element in the request body identifies
properties should be reported in the DAV:prop elements in
response body
Clemm, et al. Standards Track [Page 43]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions
(DAV:must-be-version-history): Each member of the DAV:version
history-set element in the request body MUST identify a
history resource
5.4.1 Example - DAV:locate-by-history
>>
REPORT /ws/public HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://repo.webdav.org/his/23
http://repo.webdav.org/his/84
http://repo.webdav.org/his/129
>>
HTTP/1.1 207 Multi-
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
response
http://www.webdav.org/ws/public/x/test.html
http://repo.webdav.org/his/23
HTTP/1.1 200 OK
response
Clemm, et al. Standards Track [Page 44]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, there is only one version-controlled member
/ws/public that is a version-controlled resource for one of the
specified version history resources. In particular
/ws/public/x/test.html is the version-controlled resource
http://repo.webdav.org/his/23.
5.5 Additional OPTIONS
If the server supports the version-history feature, it MUST
"version-history" as a field in the DAV response header from
OPTIONS request on any resource that supports any
properties, reports, or methods
A DAV:version-history-collection-set element MAY be included in
request body to identify collections that may contain version
resources
Additional Marshalling
If an XML request body is included, it MUST be a DAV:options
element
ANY value: A sequence of elements with at most
DAV:version-history-collection-set element
If an XML response body for a successful request is included,
MUST be a DAV:options-response XML element
response ANY
ANY value: A sequence of elements with at most
DAV:version-history-collection-set element
collection-set (href*)>
If DAV:version-history-collection-set is included in the
body, the response body for a successful request MUST contain
DAV:version-history-collection-set element identifying
that may contain version histories. An identified collection
be the root collection of a tree of collections, all of which
contain version histories. Since different servers can
different parts of the URL namespace, different resources on
same host MAY have different DAV:version-history-collection-
values. The identified collections MAY be located on
hosts from the resource
Clemm, et al. Standards Track [Page 45]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.6 Additional DELETE
Additional Postconditions
(DAV:delete-version-set): If the request deleted a
history, the request MUST have deleted all versions in
DAV:version-set of that version history, and MUST have
the postconditions for version deletion (see Section 3.13).
(DAV:version-history-has-root): If the request deleted the
version of a version history, the request MUST have updated
DAV:root-version of the version history to refer to
version that is an ancestor of all other remaining versions
that version history. A result of this postcondition is
every version history will have at least one version, and the
way to delete all versions is to delete the version
resource
5.7 Additional COPY
Additional Preconditions
(DAV:cannot-copy-history): If the request-URL identifies a
history, the request MUST fail. In order to create
version history whose versions have the same content and
properties, the appropriate sequence of VERSION-CONTROL, CHECKOUT
PUT, PROPPATCH, and CHECKIN requests must be made
5.8 Additional MOVE
Additional Preconditions
(DAV:cannot-rename-history): If the request-URL identifies
version history, the request MUST fail
5.9 Additional VERSION-CONTROL
Additional Postconditions
(DAV:new-version-history): If the request created a new
history, the request MUST have allocated a new server-defined
for that version history that MUST NOT have previously
any other resource, and MUST NOT ever identify a resource
than this version history
Clemm, et al. Standards Track [Page 46]
RFC 3253 Versioning Extensions to WebDAV March 2002
5.10 Additional CHECKIN
Additional Postconditions
(DAV:add-to-history): A URL for the new version resource MUST
been added to the DAV:version-set of the version history of
DAV:checked-out version
6 Workspace
In order to allow multiple users to work concurrently on
versions to the same version history, it is necessary to allocate
the server multiple checked-out resources for the same
history. Even if only one user is making changes to a resource,
user will sometimes wish to create a "private" version, and then
expose that version at a later time. One way to provide
functionality depends on the client keeping track of its current
of checked-out resources. This is the working-resource
defined in Section 8. The other way to provide this
avoids the need for persistent state on the client, and instead
the server maintain a human meaningful namespace for related sets
checked-out resources. This is the workspace feature defined in
section
The workspace feature introduces a "workspace resource". A
resource is a collection whose members are related version-
and non-version-controlled resources. Multiple workspaces may
used to expose different versions and configurations of a set
version-controlled resources concurrently. In order to make
to a version-controlled resource in one workspace visible in
workspace, that version-controlled resource must be checked in,
then the corresponding version-controlled resource in the
workspace can be updated to display the content and dead
of the new version
In order to ensure unambiguous merging (see Section 11)
baselining (see Section 12) semantics, a workspace may contain
most one version-controlled resource for a given version history
This is required for unambiguous merging because the MERGE
must identify which version-controlled resource is to be the
target of a given version. This is required for
baselining because a baseline can only select one version for a
version-controlled resource
Initially, an empty workspace can be created. Non-version-
resources can then be added to the workspace with standard
requests such as PUT and MKCOL. Version-controlled resources can
added to the workspace with VERSION-CONTROL requests. If
Clemm, et al. Standards Track [Page 47]
RFC 3253 Versioning Extensions to WebDAV March 2002
baseline feature is supported, collections in the workspace can
placed under baseline control, and then initialized by
baselines
6.1 Workspace
The workspace feature introduces the following REQUIRED property
a workspace
6.1.1 DAV:workspace-checkout-set (computed
This property identifies each checked-out resource
DAV:workspace property identifies this workspace
6.2 Additional Resource
The workspace feature introduces the following REQUIRED property
a WebDAV resource
6.2.1 DAV:workspace (protected
The DAV:workspace property of a workspace resource MUST
itself. The DAV:workspace property of any other type of
MUST be the same as the DAV:workspace of its parent collection
6.3 MKWORKSPACE
A MKWORKSPACE request creates a new workspace resource. A server
restrict workspace creation to particular collections, but a
can determine the location of these collections from
DAV:workspace-collection-set OPTIONS request (see Section 6.4).
If a MKWORKSPACE request fails, the server state preceding
request MUST be restored
Marshalling
If a request body is included, it MUST be a DAV:mkworkspace
element
If a response body for a successful request is included, it
be a DAV:mkworkspace-response XML element
Clemm, et al. Standards Track [Page 48]
RFC 3253 Versioning Extensions to WebDAV March 2002
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:resource-must-be-null): A resource MUST NOT exist at
request-URL
(DAV:workspace-location-ok): The request-URL MUST identify
location where a workspace can be created
Postconditions
(DAV:initialize-workspace): A new workspace exists at
request-URL. The DAV:resourcetype of the workspace MUST
DAV:collection. The DAV:workspace of the workspace MUST
the workspace
6.3.1 Example -
>>
MKWORKSPACE /ws/public HTTP/1.1
Host: www.webdav.
Content-Length: 0
>>
HTTP/1.1 201
Cache-Control: no-
In this example, a new workspace is created
http://www.webdav.org/ws/public
6.4 Additional OPTIONS
If a server supports the workspace feature, it MUST
"workspace" as a field in the DAV response header from an
request on any resource that supports any versioning properties
reports, or methods
If a server supports the workspace feature, it MUST also support
checkout-in-place feature and the version-history feature
A DAV:workspace-collection-set element MAY be included in the
body to identify collections that may contain workspace resources
Clemm, et al. Standards Track [Page 49]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Marshalling
If an XML request body is included, it MUST be a DAV:options
element
ANY value: A sequence of elements with at most
DAV:workspace-collection-set element
If an XML response body for a successful request is included,
MUST be a DAV:options-response XML element
response ANY
ANY value: A sequence of elements with at most
DAV:workspace-collection-set element
collection-set (href*)>
If DAV:workspace-collection-set is included in the request body
the response body for a successful request MUST contain
DAV:workspace-collection-set element identifying collections
may contain workspaces. An identified collection MAY be the
collection of a tree of collections, all of which may
workspaces. Since different servers can control different
of the URL namespace, different resources on the same host
have different DAV:workspace-collection-set values.
identified collections MAY be located on different hosts from
resource
Clemm, et al. Standards Track [Page 50]
RFC 3253 Versioning Extensions to WebDAV March 2002
6.4.1 Example -
>>
OPTIONS /doc HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
collection-set/>
collection-set/>
>>
HTTP/1.1 200
DAV: 1
DAV: version-control,checkout-in-place,version-history,
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
response xmlns:D="DAV:">
collection-set
http://repo.webdav.org/his
collection-set
collection-set
http://www.webdav.org/public/ws
http://www.webdav.org/private/ws
collection-set
response
In this example, the server indicates that it provides Class 1
support and basic-server-workspace versioning support. In addition
the server indicates the requested locations of the version
resources and the workspace resources
6.5 Additional DELETE
Additional Postconditions
(DAV:delete-workspace-members): If a workspace is deleted,
resource that identifies that workspace in its DAV:
property MUST be deleted
Clemm, et al. Standards Track [Page 51]
RFC 3253 Versioning Extensions to WebDAV March 2002
6.6 Additional MOVE
Additional Postconditions
(DAV:workspace-member-moved): If the request-URL did not
a workspace, the DAV:workspace of the destination MUST have
updated to have the same value as the DAV:workspace of the
collection of the destination
(DAV:workspace-moved): If the request-URL identified a workspace
any reference to that workspace in a DAV:workspace property
have been updated to refer to the new location of that workspace
6.7 Additional VERSION-CONTROL
A VERSION-CONTROL request can be used to create a new version
controlled resource for an existing version history. This allows
creation of version-controlled resources for the same version
in multiple workspaces
Additional Marshalling
ANY value: A sequence of elements with at most one DAV:
element
Additional Preconditions
(DAV:cannot-add-to-existing-history): If the DAV:version-
request body element contains a DAV:version element, the request
URL MUST NOT identify a resource
(DAV:must-be-version): The DAV:href of the DAV:version
MUST identify a version
(DAV:one-version-controlled-resource-per-history-per-workspace):
If the DAV:version-control request body specifies a version,
if the request-URL is a member of a workspace, then there MUST
already be a version-controlled member of that workspace
DAV:checked-in or DAV:checked-out property identifies any
from the version history of the version specified in the
body
Clemm, et al. Standards Track [Page 52]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions
(DAV:new-version-controlled-resource): If the request-URL did
identify a resource, a new version-controlled resource exists
the request-URL whose content and dead properties are
by those of the version in the request body, and
DAV:checked-in property identifies that version
6.7.1 Example - VERSION-CONTROL (using an existing version history
>>
VERSION-CONTROL /ws/public/bar.html HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://repo.webdav.org/his/12/ver/V3
>>
HTTP/1.1 201
Cache-Control: no-
In this example, a new version-controlled resource is created
/ws/public/bar.html. The content and dead properties of the
version-controlled resource are initialized to be the same as
of the version identified by http://repo.webdav.org/his/12/ver/V3.
7 UPDATE
The update feature provides a mechanism for changing the state of
checked-in version-controlled resource to be that of another
from the version history of that resource
7.1 UPDATE
The UPDATE method modifies the content and dead properties of
checked-in version-controlled resource (the "update target") to
those of a specified version (the "update source") from the
history of that version-controlled resource
Clemm, et al. Standards Track [Page 53]
RFC 3253 Versioning Extensions to WebDAV March 2002
The response to an UPDATE request identifies the resources
by the request, so that a client can efficiently update any
state it is maintaining. Extensions to the UPDATE method
multiple resources to be modified from a single UPDATE request (
Section 12.13).
Marshalling
The request body MUST be a DAV:update element
ANY value: A sequence of elements with at most one DAV:
element and at most one DAV:prop element
prop: see RFC 2518, Section 12.11
The response for a successful request MUST be a 207 Multi-Status
where the DAV:multistatus XML element in the response
identifies all resources that have been modified by the request
multistatus: see RFC 2518, Section 12.9
The response MUST include a Cache-Control:no-cache header
Postconditions
(DAV:update-content-and-properties): If the DAV:version element
the request body identified a version that is in the same
history as the DAV:checked-in version of a version-
resource identified by the request-URL, then the content and
properties of that version-controlled resource MUST be the same
those of the version specified by the DAV:version element, and
DAV:checked-in property of the version-controlled resource
identify that version. The request-URL MUST appear in
DAV:response element in the response body
(DAV:report-properties): If DAV:prop is specified in the
body, the properties specified in the DAV:prop element MUST
reported in the DAV:response elements in the response body
Clemm, et al. Standards Track [Page 54]
RFC 3253 Versioning Extensions to WebDAV March 2002
7.1.1 Example -
>>
UPDATE /foo.html HTTP/1.1
Host: www.webdav.
Content-type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://repo.webdav.org/his/23/ver/33
>>
HTTP/1.1 207 Multi-
Content-Type: text/xml; charset="utf-8"
Content-Length:
Cache-Control: no-
encoding="utf-8" ?>
response
http://www.webdav.org/foo.html
HTTP/1.1 200 OK
response
In this example, the content and dead properties
http://repo.webdav.org/his/23/ver/33 are copied to the version
controlled resource /foo.html, and the DAV:checked-in property
/foo.html is updated to refer
http://repo.webdav.org/his/23/ver/33.
7.2 Additional OPTIONS
If the server supports the update feature, it MUST include "update
as a field in the DAV response header from an OPTIONS request on
resource that supports any versioning properties, reports,
methods
Clemm, et al. Standards Track [Page 55]
RFC 3253 Versioning Extensions to WebDAV March 2002
8 Label
A version "label" is a string that distinguishes one version in
version history from all other versions in that version history.
label can automatically be assigned by a server, or it can
assigned by a client in order to provide a meaningful name for
version. A given version label can be assigned to at most
version of a given version history, but client assigned labels can
reassigned to another version at any time. Note that although
given label can be applied to at most one version from the
version history, the same label can be applied to versions
different version histories
For certain methods, if the request-URL identifies a version
controlled resource, a label can be specified in a Label
header (see Section 8.3) to cause the method to be applied to
version selected by that label from the version history of
version-controlled resource
8.1 Additional Version
The label feature introduces the following REQUIRED property for
version
8.1.1 DAV:label-name-set (protected
This property contains the labels that currently select this version
PCDATA value:
8.2 LABEL
A LABEL request can be applied to a version to modify the labels
select that version. The case of a label name MUST be preserved
it is stored and retrieved. When comparing two label names to
if they match or not, a server SHOULD use a case-sensitive URL
escaped UTF-8 encoded comparison of the two label names
If a LABEL request is applied to a checked in version-
resource, the operation MUST be applied to the DAV:checked-in
of that version-controlled resource
Clemm, et al. Standards Track [Page 56]
RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling
The request body MUST be a DAV:label element
ANY value: A sequence of elements with at most one DAV:add
DAV:set, or DAV:remove element
PCDATA value:
The request MAY include a Label header
The request MAY include a Depth header. If no Depth header
included, Depth:0 is assumed. Standard depth semantics apply,
the request is applied to the collection identified by
request-URL and to all members of the collection that satisfy
Depth value. If a Depth header is included and the request
on any resource, the response MUST be a 207 Multi-Status
identifies all resources for which the request has failed
If a response body for a successful request is included, it
be a DAV:label-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:must-be-checked-in): If the request-URL identifies
version-controlled resource, the version-controlled resource
be checked in
(DAV:must-select-version-in-history): If a Label request header
included and the request-URL identifies a version-
resource, the specified label MUST select a version in the
history of the version-controlled resource
(DAV:add-must-be-new-label): If DAV:add is specified in
request body, the specified label MUST NOT appear in
DAV:label-name-set of any version in the version history of
version-controlled resource
Clemm, et al. Standards Track [Page 57]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:label-must-exist): If DAV:remove is specified in the
body, the specified label MUST appear in the DAV:label-name-set
that version
Postconditions
(DAV:add-or-set-label): If DAV:add or DAV:set is specified in
request body, the specified label MUST appear in the DAV:label
name-set of the specified version, and MUST NOT appear in
DAV:label-name-set of any other version in the version history
that version
(DAV:remove-label): If DAV:remove is specified in the
body, the specified label MUST NOT appear in the DAV:label-name
set of any version in the version history of that version
8.2.1 Example - Setting a
>>
LABEL /foo.html HTTP/1.1
Host: www.webdav.
Content-type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
default
>>
HTTP/1.1 200
Cache-Control: no-
In this example, the label "default" is applied to the DAV:checked-
version of /foo.html
8.3 Label
For certain methods (e.g. GET, PROPFIND), if the request-
identifies a version-controlled resource, a label can be specified
a Label request header to cause the method to be applied to
version selected by that label from the version history of
version-controlled resource
Clemm, et al. Standards Track [Page 58]
RFC 3253 Versioning Extensions to WebDAV March 2002
The value of a label header is the name of a label, encoded
URL-escaped UTF-8. For example, the label "release B.3"
identified by the following header
Label: release%20B.3
A Label header MUST have no effect on a request whose request-
does not identify a version-controlled resource. In particular,
MUST have no effect on a request whose request-URL identifies
version or a version history
A server MUST return an HTTP-1.1 Vary header containing Label in
successful response to a cacheable request (e.g., GET) that
a Label header
8.4 Additional OPTIONS
If the server supports the label feature, it MUST include "label"
a field in the DAV response header from an OPTIONS request on
resource that supports any versioning properties, reports,
methods
8.5 Additional GET
Additional Marshalling
The request MAY include a Label header
Additional Preconditions
(DAV:must-select-version-in-history): If a Label request header
included and the request-URL identifies a version-
resource, the specified label MUST select a version in the
history of the version-controlled resource
Additional Postconditions
(DAV:apply-request-to-labeled-version): If the request-
identifies a version-controlled resource and a Label
header is included, the response MUST contain the content of
specified version rather than that of the version-
resource
8.6 Additional PROPFIND
Additional Marshalling
The request MAY include a Label header
Clemm, et al. Standards Track [Page 59]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions
(DAV:must-select-version-in-history): If a Label request header
included and the request-URL identifies a version-
resource, the specified label MUST select a version in the
history of the version-controlled resource
Additional Postconditions
(DAV:apply-request-to-labeled-version): If the request-
identifies a version-controlled resource and a Label
header is included, the response MUST contain the properties
the specified version rather than that of the version-
resource
8.7 Additional COPY
Additional Marshalling
The request MAY include a Label header
Additional Preconditions
(DAV:must-select-version-in-history): If a Label request header
included and the request-URL identifies a version-
resource, the specified label MUST select a version in the
history of the version-controlled resource
Additional Postconditions
(DAV:apply-request-to-labeled-version): If the request-
identifies a version-controlled resource and a Label
header is included, the request MUST have copied the
and content of the specified version rather than that of
version-controlled resource
8.8 Additional CHECKOUT
If the server supports the working-resource option, a LABEL
may be included to check out the version selected by the
label
Additional Marshalling
The request MAY include a Label header
Clemm, et al. Standards Track [Page 60]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions
(DAV:must-select-version-in-history): If a Label request header
included and the request-URL identifies a version-
resource, the specified label MUST select a version in the
history of the version-controlled resource
(DAV:must-not-have-label-and-apply-to-version): If a Label
header is included, the request body MUST NOT contain
DAV:apply-to-version element
Additional Postconditions
(DAV:apply-request-to-labeled-version): If the request-
identifies a checked-in version-controlled resource, and a
request header is included, the CHECKOUT MUST have been applied
the version selected by the specified label, and not to
version-controlled resource itself
8.9 Additional UPDATE
If the request body of an UPDATE request contains a DAV:label-
element, the update target is the resource identified by
request-URL, and the update source is the version selected by
specified label from the version history of the update target
Additional Marshalling
ANY value: A sequence of elements with at most one DAV:label-
or DAV:version element (but not both).
PCDATA value:
The request MAY include a Depth header. If no Depth header
included, Depth:0 is assumed. Standard depth semantics apply,
the request is applied to the collection identified by
request-URL and to all members of the collection that satisfy
Depth value. If a Depth header is included and the request
on any resource, the response MUST be a 207 Multi-Status
identifies all resources for which the request has failed
Additional Preconditions
(DAV:must-select-version-in-history): If the request includes
DAV:label-name element in the request body, the label MUST
a version in the version history of the version-
resource identified by the request-URL
Clemm, et al. Standards Track [Page 61]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:depth-update): If the request includes a Depth header
standard depth semantics apply, and the request is applied to
collection identified by the request-URL and to all members of
collection that satisfy the Depth value. The request MUST
applied to a collection before being applied to any members
that collection, since an update of a version-
collection might change the membership of that collection
Additional Postconditions
(DAV:apply-request-to-labeled-version): If a DAV:label-
element appears in the request body, the content and
properties of the version-controlled resource must have
updated to be those of the version selected by that label
9 Working-Resource
The working-resource feature provides an alternative to the
feature for supporting parallel development. Unlike the
feature, where the desired configuration of versions and checked-
resources is maintained on the server, the working-resource
maintains the configuration on the client. This simplifies
server implementation, but does not allow a user to access
configuration from clients in different physical locations, such
from another office, from home, or while traveling.
difference is that the workspace feature isolates clients from
logical change that involves renaming shared resources, until
logical change is complete and tested; with the working
feature, all clients use a common set of shared version-
resources and every client sees the result of a MOVE as soon as
occurs
If a server supports the working-resource feature but not
checkout-in-place feature, a CHECKOUT request can only be used
create a working resource, and cannot be used to check out
version-controlled resource. If a server supports the checkout-in
place feature, but not the working-resource feature, a CHECKOUT
only be used to change the state of a version-controlled
from checked-in to checked-out
9.1 Additional Version
The working-resource feature introduces the following
properties for a version
9.1.1 DAV:checkout-
This property is defined in Section 4.1.1.
Clemm, et al. Standards Track [Page 62]
RFC 3253 Versioning Extensions to WebDAV March 2002
9.1.2 DAV:checkin-
This property is defined in Section 4.1.2.
9.2 Working Resource
The working-resource feature introduces the following
properties for a working resource. Since a working resource is
checked-out resource, it also has any property defined in
document for a checked-out resource
9.2.1 DAV:auto-update (protected
This property identifies the version-controlled resource that will
updated when the working resource is checked in
9.2.2 DAV:checkout-
This property is defined in Section 4.2.1.
9.2.3 DAV:checkin-
This property is defined in Section 4.2.2.
9.3 CHECKOUT Method (applied to a version
A CHECKOUT request can be applied to a version to create a
working resource. The content and dead properties of the
resource are a copy of the version that was checked out
Marshalling
If a request body is included, it MUST be a DAV:checkout
element
ANY value: A sequence of elements with at most one DAV:apply-to
version and at most one DAV:fork-ok element
If a response body for a successful request is included
it MUST be a DAV:checkout-response XML element
Clemm, et al. Standards Track [Page 63]
RFC 3253 Versioning Extensions to WebDAV March 2002
response ANY
The response MUST include a Location header
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:checkout-of-version-with-descendant-is-forbidden):
Section 4.3.
(DAV:checkout-of-version-with-descendant-is-discouraged):
Section 4.3.
(DAV:checkout-of-checked-out-version-is-forbidden): See
4.3.
(DAV:checkout-of-checked-out-version-is-discouraged): See
4.3.
Postconditions
(DAV:create-working-resource): If the request-URL identified
version, the Location response header MUST contain the URL of
new working resource. The DAV:checked-out property of the
working resource MUST identify the version that was checked out
The content and dead properties of the working resource MUST
copies of the content and dead properties of the DAV:checked-
version. The DAV:predecessor-set property of the working
MUST be initialized to be the version identified by the request
URL. The DAV:auto-update property of the working resource
NOT exist
(DAV:create-working-resource-from-checked-in-version): If
request-URL identified a version-controlled resource,
DAV:apply-to-version is specified in the request body,
CHECKOUT is applied to the DAV:checked-in version of the version
controlled resource, and not the version-controlled
itself. A new working resource is created and the version
controlled resource remains checked-in. The DAV:auto-
property of the working resource MUST identify the version
controlled resource
Clemm, et al. Standards Track [Page 64]
RFC 3253 Versioning Extensions to WebDAV March 2002
9.3.1 Example - CHECKOUT of a
>>
CHECKOUT /his/12/ver/V3 HTTP/1.1
Host: repo.webdav.
Content-Length: 0
>>
HTTP/1.1 201
Location: http://repo.webdav.org/wr/157
Cache-Control: no-
In this example, the version identified
http://repo.webdav.org/his/12/ver/V3 is checked out, and the
working resource is located at http://repo.webdav.org/wr/157.
9.4 CHECKIN Method (applied to a working resource
A CHECKIN request can be applied to a working resource to produce
new version whose content and dead properties are a copy of those
the working resource. If the DAV:auto-update property of the
resource was set because the working resource was created by
a CHECKOUT with the DAV:apply-to-version flag to a version-
resource, the CHECKIN request will also update the content and
properties of that version-controlled resource to be those of the
version
Marshalling
If a request body is included, it MUST be a DAV:checkin
element
ANY value: A sequence of elements with at most one DAV:fork-
element
If a response body for a successful request is included, it
be a DAV:checkin-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Clemm, et al. Standards Track [Page 65]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions
(DAV:must-be-checked-out): See Section 4.4.
(DAV:version-history-is-tree) See Section 4.4.
(DAV:checkin-fork-forbidden): See Section 4.4.
(DAV:checkin-fork-discouraged): See Section 4.4.
(DAV:no-overwrite-by-auto-update): If the DAV:auto-update
for the checked-out resource identifies a version-
resource, at least one of the versions identified by
DAV:predecessor-set property of the checked-out resource
identify a version that is either the same as or a descendant
the version identified by the DAV:checked-in property of
version-controlled resource
Postconditions
(DAV:create-version): See Section 4.4.
(DAV:initialize-version-content-and-properties): See Section 4.4.
(DAV:auto-update): If the DAV:auto-update property of
checked-out resource identified a version-controlled resource,
UPDATE request with the new version MUST have been applied to
version-controlled resource
(DAV:delete-working-resource): If the request-URL identifies
working resource and if DAV:keep-checked-out is not specified
the request body, the working resource is deleted
9.4.1 Example - CHECKIN of a working
>>
CHECKIN /wr/157 HTTP/1.1
Host: repo.webdav.
Content-Length: 0
>>
HTTP/1.1 201
Location: http://repo.webdav.org/his/23/ver/15
Cache-Control: no-
Clemm, et al. Standards Track [Page 66]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the working resource /wr/157 checked in, and a
version is created at http://repo.webdav.org/his/23/ver/15.
9.5 Additional OPTIONS
If the server supports the working-resource feature, it MUST
"working-resource" as a field in the DAV response header from
OPTIONS request on any resource that supports any
properties, reports, or methods
9.6 Additional COPY
Additional Postconditions
(DAV:copy-creates-new-resource): The result of copying a
resource is a new non-version-controlled resource at
destination of the COPY. The new resource MAY automatically
put under version control, but the resulting version-
resource MUST be associated with a new version history created
that new version-controlled resource
9.7 Additional MOVE
Additional Preconditions
(DAV:cannot-rename-working-resource): If the request-
identifies a working resource, the request MUST fail
Additional Postconditions
(DAV:update-auto-update): If the request-URL identified
version-controlled resource, any DAV:auto-update properties
identified that version-controlled resource MUST have been
to contain the new location of that version-controlled resource
10 Advanced Versioning
Advanced versioning addresses the problems of parallel
and configuration management of multiple sets of
resources. Traditionally, artifacts of software development
including requirements, design documents, code, and test cases,
been a focus of configuration management. Web sites,
multiple inter-linked resources (HTML, graphics, sound, CGI,
others), are another class of complex information artifacts
benefit from the application of configuration management.
advanced versioning capabilities for coordinating concurrent
provide the infrastructure for efficient and controlled management
large evolving web sites
Clemm, et al. Standards Track [Page 67]
RFC 3253 Versioning Extensions to WebDAV March 2002
10.1 Advanced Versioning
Although a server MAY support any combination of advanced
features, in order to minimize the complexity of a WebDAV
versioning client, a WebDAV advanced versioning server SHOULD
one of the following packages
Advanced-Server-Workspace Package: basic-server-workspace
plus all advanced
Advanced-Client-Workspace Package: basic-client-workspace
plus all advanced
The advanced-server-workspace package supports advanced
capabilities for a client with no persistent state. The advanced
client-workspace package supports advanced versioning
for a client that maintains configuration state on the client.
server that supports both advanced workspace packages
interoperate with all versioning clients
10.2 Advanced Versioning
The following additional terms are used by the advanced
features
A "collection" is a resource whose state consists of not
content and properties, but also a set of named "bindings",
a binding identifies what RFC 2518 calls an "internal member"
the collection. Note that a binding is not a resource, but
is a part of the state of a collection that defines a mapping
a binding name (a URL segment) to a resource (an internal
of the collection).
Collection Version
A "collection version resource", or simply "collection version",
captures the dead properties of a version-controlled collection
as well as the names of its version-controlled bindings (
Section 14). A version-controlled binding is a binding to
version-controlled resource. If the checkout-in-place feature
supported, a collection version can be created by checking out
then checking in a version-controlled collection. If
working-resource feature is supported, a collection version can
created by checking out a collection version (to create a "
collection") and then checking in the working collection
Clemm, et al. Standards Track [Page 68]
RFC 3253 Versioning Extensions to WebDAV March 2002
A "configuration" is a set of resources that consists of a
collection and all members (not just internal members) of
root collection that are not members of another configuration
The root collection is called the "configuration root", and
members of this set are called the "members of the configuration".
Note that a collection (which is a single resource) is
different from a configuration (which is a set of resources).
Baseline
A "baseline resource", or simply "baseline", of a collection is
version of the configuration that is rooted at that
(see Section 12). In particular, a baseline captures
DAV:checked-in version of every version-controlled member of
configuration. Note that a collection version (which captures
state of a single resource) is very different from a
baseline (which captures the state of a set of resources).
Baseline-Controlled
A "baseline-controlled collection" is a collection from
baselines can be created (see Section 12).
Version-Controlled Configuration
A "version-controlled configuration resource", or
"version-controlled configuration", is a special kind of version
controlled resource that is associated with a baseline-
collection, and is used to create and access baselines of
collection (see Section 12). When a collection is both version
controlled and baseline-controlled, a client can create a
version of the collection by checking out and checking in
collection, and it can create a new baseline of that collection
checking out and checking in the version-controlled
of that collection
Activity
An "activity resource", or simply "activity", is a resource
selects a set of versions that correspond to a single
change, where the versions selected from a given version
form a single line of descent through that version history (
Section 13).
Clemm, et al. Standards Track [Page 69]
RFC 3253 Versioning Extensions to WebDAV March 2002
11 Merge
When a user wants to accept the changes (new versions) created
someone else, it is important not just to update the version
controlled resources in the user's workspace with those new versions
since this could result in "backing out" changes the user has made
those version-controlled resources. Instead, the versions created
another workspace should be "merged" into the user's version
controlled resources
The version history of a version-controlled resource provides
information needed to determine the result of the merge.
particular, the merge should select whichever version is later in
line of descent from the root version. In case the versions to
merged are on different lines of descent (neither version is
descendant of the other), neither version should be selected,
instead, a new version should be created that contains the
merge of the content and dead properties of those versions.
MERGE request can be used to check out each version-
resource that requires such a merge, and set the DAV:merge-
property of each checked-out resource to identify the version to
merged. The user is responsible for modifying the content and
properties of the checked-out resource so that it represents
logical merge of that version, and then adding that version to
DAV:predecessor-set of the checked-out resource
If the server is capable of automatically performing the merge,
MAY update the content, dead properties, and DAV:predecessor-set
the checked-out resource itself. Before checking in
automatically merged resource, the user is responsible for
that the automatic merge is correct
11.1 Additional Checked-Out Resource
The merge feature introduces the following REQUIRED properties for
checked-out resource
11.1.1 DAV:merge-
This property identifies each version that is to be merged into
checked-out resource
Clemm, et al. Standards Track [Page 70]
RFC 3253 Versioning Extensions to WebDAV March 2002
11.1.2 DAV:auto-merge-
This property identifies each version that the server has merged
this checked-out resource. The client should confirm that the
has been performed correctly before moving a URL from the DAV:auto
merge-set to the DAV:predecessor-set of a checked-out resource
11.2 MERGE
The MERGE method performs the logical merge of a specified
(the "merge source") into a specified version-controlled
(the "merge target"). If the merge source is neither an ancestor
a descendant of the DAV:checked-in or DAV:checked-out version of
merge target, the MERGE checks out the merge target (if it is
already checked out) and adds the URL of the merge source to
DAV:merge-set of the merge target. It is then the client'
responsibility to update the content and dead properties of
checked-out merge target so that it reflects the logical merge of
merge source into the current state of the merge target. The
indicates that it has completed the update of the merge target,
deleting the merge source URL from the DAV:merge-set of the checked
out merge target, and adding it to the DAV:predecessor-set. As
error check for a client forgetting to complete a merge, the
MUST fail an attempt to CHECKIN a version-controlled resource with
non-empty DAV:merge-set
When a server has the ability to automatically update the content
dead properties of the merge target to reflect the logical merge
the merge source, it may do so unless DAV:no-auto-merge is
in the MERGE request body. In order to notify the client that
merge source has been automatically merged, the MERGE request
add the URL of the auto-merged source to the DAV:auto-merge-
property of the merge target, and not to the DAV:merge-set property
The client indicates that it has verified that the auto-merge
valid, by deleting the merge source URL from the DAV:auto-merge-set
and adding it to the DAV:predecessor-set
Multiple merge sources can be specified in a single MERGE request
The set of merge sources for a MERGE request is determined from
DAV:source element of the MERGE request body as follows
- If DAV:source identifies a version, that version is a
source
- If DAV:source identifies a version-controlled resource,
DAV:checked-in version of that version-controlled resource is
merge source
Clemm, et al. Standards Track [Page 71]
RFC 3253 Versioning Extensions to WebDAV March 2002
- If DAV:source identifies a collection, the DAV:checked-in
of each version-controlled resource that is a member of
collection is a merge source
The request-URL identifies the set of possible merge targets. If
request-URL identifies a collection, any member of the
rooted at the request-URL is a possible merge target. The
target of a particular merge source is the version-controlled
checked-out resource whose DAV:checked-in or DAV:checked-out
is from the same version history as the merge source. If a
source has no merge target, that merge source is ignored
The MERGE response identifies the resources that a client must
to complete the merge. It also identifies the resources modified
the request, so that a client can efficiently update any cached
it is maintaining
Marshalling
The request body MUST be a DAV:merge element
The set of merge sources is determined by the DAV:source
in the request body
ANY value: A sequence of elements with one DAV:source element,
most one DAV:no-auto-merge element, at most one DAV:no-
element, at most one DAV:prop element, and any legal set
elements that can occur in a DAV:checkout element
prop: see RFC 2518, Section 12.11
The response for a successful request MUST be a 207 Multi-Status
where the DAV:multistatus XML element in the response
identifies all resources that have been modified by the request
multistatus: see RFC 2518, Section 12.9
The response to a successful request MUST include a
header containing the URL for the new version created by
checkin
The response MUST include a Cache-Control:no-cache header
Clemm, et al. Standards Track [Page 72]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions
(DAV:cannot-merge-checked-out-resource): The DAV:source
MUST NOT identify a checked-out resource. If the DAV:
element identifies a collection, the collection MUST NOT have
member that is a checked-out resource
(DAV:checkout-not-allowed): If DAV:no-checkout is specified in
request body, it MUST be possible to perform the merge
checking out any of the merge targets
All preconditions of the CHECKOUT operation apply to the
performed by the request
Postconditions
(DAV:ancestor-version): If a merge target is a version-
or checked-out resource whose DAV:checked-in version
DAV:checked-out version is the merge source or is a descendant
the merge source, the merge target MUST NOT have been modified
the MERGE
(DAV:descendant-version): If the merge target was a checked-
version-controlled resource whose DAV:checked-in version was
ancestor of the merge source, an UPDATE operation MUST have
applied to the merge target to set its content and dead
to be those of the merge source. If the UPDATE method is
supported, the merge target MUST have been checked out,
content and dead properties of the merge target MUST have been
to those of the merge source, and the merge source MUST have
added to the DAV:auto-merge-set of the merge target. The
target MUST appear in a DAV:response XML element in the
body
(DAV:checked-out-for-merge): If the merge target was a checked-
version-controlled resource whose DAV:checked-in version
neither a descendant nor an ancestor of the merge source,
CHECKOUT MUST have been applied to the merge target. All
elements in the DAV:merge XML element that could appear in
DAV:checkout XML element MUST have been used as arguments to
CHECKOUT request. The merge target MUST appear in a DAV:
XML element in the response body
(DAV:update-merge-set): If the DAV:checked-out version of
merge target is neither equal to nor a descendant of the
source, the merge source MUST be added to either the DAV:merge-
or the DAV:auto-merge-set of the merge target. The merge
MUST appear in a DAV:response XML element in the response body
Clemm, et al. Standards Track [Page 73]
RFC 3253 Versioning Extensions to WebDAV March 2002
If a merge source has been added to the DAV:auto-merge-set,
content and dead properties of the merge target MUST have
modified by the server to reflect the result of a logical merge
the merge source and the merge target. If a merge source has
added to the DAV:merge-set, the content and dead properties of
merge target MUST NOT have been modified by the server.
DAV:no-auto-merge is specified in the request body, the
source MUST NOT have been added to the DAV:auto-merge-set
(DAV:report-properties): If DAV:prop is specified in the
body, the properties specified in the DAV:prop element MUST
reported in the DAV:response elements in the response body
11.2.1 Example -
>>
MERGE /ws/public HTTP/1.1
Host: www.webdav.
Content-type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://www.webdav.org/ws/dev/sally
>>
HTTP/1.1 207 Multi-
Content-Type: text/xml; charset="utf-8"
Content-Length:
Cache-Control: no-
encoding="utf-8" ?>
response
http://www.webdav.org/ws/public/src/parse.c
HTTP/1.1 200 OK
response
response
http://www.webdav.org/ws/public/doc/parse.html
HTTP/1.1 200 OK
response
Clemm, et al. Standards Track [Page 74]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the DAV:checked-in versions from the
http://www.webdav.org/ws/dev/sally are merged into the version
controlled resources in the
http://www.webdav.org/ws/public. The
/ws/public/src/parse.c and /ws/public/doc/parse.html were modified
the request
11.3 DAV:merge-preview
A merge preview describes the changes that would result if
versions specified by the DAV:source element in the request body
to be merged into the resource identified by the request-
(commonly, a collection).
Marshalling
The request body MUST be a DAV:merge-preview XML element
The response body for a successful request MUST be
DAV:merge-preview-report XML element
(update-preview | conflict-preview | ignore-preview)*>
A DAV:update-preview element identifies a merge target
DAV:checked-in property would change as a result of the MERGE,
identifies the merge source for that merge target
A DAV:conflict-preview element identifies a merge target
requires a merge
A DAV:common-ancestor element identifies the version that is
common ancestor of both the merge source and the DAV:checked-in
DAV:checked-out version of the merge target
A DAV:ignore-preview element identifies a version that has
merge target and therefore would be ignored by the merge
Clemm, et al. Standards Track [Page 75]
RFC 3253 Versioning Extensions to WebDAV March 2002
11.3.1 Example - DAV:merge-preview
>>
REPORT /ws/public HTTP/1.1
Host: www.webdav.
Content-type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://www.webdav.org/ws/dev/fred
>>
HTTP/1.1 200
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
http://www.webdav.org/ws/public/foo.html
http://repo.webdav.org/his/23/ver/18
http://repo.webdav.org/his/23/ver/42
http://www.webdav.org/ws/public/bar.html
http://www.repo/his/42/ver/3
Clemm, et al. Standards Track [Page 76]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the merge preview report indicates that
/his/23/ver/42 would be merged in /ws/public/foo.html, and
/his/42/ver/3 would update /ws/public/bar.html if the
http://www.webdav.org/ws/dev/fred was merged into the
http://www.webdav.org/ws/public
11.4 Additional OPTIONS
If the server supports the merge feature, it MUST include "merge"
a field in the DAV response header from an OPTIONS request on
resource that supports any versioning properties, reports,
methods
11.5 Additional DELETE
Additional Postconditions
(DAV:delete-version-reference): If a version is deleted,
reference to that version in a DAV:merge-set or DAV:auto-merge-
property MUST be removed
11.6 Additional CHECKIN
Additional Preconditions
(DAV:merge-must-be-complete): The DAV:merge-set and DAV:auto
merge-set of the checked-out resource MUST be empty or not exist
12 Baseline
A configuration is a set of resources that consists of a
collection and all members of that root collection except
resources that are members of another configuration. A
that contains a large number of resources can consume a large
of space on a server. This can make it prohibitively expensive
remember the state of an existing configuration by creating
Depth:infinity copy of its root collection
A baseline is a version resource that captures the state of
version-controlled member of a configuration. A baseline history
a version history whose versions are baselines. New baselines
created by checking out and then checking in a special kind
version-controlled resource called a version-
configuration
A collection that is under baseline control is called a baseline
controlled collection. In order to allow efficient
implementation, the state of a baseline of a collection is limited
Clemm, et al. Standards Track [Page 77]
RFC 3253 Versioning Extensions to WebDAV March 2002
be a set of versions and their names relative to the collection,
the operations on a baseline are limited to the creation of
baseline from a collection, and restoring or merging the
back into a collection. A server MAY automatically put a
under baseline control when it is created, or a client can use
BASELINE-CONTROL method to put a specified collection under
control
As a configuration gets large, it is often useful to break it up
a set of smaller configurations that form the logical "components"
that configuration. In order to capture the fact that a baseline
a configuration is logically extended by a component
baseline, the component configuration baseline is captured as
"subbaseline" of the baseline
The root collection of a configuration is unconstrained with
to its relationship to the root collection of any of its components
In particular, the root collection of a configuration can have
member that is the root collection of one of its components (e.g.,
configuration /sys/x can have a component /sys/x/foo), can be
member of the root collection of one of its components (e.g.,
configuration /sys/y/z can have a component /sys/y), or
(e.g., configuration /sys/x can have a component /comp/bar).
12.1 Version-Controlled Configuration
Since a version-controlled configuration is a version-
resource, it has all the properties of a version-controlled resource
In addition, the baseline feature introduces the following
property for a version-controlled configuration
12.1.1 DAV:baseline-controlled-collection (protected
This property identifies the collection that contains the version
controlled resources whose DAV:checked-in versions are being
by this version-controlled configuration. The DAV:version
controlled-configuration of the DAV:baseline-controlled-collection
a version-controlled configuration MUST identify that version
controlled configuration
baseline-controlled-collection (href)>
12.2 Checked-Out Configuration
Since a checked-out configuration is a checked-out resource, it
all the properties of a checked-out resource. In addition,
baseline feature introduces the following REQUIRED property for
checked-out configuration
Clemm, et al. Standards Track [Page 78]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.2.1 DAV:subbaseline-
This property determines the DAV:subbaseline-set property of
baseline that results from checking in this resource
A server MAY reject attempts to modify the DAV:subbaseline-set of
checked-out configuration
12.3 Baseline
The DAV:resourcetype of a baseline MUST be DAV:baseline. Since
baseline is a version resource, it has all the properties of
version resource. In addition, the baseline feature introduces
following REQUIRED properties for a baseline
12.3.1 DAV:baseline-collection (protected
This property contains a server-defined URL for a collection,
each member of this collection MUST either be a version-
resource with the same DAV:checked-in version and relative name as
version-controlled member of the baseline-controlled collection
the time the baseline was created, or be a collection needed
provide the relative name for a version-controlled resource
baseline-collection (href)>
12.3.2 DAV:subbaseline-set (protected
The URLs in the DAV:subbaseline-set property MUST identify a set
other baselines. The subbaselines of a baseline are the
identified by its DAV:subbaseline-set and all subbaselines of
baselines identified by its DAV:subbaseline-set
12.4 Additional Resource
The baseline feature introduces the following REQUIRED property for
resource
12.4.1 DAV:version-controlled-configuration (computed
If the resource is a member of a version-controlled
(i.e. the resource is a collection under baseline control or is
member of a collection under baseline control), this
identifies that version-controlled configuration
Clemm, et al. Standards Track [Page 79]
RFC 3253 Versioning Extensions to WebDAV March 2002
controlled-configuration (href)>
12.5 Additional Workspace
The baseline feature introduces the following REQUIRED property for
workspace
12.5.1 DAV:baseline-controlled-collection-set (computed
This property identifies each member of the workspace that is
collection under baseline control (as well as the workspace itself
if it is under baseline control).
baseline-controlled-collection-set (href*)>
12.6 BASELINE-CONTROL
A collection can be placed under baseline control with
BASELINE-CONTROL request. When a collection is placed under
control, the DAV:version-controlled-configuration property of
collection is set to identify a new version-controlled configuration
This version-controlled configuration can be checked out and
checked in to create a new baseline for that collection
If a baseline is specified in the request body, the DAV:checked-
version of the new version-controlled configuration will be
baseline, and the collection is initialized to contain version
controlled members whose DAV:checked-in versions and relative
are determined by the specified baseline
If no baseline is specified, a new baseline history is
containing a baseline that captures the state of the version
controlled members of the collection, and the DAV:checked-in
of the version-controlled configuration will be that baseline
Marshalling
If a request body is included, it MUST be a DAV:baseline-
XML element
baseline-control ANY
ANY value: A sequence of elements with at most one DAV:
element
baseline (href)>
If a response body for a successful request is included, it
be a DAV:baseline-control-response XML element
Clemm, et al. Standards Track [Page 80]
RFC 3253 Versioning Extensions to WebDAV March 2002
baseline-control-response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:version-controlled-configuration-must-not-exist):
DAV:version-controlled-configuration property of the
identified by the request-URL MUST not exist
(DAV:must-be-baseline): The DAV:href of the DAV:baseline
in the request body MUST identify a baseline
(DAV:must-have-no-version-controlled-members): If a DAV:
element is specified in the request body, the
identified by the request-URL MUST have no version-
members
(DAV:one-baseline-controlled-collection-per-history-per
workspace): If the request-URL identifies a workspace or a
of a workspace, and if a baseline is specified in a DAV:
element in the request body, then there MUST NOT be
collection in that workspace whose DAV:version-controlled
configuration property identifies a version-
configuration for the baseline history of that baseline
Postconditions
(DAV:create-version-controlled-configuration): A new version
controlled configuration is created, whose DAV:baseline
controlled-collection property identifies the collection
(DAV:reference-version-controlled-configuration):
DAV:version-controlled-configuration of the collection
the new version-controlled configuration
(DAV:select-existing-baseline): If the request body specifies
baseline, the DAV:checked-in property of the new version
controlled configuration MUST have been set to identify
baseline. A version-controlled member of the collection will
created for each version in the baseline, where the version
controlled member will have the content and dead properties
that version, and will have the same name relative to
collection as the corresponding version-controlled resource
when the baseline was created. Any nested collections that
needed to provide the appropriate name for a version-
member will be created
Clemm, et al. Standards Track [Page 81]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:create-new-baseline): If no baseline is specified in
request body, the request MUST have created a new baseline
at a server-defined URL, and MUST have created a new baseline
that baseline history. The DAV:baseline-collection of the
baseline MUST identify a collection whose members have the
relative name and DAV:checked-in version as the version-
members of the request collection. The DAV:checked-in property
the new version-controlled configuration MUST identify the
baseline
12.6.1 Example - BASELINE-
>>
BASELINE-CONTROL /src HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
baseline-control xmlns:D="DAV:">
http://www.webdav.org/repo/blh/13/ver/8
baseline-control
>>
HTTP/1.1 200
Cache-Control: no-
Content-Length: 0
Clemm, et al. Standards Track [Page 82]
RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the collection /src is placed under
control, and is populated with members from an existing baseline.
new version-controlled configuration (/repo/vcc/128) is created
associated with /src, and /src is initialized with version-
members whose DAV:checked-in versions are those selected by
DAV:baseline-collection (/repo/bc/15) of the specified
(/repo/blh/13/ver/8). The following diagram illustrates
resulting state on the server
+-------------------------------------+
|Baseline-Controlled Collection |<------+
|/src | |
|-------------------------------------| |
|DAV:version-controlled-configuration +---+ |
+-------------------------------------+ | |
| |
| |
+-------------------------------------+ | |
|Version-Controlled Configuration |<--+ |
|/repo/vcc/128 | |
|-------------------------------------| |
|DAV:baseline-controlled-collection +-------+
|-------------------------------------|
|DAV:checked-in +-------+
+-------------------------------------+ |
|DAV:version-history +---+ |
+-------------------------------------+ | |
| |
| |
+------------------------+ | |
|Baseline History |<---------------+ |
|/repo/blh/13 | |
|------------------------+ |
|DAV:version-set +----------------+ |
+------------------------+ | | | | |
v | v v |
| |
+------------------------+ | |
|Baseline |<-------+-----------+
|/repo/blh/13/ver/8 |
|------------------------+ +--------------+
|DAV:baseline-collection +---->|Collection |
+------------------------+ |/repo/bc/15 |
+--------------+
Clemm, et al. Standards Track [Page 83]
RFC 3253 Versioning Extensions to WebDAV March 2002
In order to create new baselines of /src, /repo/vcc/128 can
checked out, new versions can be created or selected by the version
controlled members of /src, and then /repo/vcc/128 can be checked
to capture the current state of those version-controlled members
12.7 DAV:compare-baseline
A DAV:compare-baseline report contains the differences between
baseline identified by the request-URL (the "request baseline")
the baseline specified in the request body (the "compare baseline").
Marshalling
The request body MUST be a DAV:compare-baseline XML element
baseline (href)>
The response body for a successful request MUST be a DAV:compare
baseline-report XML element
baseline-
(added-version | deleted-version | changed-version)*>
A DAV:added-version element identifies a version that is
DAV:checked-in version of a member of the DAV:baseline-
of the compare baseline, but no version in the version history
that version is the DAV:checked-in version of a member of
DAV:baseline-collection of the request baseline
A DAV:deleted-version element identifies a version that is
DAV:checked-in version of a member of the DAV:baseline-
of the request baseline, but no version in the version history
that version is the DAV:checked-in version of a member of
DAV:baseline-collection of the compare baseline
A DAV:changed-version element identifies two different
from the same version history that are the DAV:checked-in
of the DAV:baseline-collection of the request baseline and
compare baseline, respectively
Clemm, et al. Standards Track [Page 84]
RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions
(DAV:must-be-baseline): The DAV:href in the request body
identify a baseline
(DAV:baselines-from-same-history): A server MAY require that
baselines being compared be from the same baseline history
12.7.1 Example - DAV:compare-baseline
>>
REPORT /bl-his/12/bl/14 HTTP/1.1
Host: repo.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
baseline xmlns:D="DAV:">
http://repo.webdav.org/bl-his/12/bl/15
baseline
>>
HTTP/1.1 200
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
baseline-report xmlns:D="DAV:">
http://repo.webdav.org/his/23/ver/8
http://repo.webdav.org/his/29/ver/12
http://repo.webdav.org/his/29/ver/19
http://repo.webdav.org/his/12/ver/4
baseline-report
In this example, the differences between baseline 14 and baseline 15
of http://repo.webdav.org/bl-his/12 are identified
Clemm, et al. Standards Track [Page 85]
RFC 3253 Versioning Extensions to WebDAV March 2002
12.8 Additional OPTIONS
If a server supports the baseline feature, it MUST include "baseline
as a field in the DAV response header from an OPTIONS request on
resource that supports any versioning properties, reports,
methods
12.9 Additional MKCOL
Additional Postconditions
If a server automatically puts a newly created collection
baseline control, all postconditions for BASELINE-CONTROL apply
the MKCOL
12.10 Additional COPY
Additional Postconditions
If the request creates a new collection at the Destination, and
server automatically puts a newly created collection
baseline control, all postconditions for BASELINE-CONTROL apply
the COPY
12.11 Additional CHECKOUT
Additional Preconditions
(DAV:must-not-update-baseline-collection): If the request-
identifies a member of the configuration rooted at
DAV:baseline-collection of a baseline, the request MUST fail
12.12 Additional CHECKIN
Additional Preconditions
(DAV:no-checked-out-baseline-controlled-collection-members):
the request-URL identifies a version-controlled configuration,
version-controlled members of the DAV:baseline-controlled
collection of the version-controlled configuration MUST
checked-in
(DAV:one-version-per-history-per-baseline): If the request-
identifies a version-controlled configuration, the set of
selected by that version-controlled configuration MUST contain
most one version from any version history, where a version
selected by a version-controlled configuration if the version
identified by the DAV:checked-in property of any member of
Clemm, et al. Standards Track [Page 86]
RFC 3253 Versioning Extensions to WebDAV March 2002
configuration rooted at the DAV:baseline-controlled collection
that version-controlled configuration, or is identified by
DAV:checked-in property of any member of the configuration
at the DAV:baseline-collection of any subbaseline of
version-controlled configuration
(DAV:cannot-modify-version-controlled-configuration): If
request-URL identifies a version-controlled member of a baseline
controlled collection whose version-controlled configuration
checked-in, the request MUST fail unless the DAV:auto-
property of the version-controlled configuration
automatically check out that version-controlled configuration
it is modified
Additional Postconditions
(DAV:create-baseline-collection): If the request-URL identifies
version-controlled configuration, the DAV:baseline-collection
the new baseline identifies a collection whose members have
same relative name and DAV:checked-in version as the members
the DAV:baseline-controlled-collection of the version-
configuration at the time of the request
(DAV:modify-configuration): If the request-URL identifies
version-controlled member of a baseline-controlled collection
this is a modification to the version-controlled configuration
that baseline-controlled collection, and standard auto-
semantics apply
12.13 Additional UPDATE
Additional Preconditions
(DAV:baseline-controlled-members-must-be-checked-in): If
request-URL identifies a version-controlled configuration,
all version-controlled members of the DAV:baseline-controlled
collection of that version-controlled configuration MUST
checked-in
(DAV:must-not-update-baseline-collection): If the request-
identifies a member of the configuration rooted at
DAV:baseline-collection of a baseline, the request MUST fail
(DAV:cannot-modify-version-controlled-configuration): If
request updates the DAV:checked-in property of any version
controlled member of a baseline-controlled collection
version-controlled configuration is checked-in, the request
Clemm, et al. Standards Track [Page 87]
RFC 3253 Versioning Extensions to WebDAV March 2002
fail unless the DAV:auto-version property of the version
controlled configuration will automatically check out
version-controlled configuration when it is modified
Additional Postconditions
(DAV:set-baseline-controlled-collection-members): If the
updated the DAV:checked-in property of a version-
configuration, then the version-controlled members of
DAV:baseline-controlled-collection of that version-
configuration MUST have been updated so that they have the
relative name, content, and dead properties as the members of
DAV:baseline-collection of the baseline. In particular
- A version-controlled member for a given version history
have been deleted if there is no version-controlled member
that version history in the DAV:baseline-collection of
baseline
- A version-controlled member for a given version history
have been renamed if its name relative to the baseline
controlled collection is different from that of the version
controlled member for that version history in
DAV:baseline-collection of the baseline
- A new version-controlled member MUST have been created for
member of the DAV:baseline-collection of the baseline for
there is no corresponding version-controlled member in
baseline-controlled collection
- An UPDATE request MUST have been applied to each version
controlled member for a given version history
DAV:checked-in version is not the same as that of the version
controlled member for that version history in
DAV:baseline-collection of the baseline
(DAV:update-subbaselines): If the request updated a version
controlled configuration whose DAV:baseline-controlled-
contains a baseline-controlled member for one of the
of the request baseline, then the DAV:checked-in property of
version-controlled configuration of that baseline-
member MUST have been updated to be that subbaseline. If
request updated a version-controlled configuration
DAV:baseline-controlled-collection is a member of a workspace
contains a baseline-controlled member for one of the
of the request baseline, then the DAV:checked-in property of
version-controlled configuration of that baseline-
member MUST have been updated to be that subbaseline
Clemm, et al. Standards Track [Page 88]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:modify-configuration): If the request updated
DAV:checked-in property of any version-controlled member of
baseline-controlled collection, and if this DAV:checked-
property differs from the DAV:checked-in property of
corresponding version-controlled member of the DAV:baseline
collection of the DAV:checked-in baseline of the DAV:version
controlled-configuration of the baseline-controlled collection
then this is a modification to that version-
configuration, and standard auto-versioning semantics apply
12.14 Additional MERGE
If the merge source is a baseline, the merge target is a version
controlled configuration for the baseline history of that baseline
where the baseline-controlled collection of that version-
configuration is a member of the collection identified by
request-URL
Additional Preconditions
(DAV:must-not-update-baseline-collection): Same semantics
UPDATE (see Section 12.13).
(DAV:cannot-modify-version-controlled-configuration):
semantics as UPDATE (see Section 12.13).
Additional Postconditions
(DAV:merge-baseline): If the merge target is a version-
configuration whose DAV:checked-out baseline is not a
of the merge baseline, then the merge baseline MUST have
added to the DAV:auto-merge-set of a version-
configuration. The DAV:checked-in version of each member of
DAV:baseline-collection of that baseline MUST have been
into the DAV:baseline-controlled-collection of that version
controlled configuration
(DAV:merge-subbaselines): If the merge target is a version
controlled configuration whose DAV:baseline-controlled-
contains a baseline-controlled member for one of the
of the merge baseline, then that subbaseline MUST have been
into the version-controlled configuration of that baseline
controlled member. If the merge target is a version-
configuration whose DAV:baseline-controlled-collection is a
of a workspace that contains a baseline-controlled member for
of the subbaselines of the merge baseline, then that
MUST have been merged into the version-controlled configuration
that baseline-controlled member
Clemm, et al. Standards Track [Page 89]
RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:set-baseline-controlled-collection-members): Same
as UPDATE (see Section 12.13).
(DAV:modify-configuration): Same semantics as UPDATE (see
12.13).
13 Activity
An activity is a resource that selects a set of versions that are
a single "line of descent", where a line of descent is a sequence
versions connected by successor relationships. If an
selects versions from multiple version histories, the
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
often desirable to perform several different logical changes in
single workspace, and then selectively merge a subset of
logical changes to other workspaces. An activity can be used
represent a single logical change, where an activity tracks all
resources that were modified to effect that single logical change
When a version-controlled resource is checked out, the user
which activity should be associated with a new version that will
created when that version-controlled resource is checked in. It
then possible to select a particular logical change for merging
another workspace, by specifying the appropriate activity in a
request
Another common problem is that although a version-controlled
may need to have multiple lines of descent, all work done by
of a given team must be on a single line of descent (to avoid
between team members). An activity resource provides the
for addressing this problem. When a version-controlled resource
checked out, a client can request that an existing activity be
or that a new activity be created. Activity semantics then
that all versions in a given version history that are associated
an activity are on a single line of descent. If all members of
team share a common activity (or sub-activities of a
activity), then all changes made by members of that team will be on
single line of descent
Clemm, et al. Standards Track [Page 90]
RFC 3253 Versioning Extensions to WebDAV March 2002
The following diagram illustrates activities. Version V5 is
latest version of foo.html selected by activity Act-2, and version V
is the latest version of bar.html selected by activity Act-2.
foo.html History bar.html
+---+ +---+
Act-1| |V1 Act-1| |V
+---+ +---+
| |
| |
+---+ +---+
Act-1| |V2 Act-2| |V
+---+ +---+
/ \ |
/ \ |
+---+ +---+ +---+
Act-1| |V3 Act-2| |V4 Act-2| |V
+---+ +---+ +---+
| |
| |
+---+ +---+
Act-2| |V5 Act-3| |V
+---+ +---+
Activities appear under a variety of names in existing
systems. When an activity is used to capture a logical change, it
commonly called a "change set". When an activity is used to
a line of descent, it is commonly called a "branch". When a
supports both branches and change sets, it is often useful to
that a particular change set occur on a particular branch.
relationship can be captured by making the change set activity be
"subactivity" of the branch activity
13.1 Activity
The DAV:resourcetype of an activity MUST be DAV:activity
The activity feature introduces the following REQUIRED properties
an activity
13.1.1 DAV:activity-version-set (computed
This property identifies each version whose DAV:activity-set
identifies this activity. Multiple versions of a single
history can be selected by an activity's DAV:activity-version-
Clemm, et al. Standards Track [Page 91]
RFC 3253 Versioning Extensions to WebDAV March 2002
property, but all DAV:activity-version-set versions from a
version history must be on a single line of descent from the
version of that version history
activity-version-set (href*)>
13.1.2 DAV:activity-checkout-set (computed
This property identifies each checked-out resource
DAV:activity-set identifies this activity
activity-checkout-set (href*)>
13.1.3 DAV:subactivity-
This property identifies each activity that forms a part of
logical change being captured by this activity. An activity
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
line of descent, and when an activity selects a version for merging
the latest version in this extended set is the one that will
merged
A server MAY reject attempts to modify the DAV:subactivity-set of
activity
13.1.4 DAV:current-workspace-set (computed
This property identifies each workspace whose DAV:current-activity
set identifies this activity
13.2 Additional Version
The activity feature introduces the following REQUIRED property for
version
Clemm, et al. Standards Track [Page 92]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.2.1 DAV:activity-
This property identifies the activities that determine to
logical changes this version contributes, and on which lines
descent this version appears. A server MAY restrict
DAV:activity-set to identify a single activity. A server MAY
to allow the value of the DAV:activity-set property of a version
be modified
activity-set (href*)>
13.3 Additional Checked-Out Resource
The activity feature introduces the following REQUIRED properties
a checked-out resource
13.3.1 DAV:
This property of a checked-out resource indicates whether
DAV:activity-set of another checked-out resource associated with
version history of this version-controlled resource can have
activity that is in the DAV:activity-set property of this checked-
resource
A result of the requirement that an activity must form a single
of descent through a given version history is that if
checked-out resources for a given version history are checked
unreserved into a single activity, only the first CHECKIN
succeed. Before another of these checked-out resources can
checked in, the user will first have to merge into that checked-
resource the latest version selected by that activity from
version history, and then modify the DAV:predecessor-set of
checked-out resource to identify that version
PCDATA value:
13.3.2 DAV:activity-
This property of a checked-out resource determines the DAV:activity
set property of the version that results from checking in
resource
13.4 Additional Workspace
The activity feature introduces the following REQUIRED property for
workspace
Clemm, et al. Standards Track [Page 93]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.4.1 DAV:current-activity-
This property identifies the activities that currently are
performed in this workspace. When a member of this workspace
checked out, if no activity is specified in the checkout request,
DAV:current-activity-set will be used. This allows an activity
unaware client to update a workspace in which activity tracking
required. The DAV:current-activity-set MAY be restricted to
at most one activity
activity-set (href*)>
13.5 MKACTIVITY
A MKACTIVITY request creates a new activity resource. A server
restrict activity creation to particular collections, but a
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
element
If a response body for a successful request is included, it
be a DAV:mkactivity-response XML element
response ANY
The response MUST include a Cache-Control:no-cache header
Preconditions
(DAV:resource-must-be-null): A resource MUST NOT exist at
request-URL
(DAV:activity-location-ok): The request-URL MUST identify
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
Clemm, et al. Standards Track [Page 94]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.5.1 Example -
>>
MKACTIVITY /act/test-23 HTTP/1.1
Host: repo.webdav.
Content-Length: 0
>>
HTTP/1.1 201
Cache-Control: no-
In this example, a new activity is created
http://repo.webdav.org/act/test-23.
13.6 DAV:latest-activity-version
The DAV:latest-activity-version report can be applied to a
history to identify the latest version that is selected from
version history by a given activity
Marshalling
The request body MUST be a DAV:latest-activity-version
element
activity-version (href)>
The response body for a successful request MUST be a DAV:latest
activity-version-report XML element
activity-version-report (href)>
The DAV:href of the response body MUST identify the version of
given version history that is a member of the DAV:activity
version-set of the given activity and has no descendant that is
member of the DAV:activity-version-set of that activity
Preconditions
(DAV:must-be-activity): The DAV:href in the request body
identify an activity
Clemm, et al. Standards Track [Page 95]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.7 Additional OPTIONS
If the server supports the activity feature, it MUST
"activity" as a field in the DAV response header from an
request on any resource that supports any versioning properties
reports, or methods
A DAV:activity-collection-set element MAY be included in the
body to identify collections that may contain activity resources
Additional Marshalling
If an XML request body is included, it MUST be a DAV:options
element
ANY value: A sequence of elements with at most
DAV:activity-collection-set element
If an XML response body for a successful request is included,
MUST be a DAV:options-response XML element
response ANY
ANY value: A sequence of elements with at most
DAV:activity-collection-set 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
DAV:activity-collection-set element identifying collections
may contain activities. An identified collection MAY be the
collection of a tree of collections, all of which may
activities. Since different servers can control different
of the URL namespace, different resources on the same host
have different DAV:activity-collection-set values. The
collections MAY be located on different hosts from the resource
13.8 Additional DELETE
Additional Postconditions
(DAV:delete-activity-reference): If an activity is deleted,
reference to that activity in a DAV:activity-set
DAV:subactivity-set, or DAV:current-activity-set MUST be removed
Clemm, et al. Standards Track [Page 96]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.9 Additional MOVE
Additional Postconditions
(DAV:update-checked-out-reference): If a checked-out resource
moved, any reference to that resource in a DAV:activity-checkout
set property MUST be updated to refer to the new location of
resource
(DAV:update-activity-reference): If the request-URL identifies
activity, any reference to that activity in a DAV:activity-set
DAV:subactivity-set, or DAV:current-activity-set MUST be
to refer to the new location of that activity
(DAV:update-workspace-reference): If the request-URL identifies
workspace, any reference to that workspace in a DAV:current
workspace-set property MUST be updated to refer to the
location of that workspace
13.10 Additional CHECKOUT
A CHECKOUT request MAY specify the DAV:activity-set for the checked
out resource
Additional Marshalling
ANY value: A sequence of elements with
most one DAV:activity-set and at most one DAV:unreserved
activity-set (href+ | new)>
Additional Preconditions
(DAV:one-checkout-per-activity-per-history): If there is a
activity set, unless DAV:unreserved is specified, another
from a version of that version history MUST NOT select an
in that activity set
(DAV:linear-activity): If there is a request activity set,
DAV:unreserved is specified, the selected version MUST be
descendant of all other versions of that version history
select that activity
Clemm, et al. Standards Track [Page 97]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions
(DAV:initialize-activity-set): The DAV:activity-set of
checked-out resource is set as follows
- If DAV:new is specified as the DAV:activity-set in the
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
workspace and the DAV:current-activity-set of the workspace
set, then those activities are used
- Otherwise, the DAV:activity-set of the DAV:checked-out
is used
(DAV:initialize-unreserved): If DAV:unreserved was specified
the request body, then the DAV:unreserved property of
checked-out resource MUST be "true".
13.10.1 Example - CHECKOUT with an
>>
CHECKOUT /ws/public/foo.html HTTP/1.1
Host: www.webdav.
Content-Type: text/xml; charset="utf-8"
Content-Length:
encoding="utf-8" ?>
activity-set
http://repo.webdav.org/act/fix-bug-23
activity-set
>>
HTTP/1.1 200
Cache-Control: no-
In this example, the CHECKOUT is being performed in
http://repo.webdav.org/act/fix-bug-23 activity
Clemm, et al. Standards Track [Page 98]
RFC 3253 Versioning Extensions to WebDAV March 2002
13.11 Additional CHECKIN
Additional Preconditions
(DAV:linear-activity): Any version which is in the version
of the checked-out resource and whose DAV:activity-set
an activity from the DAV:activity-set of the checked-out
MUST be an ancestor of the checked-out resource
(DAV:atomic-activity-checkin): If the request-URL identifies
activity, the server MAY fail the request if any of the checked
out resources in the DAV:activity-checkout-set of either
activity or any subactivity of that activity cannot be checked in
Additional Postconditions
(DAV:initialize-activity-set): The DAV:activity-set of the
version MUST have been initialized to be the same as
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
each checked-out resource in the DAV:activity-checkout-set of
that activity and any subactivity of that activity
13.12 Additional MERGE
If the DAV:source element of the request body identifies an activity
then for each version history containing a version selected by
activity, the latest version selected by that activity is a
source. Note that the versions selected by an activity are
versions in its DAV:activity-version-set unioned with the
selected by the activities in its DAV:subactivity-set
Additional Marshalling
activity EMPTY
Additional Postconditions
(DAV:checkin-activity): If DAV:checkin-activity is specified
the request body, and if the DAV:source element in the
body identifies an activity, a CHECKIN request MUST have
successfully applied to that activity before the merge
were determined
Clemm, et al. Standards Track [Page 99]
RFC 3253 Versioning Extensions to WebDAV March 2002
14 Version-Controlled-Collection
As with any versionable resource, when a collection is put
version control, a version history resource is created to
versions for that version-controlled collection. In order
preserve standard versioning semantics (a version of a
should not be modifiable), a collection version only
information about the version-controlled bindings of that collection
In order to cleanly separate a modification to the namespace from
modification to content or dead properties, a version of a
has no members, but instead records in its DAV:version-controlled
binding-set property the binding name and version history resource
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
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
members, a new version of /x/y would have to be created to
the new version of /x/y/a.html, and a new version of /x would have
be created to contain the new version of /x/y. Now suppose
"bugfix-47" activity created a new version of /x/z/b.html. Again,
new version of /x/z and a new version of /x would have to be
to contain the new version of /x/y/b.html. But now it is
to merge just "bugfix-47" into another workspace without "feature
12", because the version of /x that contains the desired version
/x/z/b.html also contains version of /x/y/a.html created
"feature-12". If, instead, a collection version just records
binding name and version history resource of each version-
internal member, changing the version selected by a member of
collection would not require a new version of the collection.
new version is still in the same version history so no new
version is required, and "feature-12" and "bugfix-47" would
become entangled
In the following example, there are three version histories,
VH14, VH19, and VH24, where VH14 contains versions of a collection
The version-controlled collection /x has version V2 of
history VH14 as its DAV:checked-in version. Since V2 has
two version controlled bindings, one with binding name "a" to
history VH19, and the other with binding name "b" to version
VH24, /x MUST have two version-controlled bindings, one named "a"
a version-controlled resource for history VH19, and the other
"b" to a version-controlled resource for history VH24. The version
Clemm, et al. Standards Track [Page 100]
RFC 3253 Versioning Extensions to WebDAV March 2002
controlled resource /x/a currently has V4 of VH19 as
DAV:checked-in version, while /x/b has V8 of VH24 as
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,
request MUST fail unless the version-controlled collection has
DAV:auto-version property that will automatically check out
version-controlled collection when it is modified
Although a collection version only records the version-
bindings of a collection, a version-controlled collection MAY
both version-controlled and non-version-controlled bindings. Non
Clemm, et al. Standards Track [Page 101]
RFC 3253 Versioning Extensions to WebDAV March 2002
version-controlled bindings are not under version control,
therefore can be added or deleted without checking out the version
controlled collection
Note that a collection version captures only a defined subset of
state of a collection. In particular, a version of a
captures its dead properties and its bindings to version-
resources, but not its live properties or bindings to non-version
controlled resources
When a server supports the working-resource feature, a client
check out a collection version to create a working collection
Unlike a version-controlled collection, which contains bindings
version-controlled resources and non-version-controlled resources,
working collection contains bindings to version history resources
non-version-controlled resources. In particular, a
collection is initialized to contain bindings to the version
resources specified by the DAV:version-controlled-binding-set of
checked out collection version. The members of a working
can then be deleted or moved to another working collection. Non
version-controlled resources can be added to a working
with methods such as PUT, COPY, and MKCOL. When a working
is checked in, a VERSION-CONTROL request is automatically applied
every non-version-controlled member of the working collection,
each non-version-controlled member is replaced by its newly
version history. The DAV:version-controlled-binding-set of the
version resulting from checking in a working collection contains
binding name and version history URL for each member of the
collection
14.1 Version-Controlled Collection
A version-controlled collection has all the properties of
collection and of a version-controlled resource. In addition,
version-controlled-collection feature introduces the
REQUIRED property for a version-controlled collection
14.1.1 DAV:eclipsed-set (computed
This property identifies the non-version-controlled internal
of the collection that currently are eclipsing a version-
internal member of the collection
!ELEMENT eclipsed-set (binding-name*)>
PCDATA value: URL
Clemm, et al. Standards Track [Page 102]
RFC 3253 Versioning Extensions to WebDAV March 2002
An UPDATE or MERGE request can give a version-controlled collection
version-controlled internal member that has the same name as
existing non-version-controlled internal member. In this case,
non-version-controlled internal member takes precedence and is
to "eclipse" the new versioned-controlled internal member. If
non-version-controlled internal member is removed (e.g., by a
or MOVE), the version-controlled internal member is exposed
14.2 Collection Version
A collection version has all the properties of a version.
addition, the version-controlled-collection feature introduces
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
controlled-binding-
(version-controlled-binding*)>
controlled-
(binding-name, version-history)>
PCDATA value: URL
14.3 Additional OPTIONS
If the server supports the version-controlled-collection feature,
MUST include "version-controlled-collection" as a field in the
response header from an OPTIONS request on any resource that
any versioning properties, reports, or methods
14.4 Additional DELETE
Additional Preconditions
(DAV:cannot-modify-checked-in-parent): If the request-
identifies a version-controlled resource, the DELETE MUST
when the collection containing the version-controlled resource
a checked-in version-controlled collection, unless DAV:auto
version semantics will automatically check out the version
controlled collection
Clemm, et al. Standards Track [Page 103]
RFC 3253 Versioning Extensions to WebDAV March 2002
14.5 Additional MKCOL
Additional Preconditions
If the request creates a new resource that is automatically
under version control, all preconditions for VERSION-CONTROL
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
Additional Preconditions
(DAV:cannot-copy-collection-version): If the source of the
is a collection version, the request MUST fail
14.7 Additional MOVE
Additional Preconditions
(DAV:cannot-modify-checked-in-parent): If the source of
request is a version-controlled resource, the request MUST
when the collection containing the source is a checked-
version-controlled collection, unless DAV:auto-version
will automatically check out that version-controlled collection
(DAV:cannot-modify-destination-checked-in-parent): If the
of the request is a version-controlled resource, the request
fail when the collection containing the destination is a checked
in version-controlled collection, unless DAV:auto-
semantics will automatically check out that version-
collection
14.8 Additional VERSION-CONTROL
Additional Preconditions
(DAV:cannot-modify-checked-in-parent): If the parent of
request-URL is a checked-in version-controlled collection,
request MUST fail unless DAV:auto-version semantics
automatically check out that version-controlled collection
Clemm, et al. Standards Track [Page 104]
RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions
(DAV:new-version-controlled-collection): If the request
identified a collection version, the collection at the request-
MUST contain a version-controlled internal member for
DAV:version-controlled-binding specified in the DAV:version
controlled-binding-set of the collection version, where the
and DAV:version-history of the internal member MUST be
DAV:binding-name and the DAV:version-history specified by
DAV:version-controlled-binding. If the internal member is
member of a workspace, and there is another member of
workspace for the same version history, those two members
identify the same version-controlled resource; otherwise,
VERSION-CONTROL request with a server selected version of
version history MUST have been applied to the URL for
internal member
14.9 Additional CHECKOUT
Additional Postconditions
(DAV:initialize-version-history-bindings): If the request has
applied to a collection version, the new working collection
be initialized to contain a binding to each of the
resources identified in the DAV:version-controlled-binding-set
that collection version
14.10 Additional CHECKIN
Additional Postconditions
(DAV:initialize-version-controlled-bindings): If the request-
identified a version-controlled collection, then the DAV:version
controlled-binding-set of the new collection version MUST
a DAV:version-controlled-binding that identifies the binding
and version history for each version-controlled binding of
version- controlled collection
(DAV:version-control-working-collection-members): If the request
URL identified a working collection, a VERSION-CONTROL
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
created version history. If a working collection member was
non-version-controlled collection, every member of the non
version-controlled collection MUST have been placed under
Clemm, et al. Standards Track [Page 105]
RFC 3253 Versioning Extensions to WebDAV March 2002
control before the non-version-controlled collection was
under version control. The DAV:version-controlled-binding-set
the new collection version MUST contain a DAV:version-controlled
binding that identifies the binding name and the version
URL for each member of the working collection
14.11 Additional UPDATE and MERGE
Additional Postconditions
(DAV:update-version-controlled-collection-members): If the
modified the DAV:checked-in version of a version-
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
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
history MUST have been renamed if its binding name differs
the DAV:binding-name for that version history in
DAV:version-controlled-binding-set of the new DAV:checked-
version
- A new version-controlled internal member MUST have been
when a version history is identified by the DAV:version
controlled-binding-set of the DAV:checked-in version, but
was no member of the version-controlled collection for
version history. If a new version-controlled member is in
workspace that already has a version-controlled resource
that version history, then the new version-controlled
MUST be just a binding (i.e., another name for) that
version-controlled resource. Otherwise, the content and
properties of the new version-controlled member MUST have
initialized to be those of the version specified for
version history by the request. If no version is specified
that version history by the request, the version selected
server defined
15 Internationalization
This specification has been designed to be compliant with the
Policy on Character Sets and Languages [RFC2277]. Specifically
where human-readable strings exist in the protocol, either
charset is explicitly stated, or XML mechanisms are used to
the charset used. Additionally, these human-readable strings
have the ability to express the natural language of the string
Clemm, et al. Standards Track [Page 106]
RFC 3253 Versioning Extensions to WebDAV March 2002
Most of the human-readable strings in this protocol appear
properties, such as DAV:creator-displayname. As defined by RFC 2518,
properties have their values marshaled as XML. XML has
provisions for character set tagging and encoding, and requires
XML processors read XML elements encoded, at minimum, using the UTF-8
[RFC2279] encoding of the ISO 10646 multilingual plane. The
parameter of the Content-Type header, together with the
"encoding" attribute, provide charset identification information
MIME and XML processors. Proper use of the charset header with
is described in RFC 3023. XML also provides a language
capability for specifying the language of the contents of
particular XML element. XML uses either IANA registered
tags (see RFC 3066) or ISO 639 language tags in the "xml:lang
attribute of an XML element to identify the language of its
and attributes
DeltaV applications, since they build upon WebDAV, are subject to
internationalization requirements specified in RFC 2518, Section 16.
In brief, these requirements mandate the use of XML character
tagging, character set encoding, and language tagging capabilities
Additionally, they strongly recommend reading RFC 3023
instruction on the use of MIME media types for XML transport and
use of the charset header
Within this specification, a label is a human-readable string that
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-
and encoded using UTF-8.
16 Security
All of the security considerations of WebDAV discussed in RFC 2518,
Section 17 also apply to WebDAV versioning. Some aspects of
versioning protocol help address security risks introduced by WebDAV
but other aspects can increase these security risks. These
are detailed below
16.1 Auditing and
WebDAV increases the ease with which a remote client can
resources on a web site, but this also increases the risk
important information being overwritten and lost, either through
error or user maliciousness. The use of WebDAV versioning can
address this problem by guaranteeing that previous information
saved in the form of immutable versions, and therefore is
available for retrieval or restoration. In addition, the
history provides a log of when changes were made, and by whom.
requests are appropriately authenticated, the history
Clemm, et al. Standards Track [Page 107]
RFC 3253 Versioning Extensions to WebDAV March 2002
provides a clear audit trail for changes to web resources. This
often significantly improve the ability to identify the source of
security problem, and thereby help guard against it in the future
16.2 Increased Need for Access
WebDAV versioning provides a variety of links between related
of information. This can increase the risk that authentication
authorization errors allow a client to locate sensitive information
For example, if version history is not appropriately protected
access control, a client can use the version history of a
resource to identify later versions of that resource that the
intended to keep private. This increases the need for
authentication and accurate authorization
A WebDAV versioning client should be designed to handle a mixture
200 (OK) and 403 (Forbidden) responses on attempts to access
properties and reports that are supported by a resource.
example, a particular user may be authorized to access the
and dead properties of a version-controlled resource, but not
authorized to access the DAV:checked-in, DAV:checked-out,
DAV:version-history properties of that resource
16.3 Security Through
While it is acknowledged that "obscurity" is not an effective
of security, it is often a good technique to keep honest
honest. Within this protocol, version URLs, version history URLs
and working resource URLs are generated by the server and can
properly obfuscated so as not to draw attention to them.
example, a version of "http://foobar.com/reviews/salaries.html"
be assigned a URL such as "http://foobar.com/repo/4934943".
16.4 Denial of
The auto-versioning mechanism provided by WebDAV can result in
large number of resources being created on the server, since
update to a resource could potentially result in the creation of
new version resource. This increases the risk of a denial of
attack that exhausts the storage capability of a server. This
is especially significant because it can be an unintentional
of something like an aggressive auto-save feature provided by
editing client. A server can decrease this risk by using
storage techniques to minimize the cost of additional versions,
by limiting auto-versioning to a locking client, and
decreasing the number of inadvertent version creations
Clemm, et al. Standards Track [Page 108]
RFC 3253 Versioning Extensions to WebDAV March 2002
17 IANA
This document uses the namespace defined by RFC 2518 for
elements. All other IANA considerations from RFC 2518 are
applicable to WebDAV Versioning
18 Intellectual
The following notice is copied from RFC 2026, Section 10.4,
describes the position of the IETF concerning intellectual
claims made against this document
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use other technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
procedures of the IETF with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights that may cover technology that may be required to
this standard. Please address the information to the IETF
Director
19
This protocol is the collaborative product of the authors and
rest of the DeltaV design team: Boris Bokowski, Bruce
(Novell), Jim Doubek (Macromedia), David Durand (INSO),
Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark
(Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI),
Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi),
Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John
(Rational). We would like to acknowledge the foundation laid for
by the authors of the WebDAV and HTTP protocols upon which
protocol is layered, and the invaluable feedback from the WebDAV
DeltaV working groups
Clemm, et al. Standards Track [Page 109]
RFC 3253 Versioning Extensions to WebDAV March 2002
20
[ISO639] ISO, "Code for the representation of names of languages",
ISO 639:1988, 1998.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets
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, "
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
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.
Clemm, et al. Standards Track [Page 110]
RFC 3253 Versioning Extensions to WebDAV March 2002
Appendix A - Resource
This document introduces several different kinds of
resources, such as version-controlled resources, versions, checked
out resources, and version history resources. As clients
resources on a server, they may find it useful to classify
resources (for example, to make UI decisions on choice of icon
menu options).
Clients should classify a resource by examining the values of
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
for each kind of versioning resource. Where an optional
introduces a new kind of versioning resource, that feature is
in parentheses following the name of that kind of
resource. If a live property or method is optional for a kind
versioning resource, the feature that introduces that live
or method is noted in parentheses following the live property
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
Supported live properties
- DAV:
- DAV:creator-
- DAV:supported-method-
- DAV:supported-live-property-
- DAV:supported-report-
- all properties defined in WebDAV [RFC2518].
Clemm, et al. Standards Track [Page 111]
RFC 3253 Versioning Extensions to WebDAV March 2002
Supported methods
-
- all methods defined in WebDAV [RFC2518]
- all methods defined in HTTP/1.1 [RFC2616].
A.3 DeltaV-Compliant
Supported live properties
- all DeltaV-compliant resource properties
Supported methods
- BASELINE-CONTROL (baseline
- all DeltaV-compliant resource methods
A.4 Versionable
Supported live properties
- DAV:workspace (workspace
- DAV:version-controlled-configuration (baseline
- all DeltaV-compliant resource properties
Supported methods
- VERSION-
- all DeltaV-compliant resource methods
A.5 Version-Controlled
Supported live properties
- DAV:auto-
- DAV:version-history (version-history
- DAV:workspace (workspace
- DAV:version-controlled-configuration (baseline
- all DeltaV-compliant resource properties
Supported methods
- VERSION-
- MERGE (merge
- all DeltaV-compliant resource methods
Clemm, et al. Standards Track [Page 112]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.6
Supported live properties
- DAV:predecessor-
- DAV:successor-
- DAV:checkout-
- DAV:version-
- 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
Supported live properties
- DAV:checked-
- all version-controlled resource properties
Supported methods
- CHECKOUT (checkout-in-place
- UPDATE (update
- all version-controlled resource methods
A.8 Checked-Out
Supported live properties
- DAV:checked-
- DAV:predecessor-
- 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
Clemm, et al. Standards Track [Page 113]
RFC 3253 Versioning Extensions to WebDAV March 2002
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
-
- all version-controlled resource methods
- all checked-out resource methods
A.10 Working Resource (working-resource
Supported live properties
- all DeltaV-compliant resource
- all checked-out resource
- DAV:auto-update
Supported methods
- all checked-out resource methods
A.11 Version History (version-history
Supported live properties
- DAV:version-
- DAV:root-
- all DeltaV-compliant resource properties
Supported methods
- all DeltaV-compliant resource methods
Clemm, et al. Standards Track [Page 114]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.12 Workspace (workspace
Supported live properties
- DAV:workspace-checkout-
- 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-
- DAV:activity-checkout-
- DAV:subactivity-
- DAV:current-workspace-
- 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-
- 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-
- all version properties
Supported methods
- all version methods
Clemm, et al. Standards Track [Page 115]
RFC 3253 Versioning Extensions to WebDAV March 2002
A.16 Version-Controlled Configuration (baseline
Supported live properties
- DAV:baseline-controlled-
- all version-controlled resource properties
Supported methods
- all version-controlled resource methods
A.17 Baseline (baseline
Supported live properties
- DAV:baseline-
- DAV:subbaseline-
- all version properties
Supported methods
- all version methods
A.18 Checked-Out Version-Controlled Configuration (baseline
Supported live properties
- DAV:subbaseline-
- all version-controlled configuration properties
Supported methods
- all version-controlled configuration methods
Clemm, et al. Standards Track [Page 116]
RFC 3253 Versioning Extensions to WebDAV March 2002
Authors'
Geoffrey
Rational
20 Maguire Road, Lexington, MA 02421
EMail: geoffrey.clemm@rational.
Jim
3039 Cornwallis, Research Triangle Park, NC 27709
EMail: jamsden@us.ibm.
Tim
Hursley Park, Winchester, UK S021 2
EMail: tim_ellison@uk.ibm.
Christopher
One Microsoft Way, Redmond, WA 90852
EMail: ckaler@microsoft.
Jim
UC Santa Cruz, Dept. of Computer
1156 High Street, Santa Cruz, CA 95064
EMail: ejw@cse.ucsc.
Clemm, et al. Standards Track [Page 117]
RFC 3253 Versioning Extensions to WebDAV March 2002
Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Clemm, et al. Standards Track [Page 118]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
