Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

To maximize interoperability and the use of existing protocol functionality, versioning support is designed as extensions to the WebDAV protocol [RFC2518], which itself is an extension to the HTTP protocol [RFC2616]. All method marshalling and postconditions defined by RFC 2518 and RFC 2616 continue to hold, to ensure that versioning unaware clients can interoperate successfully with versioning servers. Although the versioning extensions are designed to be orthogonal to most aspects of the WebDAV and HTTP protocols, a clarification to RFC 2518 is required for effective interoperable versioning. This clarification is described in Section 1.7.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.¶

The term "protected" is placed in parentheses following the definition of a protected property (see Section 1.4.2).¶

The term "computed" is placed in parentheses following the definition of a computed property (see Section 1.4.3).¶

When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type.¶

When a method is defined in this document, a list of preconditions and postconditions will be defined for that method. If the semantics of an existing method is being extended, a list of additional preconditions and postconditions will be defined. A precondition or postcondition is prefixed by a parenthesized XML element type that identifies that precondition or postcondition (see Section 1.6).¶

This document uses the terms defined in RFC 2616, in RFC 2518, and in this section. Section 2.2 defines the semantic versioning model underlying this terminology.¶

Version Control, Checked-In, Checked-Out ¶

• "Version control" is a set of constraints on how a resource can be updated. A resource under version control is either in a "checked-in" or "checked-out" state, and the version control constraints apply only while the resource is in the checked-in state.

Versionable Resource ¶

• A "versionable resource" is a resource that can be put under version control.

Version-Controlled Resource ¶

• When a versionable resource is put under version control, it becomes a "version-controlled resource". A version-controlled resource can be "checked out" to allow modification of its content or dead properties by standard HTTP and WebDAV methods.

Checked-Out Resource ¶

• A "checked-out resource" is a resource under version control that is in the checked-out state.

Version Resource ¶

• A "version resource", or simply "version", is a resource that contains a copy of a particular state (content and dead properties) of a version-controlled resource. A version is created by "checking in" a checked-out resource. The server allocates a distinct new URL for each new version, and this URL will never be used to identify any resource other than that version. The content and dead properties of a version never change.

Version History Resource ¶

• A "version history resource", or simply "version history", is a resource that contains all the versions of a particular version-controlled resource.

Version Name ¶

• A "version name" is a string chosen by the server to distinguish one version of a version history from the other versions of that version history. Versions from different version histories may have the same version name.

Predecessor, Successor, Ancestor, Descendant ¶

• When a version-controlled resource is checked out and then subsequently checked in, the version that was checked out becomes a "predecessor" of the version created by the checkin. A client can specify multiple predecessors for a new version if the new version is logically a merge of those predecessors. When a version is connected to another version by traversing one or more predecessor relations, it is called an "ancestor" of that version. The inverse of the predecessor and ancestor relations are the "successor" and "descendant" relations. Therefore, if X is a predecessor of Y, then Y is a successor of X, and if X is an ancestor of Y, then Y is a descendant of X.

Root Version Resource ¶

• The "root version resource", or simply "root version", is the version in a version history that is an ancestor of every other version in that version history.

Workspace Resource ¶

• A "workspace resource", or simply "workspace", is a collection that contains at most one version-controlled resource for a given version history (see Section 6).

Working Resource ¶

• A "working resource" is a checked-out resource created by the server at a server-defined URL when a version (instead of a version-controlled resource) is checked out. Unlike a checked-out version-controlled resource, a working resource is deleted when it is checked in.

Fork, Merge ¶

• When a second successor is added to a version, this creates a "fork" in the version history. When a version is created with multiple predecessors, this creates a "merge" in the version history. A server may restrict the version history to be linear (with no forks or merges), but an interoperable versioning client should be prepared to deal with both forks and merges in the version history.

The following diagram illustrates several of the previous definitions. Each box represents a version and each line between two boxes represents a predecessor/successor relationship. For example, it shows V3 is a predecessor of V5, V7 is a successor of V5, V1 is an ancestor of V4, and V7 is a descendant of V4. It also shows that there is a fork at version V2 and a merge at version V7.¶

History of foo.html

                 

                         ┌───┐
   Root Version -------> │   │ V1
                         └───┘           ^
                           |             |
                           |             |
                         ┌───┐           |
   Version Name ----> V2 │   │           | Ancestor
                         └───┘           |
                         /    \          |
                        /      \         |
                   ┌───┐       ┌───┐
                   │   │ V3    │   │ V4
                ^  └───┘       └───┘
                |    |           |       |
   Predecessor  |    |           |       |
                   ┌───┐       ┌───┐     |
                   │   │ V5    │   │ V6  | Descendant
                   └───┘       └───┘     |
   Successor    |       \      /         |
                |        \    /          |
                v        ┌───┐           v
                         │   │ V7
                         └───┘

Label ¶

• A "label" is a name that can be used to select a version from a version history. A label can be assigned by either a client or the server. The same label can be used in different version histories.

Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC.¶

A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed. If a method precondition or postcondition for a request is not satisfied, the response status of the request MUST be either 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request.¶

In order to allow better client handling of 403 and 409 responses, a distinct XML element type is associated with each method precondition and postcondition of a request. When a particular precondition is not satisfied or a particular postcondition cannot be achieved, the appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body, unless otherwise negotiated by the request. In a 207 Multi-Status response, the DAV:error element would appear in the appropriate DAV:responsedescription element.¶

"If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource."¶

The purpose of this sentence is to ensure that following a COPY, all destination resources have the same content and dead properties as the corresponding resources identified by the request-URL (where a resource with a given name relative to the Destination URL "corresponds" to a resource with the same name relative to the request-URL). If at the time of the request, there already is a resource at the destination that has the same resource type as the corresponding resource at the request-URL, that resource MUST NOT be deleted, but MUST be updated to have the content and dead properties of its corresponding member. If a client wishes all resources at the destination to be deleted prior to the COPY, it MUST explicitly issue a DELETE request.¶

The difference between updating a resource and replacing a resource with a new resource is especially important when resource history is being maintained (the former adds to an existing history, while the latter creates a new history). In addition, locking and access control constraints might allow you to update a resource, but not allow you to delete it and create a new one in its place.¶

Note that this clarification does not apply to a MOVE request. A MOVE request with Overwrite:T MUST perform the DELETE with "Depth:infinity" on the destination resource prior to performing the MOVE.¶

If a write-locked resource has a non-computed property defined by this document, the property value MUST NOT be changed by a request unless the appropriate lock token is included in the request. Since every method introduced in this document other than REPORT modifies at least one property defined by this document, every versioning method other than REPORT is affected by a write lock. In particular, the method MUST fail with a 423 (Locked) status if the resource is write-locked and the appropriate token is not specified in an If request header.¶

• Core-Versioning Package: version-control
• Basic-Server-Workspace Package: version-control, workspace, version-history, checkout
• Basic-Client-Workspace Package: version-control, working-resource, update, label

The core-versioning package supports linear versioning by both versioning-aware and versioning-unaware clients. A versioning-aware client can use reports and properties to access previous versions of a version-controlled resource.¶

The basic workspace packages support parallel development of version-controlled resources. Each client has its own configuration of the shared version-controlled resources, and can make changes to its configuration without disturbing that of another client.¶

In the basic-server-workspace package, all persistent state is maintained on the server. Each client has its own workspace resource allocated on the server, where each workspace identifies a configuration of the shared version-controlled resources. Each client makes changes to its workspace, and can transfer changes when appropriate from one workspace to another. The server workspace package is appropriate for clients with no local persistent state, or for clients that wish to expose their working configurations to other clients.¶

In the basic-client-workspace package, each client maintains in local persistent storage the state for its configuration of the shared version-controlled resources. When a client is ready to make its changes visible to other clients, it allocates a set of "working resources" on the server, updates the content and dead properties of these working resources, and then uses the set of working resources to update the version-controlled resources. The working resources are used, instead of directly updating the version-controlled resources, so that sets of consistent updates can be prepared in parallel by multiple clients. Also, a working resource allows a client to prepare a single update that requires multiple server requests (e.g. updating both the content and dead properties of a resource requires both a PUT and a PROPPATCH). The client workspace package simplifies the server implementation by requiring each client to maintain its own namespace, but this requires that the clients have local persistent state, and does not allow clients to expose their working configurations to other clients.¶

A server that supports both basic workspace packages will interoperate with all basic versioning clients.¶

The version-control feature introduces the following REQUIRED properties for any WebDAV resource.¶

The version-control feature introduces the following REQUIRED properties for a version-controlled resource.¶

The version-control feature introduces the following REQUIRED properties for a checked-out resource.¶

The version-control feature introduces the following REQUIRED properties for a version.¶

A VERSION-CONTROL request can be used to create a version-controlled resource at the request-URL. It can be applied to a versionable resource or to a version-controlled resource.¶

If the request-URL identifies a versionable resource, a new version history resource is created, a new version is created whose content and dead properties are copied from the versionable resource, and the resource is given a DAV:checked-in property that is initialized to identify this new version.¶

If the request-URL identifies a version-controlled resource, the resource just remains under version-control. This allows a client to be unaware of whether or not a server automatically puts a resource under version control when it is created.¶

If a VERSION-CONTROL request fails, the server state preceding the request MUST be restored.¶

Marshalling: ¶

• If a request body is included, it MUST be a DAV:version-control XML element.

  <!ELEMENT version-control ANY>
  

• If a response body for a successful request is included, it MUST be a DAV:version-control-response XML element. Note that this document does not define any elements for the VERSION-CONTROL response body, but the DAV:version-control-response element is defined to ensure interoperability between future extensions that do define elements for the VERSION-CONTROL response body.

  <!ELEMENT version-control-response ANY>
  

Postconditions: ¶

• (DAV:put-under-version-control): If the request-URL identified a versionable resource at the time of the request, the request MUST have created a new version history and MUST have created a new version resource in that version history. The resource MUST have a DAV:checked-in property that identifies the new version. The content, dead properties, and DAV:resourcetype of the new version MUST be the same as those of the resource. Note that an implementation can choose to locate the version history and version resources anywhere that it wishes. In particular, it could locate them on the same host and server as the version-controlled resource, on a different virtual host maintained by the same server, on the same host maintained by a different server, or on a different host maintained by a different server.
• (DAV:must-not-change-existing-checked-in-out): If the request-URL identified a resource already under version control at the time of the request, the request MUST NOT change the DAV:checked-in or DAV:checked-out property of that version-controlled resource.

A REPORT request is an extensible mechanism for obtaining information about a resource. Unlike a resource property, which has a single value, the value of a report can depend on additional information specified in the REPORT request body and in the REPORT request headers.¶

Marshalling: ¶

• The body of a REPORT request specifies which report is being requested, as well as any additional information that will be used to customize the report.
• The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed.
• The response body for a successful request MUST contain the requested report.
• If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource.

Preconditions: ¶

• (DAV:supported-report): The specified report MUST be supported by the resource identified by the request-URL.

Postconditions: ¶

• (DAV:no-modification): The REPORT method MUST NOT have changed the content or dead properties of any resource.

The DAV:version-tree report describes the requested properties of all the versions in the version history of a version. If the report is requested for a version-controlled resource, it is redirected to its DAV:checked-in or DAV:checked-out version.¶

The DAV:version-tree report MUST be supported by all version resources and all version-controlled resources.¶

Marshalling: ¶

• The request body MUST be a DAV:version-tree XML element.

  <!ELEMENT version-tree ANY>
  ANY value: a sequence of zero or more elements, with at most one
  DAV:prop element.
  prop: see RFC 2518, Section 12.11
  

• The response body for a successful request MUST be a DAV:multistatus XML element.

  multistatus: see RFC 2518, Section 12.9
  

• The response body for a successful DAV:version-tree REPORT request MUST contain a DAV:response element for each version in the version history of the version identified by the request-URL.

Many property values are defined as a DAV:href, or a set of DAV:href elements. The DAV:expand-property report provides a mechanism for retrieving in one request the properties from the resources identified by those DAV:href elements. This report not only decreases the number of requests required, but also allows the server to minimize the number of separate read transactions required on the underlying versioning store.¶

The DAV:expand-property report SHOULD be supported by all resources that support the REPORT method.¶

Marshalling: ¶

• The request body MUST be a DAV:expand-property XML element.

  <!ELEMENT expand-property (property*)>
  <!ELEMENT property (property*)>
  <!ATTLIST property name NMTOKEN #REQUIRED>
  name value: a property element type
  <!ATTLIST property namespace NMTOKEN "DAV:">
  namespace value: an XML namespace
  

• The response body for a successful request MUST be a DAV:multistatus XML element.

  multistatus: see RFC 2518, Section 12.9
  

• The properties reported in the DAV:prop elements of the DAV:multistatus element MUST be those identified by the DAV:property elements in the DAV:expand-property element. If there are DAV:property elements nested within a DAV:property element, then every DAV:href in the value of the corresponding property is replaced by a DAV:response element whose DAV:prop elements report the values of the properties identified by the nested DAV:property elements. The nested DAV:property elements can in turn contain DAV:property elements, so that multiple levels 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 by replacing every occurrence of "href" in the DTD with "href | response".

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

Additional Preconditions: ¶

• (DAV:cannot-modify-version-controlled-content): If the request-URL identifies a resource with a DAV:checked-in property, the request MUST fail unless DAV:auto-version semantics will automatically check out the resource.
• (DAV:cannot-modify-version): If the request-URL identifies a version, the request MUST fail.
• If the request creates a new resource that is automatically placed under version control, all preconditions for VERSION-CONTROL apply to the request.

Additional Postconditions: ¶

• (DAV:auto-checkout): If the resource was a checked-in version-controlled resource whose DAV:auto-version property indicates it should be automatically checked out but not automatically checked in for a modification request, then the server MUST have automatically checked out the resource prior to executing the request. In particular, the value of the DAV:checked-out property of the resource MUST be that of the DAV:checked-in property prior to the request, the DAV:checked-in property MUST have been removed, and the DAV:predecessor-set property MUST be initialized to be the same as the DAV:checked-out property. If any part of the checkout/update sequence failed, the status from the failed part of the request MUST be returned, and the server state preceding the request sequence MUST be restored.
• (DAV:auto-checkout-checkin): If the resource was a checked-in version-controlled resource whose DAV:auto-version property indicates it should be automatically checked out and automatically checked in for a modification request, then the server MUST have automatically checked out the resource prior to executing the request and automatically checked it in after the request. In particular, the DAV:checked-in property of the resource MUST identify a new version whose content and dead properties are the same as those of the resource. The DAV:predecessor-set of the new version MUST identify the version identified by the DAV:checked-in property prior to the request. If any part of the checkout/update/checkin sequence failed, the status from the failed part of the request MUST be returned, and the server state preceding the request sequence MUST be restored.
• If the request creates a new resource, the new resource MAY have automatically been placed under version control, and all postconditions for VERSION-CONTROL apply to the request.

A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a versioning server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request.¶

Additional Preconditions: ¶

• (DAV:supported-live-property): If the request attempts to access a property defined by this document, the semantics of that property MUST be supported by the server.

Additional Preconditions: ¶

• (DAV:cannot-modify-version-controlled-property): If the request attempts to modify a dead property, same semantics as PUT (see Section 3.10).
• (DAV:cannot-modify-version): If the request attempts to modify a dead property, same semantics as PUT (see Section 3.10).
• (DAV:cannot-modify-protected-property): An attempt to modify a property that is defined by this document, as being protected for that kind of resource, MUST fail.
• (DAV:supported-live-property): An attempt to modify a property defined by this document, but whose semantics are not enforced by the server, MUST fail. This helps ensure that a client will be notified when it is trying to use a property whose semantics are not supported by the server.

Additional Postconditions: ¶

• (DAV:auto-checkout): If the request modified a dead property, same semantics as PUT (see Section 3.10).
• (DAV:auto-checkout-checkin): If the request modified a dead property, same semantics as PUT (see Section 3.10).

Additional Preconditions: ¶

• (DAV:no-version-delete): A server MAY fail an attempt to DELETE a version.

Additional Postconditions: ¶

• (DAV:update-predecessor-set): If a version was deleted, the server MUST have replaced any reference to that version in a DAV:predecessor-set by a copy of the DAV:predecessor-set of the deleted version.

Additional Preconditions: ¶

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

Additional Postconditions: ¶

• (DAV:must-not-copy-versioning-property): A property defined by this document MUST NOT have been copied to the new resource created by this request, but instead that property of the new resource MUST have the default initial value it would have had if the new resource had been created by a non-versioning method such as PUT or a MKCOL.
• (DAV:auto-checkout): If the destination is a version-controlled 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 a version-controlled resource or version, and if there is no resource at the destination of the COPY, then the COPY creates a new non-version-controlled resource at the destination of the COPY. The new resource MAY automatically be put under version control, but the resulting version-controlled resource MUST be associated with a new version history created for that new version-controlled resource, and all postconditions for VERSION-CONTROL apply to the request.

Additional Preconditions: ¶

• (DAV:cannot-rename-version): If the request-URL identifies a version, the request MUST fail.

Additional Postconditions: ¶

• (DAV:preserve-versioning-properties): When a resource is moved from a source URL to a destination URL, a property defined by this document MUST have the same value at the destination URL as it had at the source URL.

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 a precondition or postcondition cannot be satisfied, the lock timeout MUST NOT occur.¶

Additional Preconditions: ¶

• (DAV:version-history-is-tree): If the request-URL identifies a checked-out version-controlled resource that will be automatically checked in when the lock is removed, then the versions identified by the DAV:predecessor-set of the checked-out resource MUST be descendants of the root version of the version history for the DAV:checked-out version.

Additional Postconditions: ¶

• (DAV:auto-checkin): If the request-URL identified a checked-out version-controlled resource that had been automatically checked out because of its DAV:auto-version property, the request MUST have created a new version in the version history of the DAV:checked-out version. The request MUST have allocated a URL for the version that MUST NOT have previously identified any other resource, and MUST NOT ever identify a resource other than this version. The content, dead properties, DAV:resourcetype, and DAV:predecessor-set of the new version MUST be copied from the checked-out resource. The DAV:version-name of the new version MUST be set to a server-defined value distinct from all other DAV:version-name values of other versions in the same version history. The request MUST have removed the DAV:checked-out property of the version-controlled resource, and MUST have added a DAV:checked-in property that identifies the new version.

The checkout-in-place feature introduces the following REQUIRED properties for a version.¶

The checkout-in-place feature introduces the following REQUIRED properties for a checked-out resource.¶

A CHECKOUT request can be applied to a checked-in version-controlled resource to allow modifications to the content and dead properties of that version-controlled resource.¶

If a CHECKOUT request fails, the server state preceding the request MUST be restored.¶

Marshalling: ¶

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

  <!ELEMENT checkout ANY>
  

• ANY value: A sequence of elements with at most one DAV:fork-ok element.

  <!ELEMENT fork-ok EMPTY>
  

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

  <!ELEMENT checkout-response ANY>
  

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

Preconditions: ¶

• (DAV:must-be-checked-in): If a version-controlled resource is being checked out, it MUST have a DAV:checked-in property.
• (DAV:checkout-of-version-with-descendant-is-forbidden): If the DAV:checkout-fork property of the version being checked out is DAV:forbidden, the request MUST fail if a version identifies that version in its DAV:predecessor-set.
• (DAV:checkout-of-version-with-descendant-is-discouraged): If the DAV:checkout-fork property of the version being checked out is DAV:discouraged, the request MUST fail if a version identifies that version in its DAV:predecessor-set unless DAV:fork-ok is specified in the request body.
• (DAV:checkout-of-checked-out-version-is-forbidden): If the DAV:checkout-fork property of the version being checked out is DAV:forbidden, the request MUST fail if a checked-out resource identifies that version in its DAV:checked-out property.
• (DAV:checkout-of-checked-out-version-is-discouraged): If the DAV:checkout-fork property of the version being checked out is DAV:discouraged, the request MUST fail if a checked-out resource identifies that version in its DAV:checked-out property unless DAV:fork-ok is specified in the request body.

Postconditions: ¶

• (DAV:is-checked-out): The checked-out resource MUST have a DAV:checked-out property that identifies the DAV:checked-in version preceding the checkout. The version-controlled resource MUST NOT have a DAV:checked-in property.
• (DAV:initialize-predecessor-set): The DAV:predecessor-set property of the checked-out resource MUST be initialized to be the DAV:checked-out version.

A CHECKIN request can be applied to a checked-out version-controlled resource to produce a new version whose content and dead properties are copied from the checked-out resource.¶

If a CHECKIN request fails, the server state preceding the request MUST be restored.¶

Marshalling: ¶

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

  <!ELEMENT checkin ANY>
  ANY value: A sequence of elements with at most one
  DAV:keep-checked-out element and at most one DAV:fork-ok element.
  
  <!ELEMENT keep-checked-out EMPTY>
  <!ELEMENT fork-ok EMPTY>
  

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

  <!ELEMENT checkin-response ANY>
  

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

Preconditions: ¶

• (DAV:must-be-checked-out): The request-URL MUST identify a resource with a DAV:checked-out property.
• (DAV:version-history-is-tree) The versions identified by the DAV:predecessor-set of the checked-out resource MUST be descendants of the root version of the version history for the DAV:checked-out version.
• (DAV:checkin-fork-forbidden): A CHECKIN request MUST fail if it would cause a version whose DAV:checkin-fork is DAV:forbidden to appear in the DAV:predecessor-set of more than one version.
• (DAV:checkin-fork-discouraged): A CHECKIN request MUST fail if it would cause a version whose DAV:checkin-fork is DAV:discouraged to appear in the DAV:predecessor-set of more than one version, unless DAV:fork-ok is specified in the request body.

Postconditions: ¶

• (DAV:create-version): The request MUST have created a new version in the version history of the DAV:checked-out version. The request MUST have allocated a distinct new URL for the new version, and that URL MUST NOT ever identify any resource other than that version. The URL for the new version MUST be returned in a Location response header.
• (DAV:initialize-version-content-and-properties): The content, dead properties, DAV:resourcetype, and DAV:predecessor-set of the new version MUST be copied from the checked-out resource. The DAV:version-name of the new version MUST be set to a server-defined value distinct from all other DAV:version-name values of 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 in the request body, the DAV:checked-out property of the version-controlled resource MUST have been removed and a DAV:checked-in property that identifies the new version MUST have been added.
• (DAV:keep-checked-out): If DAV:keep-checked-out is specified in the request body, the DAV:checked-out property of the checked-out resource MUST have been updated to identify the new version.

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 partial effects of the UNCHECKOUT request.¶

Marshalling: ¶

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

  <!ELEMENT uncheckout ANY>
  

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

  <!ELEMENT uncheckout-response ANY>
  

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

Preconditions: ¶

• (DAV:must-be-checked-out-version-controlled-resource): The request-URL MUST identify a version-controlled resource with a DAV:checked-out property.

Postconditions: ¶

• (DAV:cancel-checked-out): The value of the DAV:checked-in property is that of the DAV:checked-out property prior to the request, and the DAV:checked-out property has been removed.
• (DAV:restore-content-and-dead-properties): The content and dead properties of the version-controlled resource are copies of its DAV:checked-in version.

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

The DAV:resourcetype of a version history MUST be DAV:version-history.¶

The version-history feature introduces the following REQUIRED properties for a version history.¶

The version-history feature introduces the following REQUIRED property for a version-controlled resource.¶

The version-history feature introduces the following REQUIRED property for a version.¶

Many properties identify a version from some version history. It is often useful to be able to efficiently locate a version-controlled resource for that version history. The DAV:locate-by-history report can be applied to a collection to locate the collection member that is a version-controlled resource for a specified version history resource.¶

Marshalling: ¶

• The request body MUST be a DAV:locate-by-history XML element.

  <!ELEMENT locate-by-history (version-history-set, prop)>
  <!ELEMENT version-history-set (href+)>
  prop: see RFC 2518, Section 12.11
  

• The response body for a successful request MUST be a DAV:multistatus XML element containing every version-controlled resource that is a member of the collection identified by the request-URL, and whose DAV:version-history property identifies one of the version history resources identified by the request body. The DAV:prop element in the request body identifies which properties should be reported in the DAV:prop elements in the response body.

Preconditions: ¶

• (DAV:must-be-version-history): Each member of the DAV:version-history-set element in the request body MUST identify a version history resource.

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

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

Additional Marshalling: ¶

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

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

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

  <!ELEMENT options-response ANY>
  ANY value: A sequence of elements with at most one
  DAV:version-history-collection-set element.
  
  <!ELEMENT version-history-collection-set (href*)>
  

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

Additional Postconditions: ¶

• (DAV:delete-version-set): If the request deleted a version history, the request MUST have deleted all versions in the DAV:version-set of that version history, and MUST have satisfied the postconditions for version deletion (see Section 3.13).
• (DAV:version-history-has-root): If the request deleted the root version of a version history, the request MUST have updated the DAV:root-version of the version history to refer to another version that is an ancestor of all other remaining versions in that version history. A result of this postcondition is that every version history will have at least one version, and the only way to delete all versions is to delete the version history resource.

Additional Preconditions: ¶

• (DAV:cannot-copy-history): If the request-URL identifies a version history, the request MUST fail. In order to create another version history whose versions have the same content and dead properties, the appropriate sequence of VERSION-CONTROL, CHECKOUT, PUT, PROPPATCH, and CHECKIN requests must be made.

Additional Preconditions: ¶

• (DAV:cannot-rename-history): If the request-URL identifies a version history, the request MUST fail.

Additional Postconditions: ¶

• (DAV:new-version-history): If the request created a new version history, the request MUST have allocated a new server-defined URL for that version history that MUST NOT have previously identified any other resource, and MUST NOT ever identify a resource other than this version history.

Additional Postconditions: ¶

• (DAV:add-to-history): A URL for the new version resource MUST have been added to the DAV:version-set of the version history of the DAV:checked-out version.

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

The workspace feature introduces the following REQUIRED property for a WebDAV resource.¶

A MKWORKSPACE request creates a new workspace resource. A server MAY restrict workspace creation to particular collections, but a client can determine the location of these collections from a DAV:workspace-collection-set OPTIONS request (see Section 6.4).¶

If a MKWORKSPACE request fails, the server state preceding the request MUST be restored.¶

Marshalling: ¶

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

  <!ELEMENT mkworkspace ANY>
  

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

  <!ELEMENT mkworkspace-response ANY>
  

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

Preconditions: ¶

• (DAV:resource-must-be-null): A resource MUST NOT exist at the request-URL.
• (DAV:workspace-location-ok): The request-URL MUST identify a location where a workspace can be created.

Postconditions: ¶

• (DAV:initialize-workspace): A new workspace exists at the request-URL. The DAV:resourcetype of the workspace MUST be DAV:collection. The DAV:workspace of the workspace MUST identify the workspace.

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

If a server supports the workspace feature, it MUST also support the checkout-in-place feature and the version-history feature.¶

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

Additional Marshalling: ¶

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

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

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

  <!ELEMENT options-response ANY>
  ANY value: A sequence of elements with at most one
  DAV:workspace-collection-set element.
  
  <!ELEMENT workspace-collection-set (href*)>
  

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

Additional Postconditions: ¶

• (DAV:delete-workspace-members): If a workspace is deleted, any resource that identifies that workspace in its DAV:workspace property MUST be deleted.

Additional Postconditions: ¶

• (DAV:workspace-member-moved): If the request-URL did not identify a workspace, the DAV:workspace of the destination MUST have been updated to have the same value as the DAV:workspace of the parent collection of the destination.
• (DAV:workspace-moved): If the request-URL identified a workspace, any reference to that workspace in a DAV:workspace property MUST have been updated to refer to the new location of that workspace.

A VERSION-CONTROL request can be used to create a new version-controlled resource for an existing version history. This allows the creation of version-controlled resources for the same version history in multiple workspaces.¶

Additional Marshalling: ¶

• <!ELEMENT version-control ANY>
  ANY value: A sequence of elements with at most one DAV:version
  element.
  
  <!ELEMENT version (href)>
  

Additional Preconditions: ¶

• (DAV:cannot-add-to-existing-history): If the DAV:version-control 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 element MUST identify a version.
• (DAV:one-version-controlled-resource-per-history-per-workspace): If the DAV:version-control request body specifies a version, and if the request-URL is a member of a workspace, then there MUST NOT already be a version-controlled member of that workspace whose DAV:checked-in or DAV:checked-out property identifies any version from the version history of the version specified in the request body.

Additional Postconditions: ¶

• (DAV:new-version-controlled-resource): If the request-URL did NOT identify a resource, a new version-controlled resource exists at the request-URL whose content and dead properties are initialized by those of the version in the request body, and whose DAV:checked-in property identifies that version.

The UPDATE method modifies the content and dead properties of a checked-in version-controlled resource (the "update target") to be those of a specified version (the "update source") from the version history of that version-controlled resource.¶

The response to an UPDATE request identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining. Extensions to the UPDATE method allow multiple resources to be modified from a single UPDATE request (see Section 12.13).¶

Marshalling: ¶

• The request body MUST be a DAV:update element.

  <!ELEMENT update ANY>
  ANY value: A sequence of elements with at most one DAV:version
  element and at most one DAV:prop element.
  <!ELEMENT version (href)>
  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 body 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 in the request body identified a version that is in the same version history as the DAV:checked-in version of a version-controlled resource identified by the request-URL, then the content and dead properties of that version-controlled resource MUST be the same as those of the version specified by the DAV:version element, and the DAV:checked-in property of the version-controlled resource MUST identify that version. The request-URL MUST appear in a DAV:response element in the response body.
• (DAV:report-properties): If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements in the response body.

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

The label feature introduces the following REQUIRED property for a version.¶

A LABEL request can be applied to a version to modify the labels that select that version. The case of a label name MUST be preserved when it is stored and retrieved. When comparing two label names to decide 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-controlled resource, the operation MUST be applied to the DAV:checked-in version of that version-controlled resource.¶

Marshalling: ¶

• The request body MUST be a DAV:label element.

  <!ELEMENT label ANY>
  ANY value: A sequence of elements with at most one DAV:add,
  DAV:set, or DAV:remove element.
  
  <!ELEMENT add (label-name)>
  <!ELEMENT set (label-name)>
  <!ELEMENT remove (label-name)>
  <!ELEMENT label-name (#PCDATA)>
  PCDATA value: string
  

• The request MAY include a Label header.
• The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed. Standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. If a Depth header is included and the request fails on any resource, the response MUST be a 207 Multi-Status that identifies all resources for which the request has failed.
• If a response body for a successful request is included, it MUST be a DAV:label-response XML element.

  <!ELEMENT label-response ANY>
  

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

Preconditions: ¶

• (DAV:must-be-checked-in): If the request-URL identifies a version-controlled resource, the version-controlled resource MUST be checked in.
• (DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
• (DAV:add-must-be-new-label): If DAV:add is specified in the request body, the specified label MUST NOT appear in the DAV:label-name-set of any version in the version history of that version-controlled resource.
• (DAV:label-must-exist): If DAV:remove is specified in the request body, the specified label MUST appear in the DAV:label-name-set of that version.

Postconditions: ¶

• (DAV:add-or-set-label): If DAV:add or DAV:set is specified in the request body, the specified label MUST appear in the DAV:label-name-set of the specified version, and MUST NOT appear in the DAV:label-name-set of any other version in the version history of that version.
• (DAV:remove-label): If DAV:remove is specified in the request body, the specified label MUST NOT appear in the DAV:label-name-set of any version in the version history of that version.

For certain methods (e.g. GET, PROPFIND), if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.¶

A Label header MUST have no effect on a request whose request-URL does not identify a version-controlled resource. In particular, it MUST have no effect on a request whose request-URL identifies a version or a version history.¶

A server MUST return an HTTP-1.1 Vary header containing Label in a successful response to a cacheable request (e.g., GET) that includes a Label header.¶

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

Additional Marshalling: ¶

• The request MAY include a Label header.

Additional Preconditions: ¶

• (DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.

Additional Postconditions: ¶

• (DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the response MUST contain the content of the specified version rather than that of the version-controlled resource.

Additional Marshalling: ¶

• The request MAY include a Label header.

Additional Preconditions: ¶

• (DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.

Additional Postconditions: ¶

• (DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the response MUST contain the properties of the specified version rather than that of the version-controlled resource.

Additional Marshalling: ¶

• The request MAY include a Label header.

Additional Preconditions: ¶

• (DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.

Additional Postconditions: ¶

• (DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the request MUST have copied the properties and content of the specified version rather than that of the version-controlled resource.

If the server supports the working-resource option, a LABEL header may be included to check out the version selected by the specified label.¶

Additional Marshalling: ¶

• The request MAY include a Label header.

Additional Preconditions: ¶

• (DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
• (DAV:must-not-have-label-and-apply-to-version): If a Label request header is included, the request body MUST NOT contain a DAV:apply-to-version element.

Additional Postconditions: ¶

• (DAV:apply-request-to-labeled-version): If the request-URL identifies a checked-in version-controlled resource, and a Label request header is included, the CHECKOUT MUST have been applied to the version selected by the specified label, and not to the version-controlled resource itself.

If the request body of an UPDATE request contains a DAV:label-name element, the update target is the resource identified by the request-URL, and the update source is the version selected by the specified label from the version history of the update target.¶

Additional Marshalling: ¶

• <!ELEMENT update ANY>
  ANY value: A sequence of elements with at most one DAV:label-name
  or DAV:version element (but not both).
  <!ELEMENT label-name (#PCDATA)>
  PCDATA value: string
  

  The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed. Standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. If a Depth header is included and the request fails on any resource, the response MUST be a 207 Multi-Status that identifies all resources for which the request has failed.

Additional Preconditions: ¶

• (DAV:must-select-version-in-history): If the request includes a DAV:label-name element in the request body, the label MUST select a version in the version history of the version-controlled resource identified by the request-URL.
• (DAV:depth-update): If the request includes a Depth header, standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. The request MUST be applied to a collection before being applied to any members of that collection, since an update of a version-controlled collection might change the membership of that collection.

Additional Postconditions: ¶

• (DAV:apply-request-to-labeled-version): If a DAV:label-name element appears in the request body, the content and dead properties of the version-controlled resource must have been updated to be those of the version selected by that label.

The working-resource feature introduces the following REQUIRED properties for a version.¶

The working-resource feature introduces the following REQUIRED properties for a working resource. Since a working resource is a checked-out resource, it also has any property defined in this document for a checked-out resource.¶

A CHECKOUT request can be applied to a version to create a new working resource. The content and dead properties of the working resource are a copy of the version that was checked out.¶

Marshalling: ¶

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

  <!ELEMENT checkout ANY>
  
  ANY value: A sequence of elements with at most one DAV:apply-to-version
  and at most one DAV:fork-ok element.
  <!ELEMENT apply-to-version EMPTY>
  <!ELEMENT fork-ok EMPTY>
  

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

  <!ELEMENT checkout-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): See Section 4.3.
• (DAV:checkout-of-version-with-descendant-is-discouraged): See Section 4.3.
• (DAV:checkout-of-checked-out-version-is-forbidden): See Section 4.3.
• (DAV:checkout-of-checked-out-version-is-discouraged): See Section 4.3.

Postconditions: ¶

• (DAV:create-working-resource): If the request-URL identified a version, the Location response header MUST contain the URL of a new working resource. The DAV:checked-out property of the new working resource MUST identify the version that was checked out. The content and dead properties of the working resource MUST be copies of the content and dead properties of the DAV:checked-out version. The DAV:predecessor-set property of the working resource MUST be initialized to be the version identified by the request-URL. The DAV:auto-update property of the working resource MUST NOT exist.
• (DAV:create-working-resource-from-checked-in-version): If the request-URL identified a version-controlled resource, and DAV:apply-to-version is specified in the request body, the CHECKOUT is applied to the DAV:checked-in version of the version-controlled resource, and not the version-controlled resource itself. A new working resource is created and the version-controlled resource remains checked-in. The DAV:auto-update property of the working resource MUST identify the version-controlled resource.

A CHECKIN request can be applied to a working resource to produce a new version whose content and dead properties are a copy of those of the working resource. If the DAV:auto-update property of the working resource was set because the working resource was created by applying a CHECKOUT with the DAV:apply-to-version flag to a version-controlled resource, the CHECKIN request will also update the content and dead properties of that version-controlled resource to be those of the new version.¶

Marshalling: ¶

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

  <!ELEMENT checkin ANY>
  ANY value: A sequence of elements with at most one DAV:fork-ok
  element.
  
  <!ELEMENT fork-ok EMPTY>
  

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

  <!ELEMENT checkin-response ANY>
  

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

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 property for the checked-out resource identifies a version-controlled resource, at least one of the versions identified by the DAV:predecessor-set property of the checked-out resource MUST identify a version that is either the same as or a descendant of the version identified by the DAV:checked-in property of that 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 the checked-out resource identified a version-controlled resource, an UPDATE request with the new version MUST have been applied to that version-controlled resource.
• (DAV:delete-working-resource): If the request-URL identifies a working resource and if DAV:keep-checked-out is not specified in the request body, the working resource is deleted.

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

Additional Postconditions: ¶

• (DAV:copy-creates-new-resource): The result of copying a working resource is a new non-version-controlled resource at the destination of the COPY. The new resource MAY automatically be put under version control, but the resulting version-controlled resource MUST be associated with a new version history created for that new version-controlled resource.

Additional Preconditions: ¶

• (DAV:cannot-rename-working-resource): If the request-URL identifies a working resource, the request MUST fail.

Additional Postconditions: ¶

• (DAV:update-auto-update): If the request-URL identified a version-controlled resource, any DAV:auto-update properties that identified that version-controlled resource MUST have been updated to contain the new location of that version-controlled resource.

Advanced-Server-Workspace Package: basic-server-workspace package plus all advanced features¶

Advanced-Client-Workspace Package: basic-client-workspace package plus all advanced features¶

The advanced-server-workspace package supports advanced versioning capabilities for a client with no persistent state. The advanced-client-workspace package supports advanced versioning capabilities for a client that maintains configuration state on the client. A server that supports both advanced workspace packages will interoperate with all versioning clients.¶

The following additional terms are used by the advanced versioning features.¶

Collection ¶

• A "collection" is a resource whose state consists of not only content and properties, but also a set of named "bindings", where a binding identifies what RFC 2518 calls an "internal member" of the collection. Note that a binding is not a resource, but rather is a part of the state of a collection that defines a mapping from a binding name (a URL segment) to a resource (an internal member of the collection).

Collection Version Resource ¶

• 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 (see Section 14). A version-controlled binding is a binding to a version-controlled resource. If the checkout-in-place feature is supported, a collection version can be created by checking out and then checking in a version-controlled collection. If the working-resource feature is supported, a collection version can be created by checking out a collection version (to create a "working collection") and then checking in the working collection.

Configuration ¶

• A "configuration" is a set of resources that consists of a root collection and all members (not just internal members) of that root collection that are not members of another configuration. The root collection is called the "configuration root", and the members of this set are called the "members of the configuration". Note that a collection (which is a single resource) is very different from a configuration (which is a set of resources).

Baseline Resource ¶

• A "baseline resource", or simply "baseline", of a collection is a version of the configuration that is rooted at that collection (see Section 12). In particular, a baseline captures the DAV:checked-in version of every version-controlled member of that configuration. Note that a collection version (which captures the state of a single resource) is very different from a collection baseline (which captures the state of a set of resources).

Baseline-Controlled Collection ¶

• A "baseline-controlled collection" is a collection from which baselines can be created (see Section 12).

Version-Controlled Configuration Resource ¶

• A "version-controlled configuration resource", or simply "version-controlled configuration", is a special kind of version-controlled resource that is associated with a baseline-controlled collection, and is used to create and access baselines of that collection (see Section 12). When a collection is both version-controlled and baseline-controlled, a client can create a new version of the collection by checking out and checking in that collection, and it can create a new baseline of that collection by checking out and checking in the version-controlled configuration of that collection.

Activity Resource ¶

• An "activity resource", or simply "activity", is a resource that selects a set of versions that correspond to a single logical change, where the versions selected from a given version history form a single line of descent through that version history (see Section 13).

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

The MERGE method performs the logical merge of a specified version (the "merge source") into a specified version-controlled resource (the "merge target"). If the merge source is neither an ancestor nor a descendant of the DAV:checked-in or DAV:checked-out version of the merge target, the MERGE checks out the merge target (if it is not already checked out) and adds the URL of the merge source to the DAV:merge-set of the merge target. It is then the client's responsibility to update the content and dead properties of the checked-out merge target so that it reflects the logical merge of the merge source into the current state of the merge target. The client indicates that it has completed the update of the merge target, by 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 an error check for a client forgetting to complete a merge, the server MUST fail an attempt to CHECKIN a version-controlled resource with a non-empty DAV:merge-set.¶

When a server has the ability to automatically update the content and dead properties of the merge target to reflect the logical merge of the merge source, it may do so unless DAV:no-auto-merge is specified in the MERGE request body. In order to notify the client that a merge source has been automatically merged, the MERGE request MUST add the URL of the auto-merged source to the DAV:auto-merge-set property of the merge target, and not to the DAV:merge-set property. The client indicates that it has verified that the auto-merge is valid, by deleting the merge source URL from the DAV:auto-merge-set, and adding it to the DAV:predecessor-set.¶

• If DAV:source identifies a version, that version is a merge source.
• If DAV:source identifies a version-controlled resource, the DAV:checked-in version of that version-controlled resource is a merge source.
• If DAV:source identifies a collection, the DAV:checked-in version of each version-controlled resource that is a member of that collection is a merge source.

The request-URL identifies the set of possible merge targets. If the request-URL identifies a collection, any member of the configuration rooted at the request-URL is a possible merge target. The merge target of a particular merge source is the version-controlled or checked-out resource whose DAV:checked-in or DAV:checked-out version is from the same version history as the merge source. If a merge source has no merge target, that merge source is ignored.¶

The MERGE response identifies the resources that a client must modify to complete the merge. It also identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining.¶

Marshalling: ¶

• The request body MUST be a DAV:merge element.
• The set of merge sources is determined by the DAV:source element in the request body.

  <!ELEMENT merge ANY>
  ANY value: A sequence of elements with one DAV:source element, at
  most one DAV:no-auto-merge element, at most one DAV:no-checkout
  element, at most one DAV:prop element, and any legal set of
  elements that can occur in a DAV:checkout element.
  <!ELEMENT source (href+)>
  <!ELEMENT no-auto-merge EMPTY>
  <!ELEMENT no-checkout EMPTY>
  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 body 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 Location header containing the URL for the new version created by the checkin.
• The response MUST include a Cache-Control:no-cache header.

Preconditions: ¶

• (DAV:cannot-merge-checked-out-resource): The DAV:source element MUST NOT identify a checked-out resource. If the DAV:source element identifies a collection, the collection MUST NOT have a member that is a checked-out resource.
• (DAV:checkout-not-allowed): If DAV:no-checkout is specified in the request body, it MUST be possible to perform the merge without checking out any of the merge targets.
• All preconditions of the CHECKOUT operation apply to the checkouts performed by the request.

Postconditions: ¶

• (DAV:ancestor-version): If a merge target is a version-controlled or checked-out resource whose DAV:checked-in version or DAV:checked-out version is the merge source or is a descendant of the merge source, the merge target MUST NOT have been modified by the MERGE.
• (DAV:descendant-version): If the merge target was a checked-in version-controlled resource whose DAV:checked-in version was an ancestor of the merge source, an UPDATE operation MUST have been applied to the merge target to set its content and dead properties to be those of the merge source. If the UPDATE method is not supported, the merge target MUST have been checked out, the content and dead properties of the merge target MUST have been set to those of the merge source, and the merge source MUST have been added to the DAV:auto-merge-set of the merge target. The merge target MUST appear in a DAV:response XML element in the response body.
• (DAV:checked-out-for-merge): If the merge target was a checked-in version-controlled resource whose DAV:checked-in version was neither a descendant nor an ancestor of the merge source, a CHECKOUT MUST have been applied to the merge target. All XML elements in the DAV:merge XML element that could appear in a DAV:checkout XML element MUST have been used as arguments to the CHECKOUT request. The merge target MUST appear in a DAV:response XML element in the response body.
• (DAV:update-merge-set): If the DAV:checked-out version of the merge target is neither equal to nor a descendant of the merge source, the merge source MUST be added to either the DAV:merge-set or the DAV:auto-merge-set of the merge target. The merge target MUST appear in a DAV:response XML element in the response body.
• If a merge source has been added to the DAV:auto-merge-set, the content and dead properties of the merge target MUST have been modified by the server to reflect the result of a logical merge of the merge source and the merge target. If a merge source has been added to the DAV:merge-set, the content and dead properties of the merge target MUST NOT have been modified by the server. If DAV:no-auto-merge is specified in the request body, the merge source MUST NOT have been added to the DAV:auto-merge-set.
• (DAV:report-properties): If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements in the response body.

A merge preview describes the changes that would result if the versions specified by the DAV:source element in the request body were to be merged into the resource identified by the request-URL (commonly, a collection).¶

Marshalling: ¶

• The request body MUST be a DAV:merge-preview XML element.

  <!ELEMENT merge-preview (source)>
  <!ELEMENT source (href)>
  

• The response body for a successful request MUST be a DAV:merge-preview-report XML element.

  <!ELEMENT merge-preview-report
  (update-preview | conflict-preview | ignore-preview)*>
  

• A DAV:update-preview element identifies a merge target whose DAV:checked-in property would change as a result of the MERGE, and identifies the merge source for that merge target.

  <!ELEMENT update-preview (target, version)>
  <!ELEMENT target (href)>
  <!ELEMENT version (href)>
  

• A DAV:conflict-preview element identifies a merge target that requires a merge.

  <!ELEMENT conflict-preview (target, common-ancestor, version)>
  

• A DAV:common-ancestor element identifies the version that is a common ancestor of both the merge source and the DAV:checked-in or DAV:checked-out version of the merge target.

  <!ELEMENT common-ancestor (href)>
  

• A DAV:ignore-preview element identifies a version that has no merge target and therefore would be ignored by the merge.

  <!ELEMENT ignore-preview (version)>
  

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

Additional Postconditions: ¶

• (DAV:delete-version-reference): If a version is deleted, any reference to that version in a DAV:merge-set or DAV:auto-merge-set property MUST be removed.

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.

Since a version-controlled configuration is a version-controlled resource, it has all the properties of a version-controlled resource. In addition, the baseline feature introduces the following REQUIRED property for a version-controlled configuration.¶

Since a checked-out configuration is a checked-out resource, it has all the properties of a checked-out resource. In addition, the baseline feature introduces the following REQUIRED property for a checked-out configuration.¶

The DAV:resourcetype of a baseline MUST be DAV:baseline. Since a baseline is a version resource, it has all the properties of a version resource. In addition, the baseline feature introduces the following REQUIRED properties for a baseline.¶

The baseline feature introduces the following REQUIRED property for a resource.¶

The baseline feature introduces the following REQUIRED property for a workspace.¶

A collection can be placed under baseline control with a BASELINE-CONTROL request. When a collection is placed under baseline control, the DAV:version-controlled-configuration property of the collection is set to identify a new version-controlled configuration. This version-controlled configuration can be checked out and then checked in to create a new baseline for that collection.¶

If a baseline is specified in the request body, the DAV:checked-in version of the new version-controlled configuration will be that baseline, and the collection is initialized to contain version-controlled members whose DAV:checked-in versions and relative names are determined by the specified baseline.¶

If no baseline is specified, a new baseline history is created containing a baseline that captures the state of the version-controlled members of the collection, and the DAV:checked-in version of the version-controlled configuration will be that baseline.¶

Marshalling: ¶

• If a request body is included, it MUST be a DAV:baseline-control XML element.

  <!ELEMENT baseline-control ANY>
  ANY value: A sequence of elements with at most one DAV:baseline
  element.
  
  <!ELEMENT baseline (href)>
  

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

  <!ELEMENT baseline-control-response ANY>
  

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

Preconditions: ¶

• (DAV:version-controlled-configuration-must-not-exist): The DAV:version-controlled-configuration property of the collection identified by the request-URL MUST not exist.
• (DAV:must-be-baseline): The DAV:href of the DAV:baseline element in the request body MUST identify a baseline.
• (DAV:must-have-no-version-controlled-members): If a DAV:baseline element is specified in the request body, the collection identified by the request-URL MUST have no version-controlled members.
• (DAV:one-baseline-controlled-collection-per-history-per-workspace): If the request-URL identifies a workspace or a member of a workspace, and if a baseline is specified in a DAV:baseline element in the request body, then there MUST NOT be another collection in that workspace whose DAV:version-controlled-configuration property identifies a version-controlled 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): The DAV:version-controlled-configuration of the collection identifies the new version-controlled configuration.
• (DAV:select-existing-baseline): If the request body specifies a baseline, the DAV:checked-in property of the new version-controlled configuration MUST have been set to identify this baseline. A version-controlled member of the collection will be created for each version in the baseline, where the version-controlled member will have the content and dead properties of that version, and will have the same name relative to the collection as the corresponding version-controlled resource had when the baseline was created. Any nested collections that are needed to provide the appropriate name for a version-controlled member will be created.
• (DAV:create-new-baseline): If no baseline is specified in the request body, the request MUST have created a new baseline history at a server-defined URL, and MUST have created a new baseline in that baseline history. The DAV:baseline-collection of the new baseline MUST identify a collection whose members have the same relative name and DAV:checked-in version as the version-controlled members of the request collection. The DAV:checked-in property of the new version-controlled configuration MUST identify the new baseline.

A DAV:compare-baseline report contains the differences between the baseline identified by the request-URL (the "request baseline") and the baseline specified in the request body (the "compare baseline").¶

Marshalling: ¶

• The request body MUST be a DAV:compare-baseline XML element.

  <!ELEMENT compare-baseline (href)>
  

• The response body for a successful request MUST be a DAV:compare-baseline-report XML element.

  <!ELEMENT compare-baseline-report
  (added-version | deleted-version | changed-version)*>
  

• A DAV:added-version element identifies a version that is the DAV:checked-in version of a member of the DAV:baseline-collection of the compare baseline, but no version in the version history of that version is the DAV:checked-in version of a member of the DAV:baseline-collection of the request baseline.

  <!ELEMENT added-version (href)>
  

• A DAV:deleted-version element identifies a version that is the DAV:checked-in version of a member of the DAV:baseline-collection of the request baseline, but no version in the version history of that version is the DAV:checked-in version of a member of the DAV:baseline-collection of the compare baseline.

  <!ELEMENT deleted-version (href)>
  

• A DAV:changed-version element identifies two different versions from the same version history that are the DAV:checked-in version of the DAV:baseline-collection of the request baseline and the compare baseline, respectively.

  <!ELEMENT changed-version (href, href)>
  

Preconditions: ¶

• (DAV:must-be-baseline): The DAV:href in the request body MUST identify a baseline.
• (DAV:baselines-from-same-history): A server MAY require that the baselines being compared be from the same baseline history.

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

Additional Postconditions: ¶

• If a server automatically puts a newly created collection under baseline control, all postconditions for BASELINE-CONTROL apply to the MKCOL.

Additional Postconditions: ¶

• If the request creates a new collection at the Destination, and a server automatically puts a newly created collection under baseline control, all postconditions for BASELINE-CONTROL apply to the COPY.

Additional Preconditions: ¶

• (DAV:must-not-update-baseline-collection): If the request-URL identifies a member of the configuration rooted at the DAV:baseline-collection of a baseline, the request MUST fail.

Additional Preconditions: ¶

• (DAV:no-checked-out-baseline-controlled-collection-members): If the request-URL identifies a version-controlled configuration, all version-controlled members of the DAV:baseline-controlled-collection of the version-controlled configuration MUST be checked-in.
• (DAV:one-version-per-history-per-baseline): If the request-URL identifies a version-controlled configuration, the set of versions selected by that version-controlled configuration MUST contain at most one version from any version history, where a version is selected by a version-controlled configuration if the version is identified by the DAV:checked-in property of any member of the configuration rooted at the DAV:baseline-controlled collection of that version-controlled configuration, or is identified by the DAV:checked-in property of any member of the configuration rooted at the DAV:baseline-collection of any subbaseline of that version-controlled configuration.
• (DAV:cannot-modify-version-controlled-configuration): If the request-URL identifies a version-controlled member of a baseline-controlled collection whose version-controlled configuration is checked-in, the request MUST fail unless the DAV:auto-version property of the version-controlled configuration will automatically check out that version-controlled configuration when it is modified.

Additional Postconditions: ¶

• (DAV:create-baseline-collection): If the request-URL identifies a version-controlled configuration, the DAV:baseline-collection of the new baseline identifies a collection whose members have the same relative name and DAV:checked-in version as the members of the DAV:baseline-controlled-collection of the version-controlled configuration at the time of the request.
• (DAV:modify-configuration): If the request-URL identifies a version-controlled member of a baseline-controlled collection, this is a modification to the version-controlled configuration of that baseline-controlled collection, and standard auto-versioning semantics apply.

Additional Preconditions: ¶

• (DAV:baseline-controlled-members-must-be-checked-in): If the request-URL identifies a version-controlled configuration, then all version-controlled members of the DAV:baseline-controlled-collection of that version-controlled configuration MUST be checked-in.
• (DAV:must-not-update-baseline-collection): If the request-URL identifies a member of the configuration rooted at the DAV:baseline-collection of a baseline, the request MUST fail.
• (DAV:cannot-modify-version-controlled-configuration): If the request updates the DAV:checked-in property of any version-controlled member of a baseline-controlled collection whose version-controlled configuration is checked-in, the request MUST fail unless the DAV:auto-version property of the version-controlled configuration will automatically check out that version-controlled configuration when it is modified.

Additional Postconditions: ¶

• (DAV:set-baseline-controlled-collection-members): If the request updated the DAV:checked-in property of a version-controlled configuration, then the version-controlled members of the DAV:baseline-controlled-collection of that version-controlled configuration MUST have been updated so that they have the same relative name, content, and dead properties as the members of the DAV:baseline-collection of the baseline. In particular:
  • A version-controlled member for a given version history MUST have been deleted if there is no version-controlled member for that version history in the DAV:baseline-collection of the baseline.
  • A version-controlled member for a given version history MUST 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 the DAV:baseline-collection of the baseline.
  • A new version-controlled member MUST have been created for each member of the DAV:baseline-collection of the baseline for which there is no corresponding version-controlled member in the baseline-controlled collection.
  • An UPDATE request MUST have been applied to each version-controlled member for a given version history whose DAV:checked-in version is not the same as that of the version-controlled member for that version history in the DAV:baseline-collection of the baseline.
• (DAV:update-subbaselines): If the request updated a version-controlled configuration whose DAV:baseline-controlled-collection contains a baseline-controlled member for one of the subbaselines of the request baseline, then the DAV:checked-in property of the version-controlled configuration of that baseline-controlled member MUST have been updated to be that subbaseline. If the request updated a version-controlled configuration whose DAV:baseline-controlled-collection is a member of a workspace that contains a baseline-controlled member for one of the subbaselines of the request baseline, then the DAV:checked-in property of the version-controlled configuration of that baseline-controlled member MUST have been updated to be that subbaseline.
• (DAV:modify-configuration): If the request updated the DAV:checked-in property of any version-controlled member of a baseline-controlled collection, and if this DAV:checked-in property differs from the DAV:checked-in property of the 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-controlled configuration, and standard auto-versioning semantics apply.

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-controlled configuration is a member of the collection identified by the request-URL.¶

Additional Preconditions: ¶

• (DAV:must-not-update-baseline-collection): Same semantics as UPDATE (Section 12.13).
• (DAV:cannot-modify-version-controlled-configuration): Same semantics as UPDATE (Section 12.13).

Additional Postconditions: ¶

• (DAV:merge-baseline): If the merge target is a version-controlled configuration whose DAV:checked-out baseline is not a descendant of the merge baseline, then the merge baseline MUST have been added to the DAV:auto-merge-set of a version-controlled configuration. The DAV:checked-in version of each member of the DAV:baseline-collection of that baseline MUST have been merged 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-collection contains a baseline-controlled member for one of the subbaselines of the merge baseline, then that subbaseline MUST have been merged into the version-controlled configuration of that baseline-controlled member. If the merge target is a version-controlled configuration whose DAV:baseline-controlled-collection is a member of a workspace that contains a baseline-controlled member for one of the subbaselines of the merge baseline, then that subbaseline MUST have been merged into the version-controlled configuration of that baseline-controlled member.
• (DAV:set-baseline-controlled-collection-members): Same semantics as UPDATE (Section 12.13).
• (DAV:modify-configuration): Same semantics as UPDATE (see Section 12.13).

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

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

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

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

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

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

Marshalling: ¶

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

  <!ELEMENT mkactivity ANY>
  

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

  <!ELEMENT mkactivity-response ANY>
  

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

Preconditions: ¶

• (DAV:resource-must-be-null): A resource MUST NOT exist at the request-URL.
• (DAV:activity-location-ok): The request-URL MUST identify a location where an activity can be created.

Postconditions: ¶

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

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

Marshalling: ¶

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

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

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

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

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

Preconditions: ¶

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

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

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

Additional Marshalling: ¶

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

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

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

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

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

Additional Postconditions: ¶

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

Additional Postconditions: ¶

• (DAV:update-checked-out-reference): If a checked-out resource is moved, any reference to that resource in a DAV:activity-checkout-set property MUST be updated to refer to the new location of that resource.
• (DAV:update-activity-reference): If the request-URL identifies an activity, any reference to that activity in a DAV:activity-set, DAV:subactivity-set, or DAV:current-activity-set MUST be updated to refer to the new location of that activity.
• (DAV:update-workspace-reference): If the request-URL identifies a workspace, any reference to that workspace in a DAV:current-workspace-set property MUST be updated to refer to the new location of that workspace.

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

Additional Marshalling: ¶

• <!ELEMENT checkout ANY> ANY value: A sequence of elements with at
  most one DAV:activity-set and at most one DAV:unreserved.
  
  <!ELEMENT activity-set (href+ | new)>
  <!ELEMENT new EMPTY>
  <!ELEMENT unreserved EMPTY>
  

Additional Preconditions: ¶

• (DAV:one-checkout-per-activity-per-history): If there is a request activity set, unless DAV:unreserved is specified, another checkout from a version of that version history MUST NOT select an activity in that activity set.
• (DAV:linear-activity): If there is a request activity set, unless DAV:unreserved is specified, the selected version MUST be a descendant of all other versions of that version history that select that activity.

Additional Postconditions: ¶

• (DAV:initialize-activity-set): The DAV:activity-set of the checked-out resource is set as follows:
  • If DAV:new is specified as the DAV:activity-set in the request body, then a new activity created by the server is used.
  • Otherwise, if activities are specified in the request body, then those activities are used.
  • Otherwise, if the version-controlled resource is a member of a workspace and the DAV:current-activity-set of the workspace is set, then those activities are used.
  • Otherwise, the DAV:activity-set of the DAV:checked-out version is used.
• (DAV:initialize-unreserved): If DAV:unreserved was specified in the request body, then the DAV:unreserved property of the checked-out resource MUST be "true".

Additional Preconditions: ¶

• (DAV:linear-activity): Any version which is in the version history of the checked-out resource and whose DAV:activity-set identifies an activity from the DAV:activity-set of the checked-out resource MUST be an ancestor of the checked-out resource.
• (DAV:atomic-activity-checkin): If the request-URL identifies an activity, the server MAY fail the request if any of the checked-out resources in the DAV:activity-checkout-set of either that activity or any subactivity of that activity cannot be checked in.

Additional Postconditions: ¶

• (DAV:initialize-activity-set): The DAV:activity-set of the new version MUST have been initialized to be the same as the DAV:activity-set of the checked-out resource.
• (DAV:activity-checkin): If the request-URL identified an activity, the server MUST have successfully applied the CHECKIN request to each checked-out resource in the DAV:activity-checkout-set of both that activity and any subactivity of that activity.

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

Additional Marshalling: ¶

• <!ELEMENT checkin-activity EMPTY>
  

Additional Postconditions: ¶

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

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

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

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

Additional Preconditions: ¶

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

Additional Preconditions: ¶

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

Additional Postconditions: ¶

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

Additional Preconditions: ¶

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

Additional Preconditions: ¶

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

Additional Preconditions: ¶

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

Additional Postconditions: ¶

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

Additional Postconditions: ¶

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

Additional Postconditions: ¶

• (DAV:initialize-version-controlled-bindings): If the request-URL identified a version-controlled collection, then the DAV:version-controlled-binding-set of the new collection version MUST contain a DAV:version-controlled-binding that identifies the binding name and version history for each version-controlled binding of the version-controlled collection.
• (DAV:version-control-working-collection-members): If the request-URL identified a working collection, a VERSION-CONTROL request MUST have been automatically applied to every non-version-controlled member of the working collection, and each non-version-controlled member MUST have been replaced by its newly created version history. If a working collection member was a non-version-controlled collection, every member of the non-version-controlled collection MUST have been placed under version control before the non-version-controlled collection was placed under version control. The DAV:version-controlled-binding-set of the new collection version MUST contain a DAV:version-controlled-binding that identifies the binding name and the version history URL for each member of the working collection.

Additional Postconditions: ¶

• (DAV:update-version-controlled-collection-members): If the request modified the DAV:checked-in version of a version-controlled collection, then the version-controlled members of that version-controlled collection MUST have been updated. In particular:
  • A version-controlled internal member MUST have been deleted if its version history is not identified by the DAV:version-controlled-binding-set of the new DAV:checked-in version.
  • A version-controlled internal member for a given version history MUST have been renamed if its binding name differs from the DAV:binding-name for that version history in the DAV:version-controlled-binding-set of the new DAV:checked-in version.
  • A new version-controlled internal member MUST have been created when a version history is identified by the DAV:version-controlled-binding-set of the DAV:checked-in version, but there was no member of the version-controlled collection for that version history. If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource. Otherwise, the content and dead properties of the new version-controlled member MUST have been initialized to be those of the version specified for that version history by the request. If no version is specified for that version history by the request, the version selected is server defined.

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

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

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

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

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

• all DeltaV-compliant resource properties.

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

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

Supported live properties: ¶

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

Supported methods: ¶

• all checked-out resource methods.

Supported live properties: ¶

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

Supported methods: ¶

• all DeltaV-compliant resource methods.

Supported live properties: ¶

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

Supported methods: ¶

• all DeltaV-compliant collection methods.

Supported live properties: ¶

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

Supported methods: ¶

• all DeltaV-compliant resource methods.

Supported live properties: ¶

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

Supported methods: ¶

• all version-controlled resource methods.

Supported live properties: ¶

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

Supported methods: ¶

• all version methods.

Supported live properties: ¶

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

Supported methods: ¶

• all version-controlled resource methods.

Supported live properties: ¶

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

Supported methods: ¶

• all version methods.

Supported live properties: ¶

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

Supported methods: ¶

• all version-controlled configuration methods.