Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3253

Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

Pages: 118
Proposed Standard
Errata
Part 3 of 4 – Pages 52 to 90
First   Prev   Next

Top   ToC   RFC3253 - Page 52   prevText

6.6 Additional MOVE Semantics

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.

6.7 Additional VERSION-CONTROL Semantics

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.
Top   ToC   RFC3253 - Page 53
   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.

6.7.1 Example - VERSION-CONTROL (using an existing version history)

>>REQUEST VERSION-CONTROL /ws/public/bar.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:version-control xmlns:D="DAV:"> <D:version> <D:href>http://repo.webdav.org/his/12/ver/V3</D:href> </D:version> </D:version-control> >>RESPONSE HTTP/1.1 201 Created Cache-Control: no-cache In this example, a new version-controlled resource is created at /ws/public/bar.html. The content and dead properties of the new version-controlled resource are initialized to be the same as those of the version identified by http://repo.webdav.org/his/12/ver/V3.

7 UPDATE Feature

The update feature provides a mechanism for changing the state of a checked-in version-controlled resource to be that of another version from the version history of that resource.

7.1 UPDATE Method

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.
Top   ToC   RFC3253 - Page 54
   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.
Top   ToC   RFC3253 - Page 55

7.1.1 Example - UPDATE

>>REQUEST UPDATE /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:update xmlns:D="DAV:"> <D:version> <D:href>http://repo.webdav.org/his/23/ver/33</D:href> </D:version> </D:update> >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/foo.html</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> In this example, the content and dead properties of http://repo.webdav.org/his/23/ver/33 are copied to the version- controlled resource /foo.html, and the DAV:checked-in property of /foo.html is updated to refer to http://repo.webdav.org/his/23/ver/33.

7.2 Additional OPTIONS Semantics

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.
Top   ToC   RFC3253 - Page 56

8 Label Feature

A version "label" is a string that distinguishes one version in a version history from all other versions in that version history. A label can automatically be assigned by a server, or it can be assigned by a client in order to provide a meaningful name for that version. A given version label can be assigned to at most one version of a given version history, but client assigned labels can be reassigned to another version at any time. Note that although a given label can be applied to at most one version from the same version history, the same label can be applied to versions from different version histories. For certain methods, if the request-URL identifies a version- controlled resource, a label can be specified in a Label request header (see Section 8.3) to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.

8.1 Additional Version Properties

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

8.1.1 DAV:label-name-set (protected)

This property contains the labels that currently select this version. <!ELEMENT label-name-set (label-name*)> <!ELEMENT label-name (#PCDATA)> PCDATA value: string

8.2 LABEL Method

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.
Top   ToC   RFC3253 - Page 57
   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.
Top   ToC   RFC3253 - Page 58
      (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.

8.2.1 Example - Setting a label

>>REQUEST LABEL /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:label xmlns:D="DAV:"> <D:set> <D:label-name>default</D:label-name> </D:set> </D:label> >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache In this example, the label "default" is applied to the DAV:checked-in version of /foo.html.

8.3 Label Header

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.
Top   ToC   RFC3253 - Page 59
   The value of a label header is the name of a label, encoded using
   URL-escaped UTF-8.  For example, the label "release B.3" is
   identified by the following header:

     Label: release%20B.3

   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.

8.4 Additional OPTIONS Semantics

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.

8.5 Additional GET Semantics

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.

8.6 Additional PROPFIND Semantics

Additional Marshalling: The request MAY include a Label header.
Top   ToC   RFC3253 - Page 60
   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.

8.7 Additional COPY Semantics

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.

8.8 Additional CHECKOUT Semantics

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.
Top   ToC   RFC3253 - Page 61
   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.

8.9 Additional UPDATE Semantics

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.
Top   ToC   RFC3253 - Page 62
      (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.

9 Working-Resource Feature

The working-resource feature provides an alternative to the workspace feature for supporting parallel development. Unlike the workspace feature, where the desired configuration of versions and checked-out resources is maintained on the server, the working-resource feature maintains the configuration on the client. This simplifies the server implementation, but does not allow a user to access the configuration from clients in different physical locations, such as from another office, from home, or while traveling. Another difference is that the workspace feature isolates clients from a logical change that involves renaming shared resources, until that logical change is complete and tested; with the working resource feature, all clients use a common set of shared version-controlled resources and every client sees the result of a MOVE as soon as it occurs. If a server supports the working-resource feature but not the checkout-in-place feature, a CHECKOUT request can only be used to create a working resource, and cannot be used to check out a version-controlled resource. If a server supports the checkout-in- place feature, but not the working-resource feature, a CHECKOUT can only be used to change the state of a version-controlled resource from checked-in to checked-out.

9.1 Additional Version Properties

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

9.1.1 DAV:checkout-fork

This property is defined in Section 4.1.1.
Top   ToC   RFC3253 - Page 63

9.1.2 DAV:checkin-fork

This property is defined in Section 4.1.2.

9.2 Working Resource Properties

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.

9.2.1 DAV:auto-update (protected)

This property identifies the version-controlled resource that will be updated when the working resource is checked in. <!ELEMENT auto-update (href)>

9.2.2 DAV:checkout-fork

This property is defined in Section 4.2.1.

9.2.3 DAV:checkin-fork

This property is defined in Section 4.2.2.

9.3 CHECKOUT Method (applied to a version)

A CHECKOUT request can be applied to a version to create a 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.
Top   ToC   RFC3253 - Page 64
      <!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.
Top   ToC   RFC3253 - Page 65

9.3.1 Example - CHECKOUT of a version

>>REQUEST CHECKOUT /his/12/ver/V3 HTTP/1.1 Host: repo.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Location: http://repo.webdav.org/wr/157 Cache-Control: no-cache In this example, the version identified by http://repo.webdav.org/his/12/ver/V3 is checked out, and the new working resource is located at http://repo.webdav.org/wr/157.

9.4 CHECKIN Method (applied to a working resource)

A CHECKIN request can be applied to a working resource to produce 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.
Top   ToC   RFC3253 - Page 66
   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.

9.4.1 Example - CHECKIN of a working resource

>>REQUEST CHECKIN /wr/157 HTTP/1.1 Host: repo.webdav.org Content-Length: 0 >>RESPONSE HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/15 Cache-Control: no-cache
Top   ToC   RFC3253 - Page 67
   In this example, the working resource /wr/157 checked in, and a new
   version is created at http://repo.webdav.org/his/23/ver/15.

9.5 Additional OPTIONS Semantics

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.

9.6 Additional COPY Semantics

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.

9.7 Additional MOVE Semantics

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.

10 Advanced Versioning Features

Advanced versioning addresses the problems of parallel development and configuration management of multiple sets of interrelated resources. Traditionally, artifacts of software development, including requirements, design documents, code, and test cases, have been a focus of configuration management. Web sites, comprising multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are another class of complex information artifacts that benefit from the application of configuration management. The advanced versioning capabilities for coordinating concurrent change provide the infrastructure for efficient and controlled management of large evolving web sites.
Top   ToC   RFC3253 - Page 68

10.1 Advanced Versioning Packages

Although a server MAY support any combination of advanced versioning features, in order to minimize the complexity of a WebDAV advanced versioning client, a WebDAV advanced versioning server SHOULD support one of the following packages: 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.

10.2 Advanced Versioning Terms

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.
Top   ToC   RFC3253 - Page 69
   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).
Top   ToC   RFC3253 - Page 70

11 Merge Feature

When a user wants to accept the changes (new versions) created by someone else, it is important not just to update the version- controlled resources in the user's workspace with those new versions, since this could result in "backing out" changes the user has made to those version-controlled resources. Instead, the versions created in another workspace should be "merged" into the user's version- controlled resources. The version history of a version-controlled resource provides the information needed to determine the result of the merge. In particular, the merge should select whichever version is later in the line of descent from the root version. In case the versions to be merged are on different lines of descent (neither version is a descendant of the other), neither version should be selected, but instead, a new version should be created that contains the logical merge of the content and dead properties of those versions. The MERGE request can be used to check out each version-controlled resource that requires such a merge, and set the DAV:merge-set property of each checked-out resource to identify the version to be merged. The user is responsible for modifying the content and dead properties of the checked-out resource so that it represents the logical merge of that version, and then adding that version to the DAV:predecessor-set of the checked-out resource. If the server is capable of automatically performing the merge, it MAY update the content, dead properties, and DAV:predecessor-set of the checked-out resource itself. Before checking in the automatically merged resource, the user is responsible for verifying that the automatic merge is correct.

11.1 Additional Checked-Out Resource Properties

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

11.1.1 DAV:merge-set

This property identifies each version that is to be merged into this checked-out resource. <!ELEMENT merge-set (href*)>
Top   ToC   RFC3253 - Page 71

11.1.2 DAV:auto-merge-set

This property identifies each version that the server has merged into this checked-out resource. The client should confirm that the merge has been performed correctly before moving a URL from the DAV:auto- merge-set to the DAV:predecessor-set of a checked-out resource. <!ELEMENT auto-merge-set (href*)>

11.2 MERGE Method

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. Multiple merge sources can be specified in a single MERGE request. The set of merge sources for a MERGE request is determined from the DAV:source element of the MERGE request body as follows: - 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.
Top   ToC   RFC3253 - Page 72
   -  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.
Top   ToC   RFC3253 - Page 73
   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.
Top   ToC   RFC3253 - Page 74
      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.

11.2.1 Example - MERGE

>>REQUEST MERGE /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/sally</D:href> </D:source> </D:merge> >>RESPONSE HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/ws/public/src/parse.c</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> <D:response> <D:href>http://www.webdav.org/ws/public/doc/parse.html</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> </D:multistatus>
Top   ToC   RFC3253 - Page 75
   In this example, the DAV:checked-in versions from the workspace
   http://www.webdav.org/ws/dev/sally are merged into the version-
   controlled resources in the workspace
   http://www.webdav.org/ws/public.  The resources
   /ws/public/src/parse.c and /ws/public/doc/parse.html were modified by
   the request.

11.3 DAV:merge-preview Report

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.
Top   ToC   RFC3253 - Page 76
      <!ELEMENT ignore-preview (version)>

11.3.1 Example - DAV:merge-preview Report

>>REQUEST REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge-preview xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/fred</D:href> </D:source> </D:merge-preview> >>RESPONSE HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge-preview-report xmlns:D="DAV:"> <D:conflict-preview> <D:target> <D:href>http://www.webdav.org/ws/public/foo.html</D:href> </D:target> <D:common-ancestor> <D:href>http://repo.webdav.org/his/23/ver/18</D:href> </D:common-ancestor> <D:version> <D:href>http://repo.webdav.org/his/23/ver/42</D:href> </D:version> </D:conflict-preview> <D:update-preview> <D:target> <D:href>http://www.webdav.org/ws/public/bar.html</D:href> </D:target> <D:version> <D:href>http://www.repo/his/42/ver/3</D:href> </D:version> </D:update-preview> </D:merge-preview-report>
Top   ToC   RFC3253 - Page 77
   In this example, the merge preview report indicates that version
   /his/23/ver/42 would be merged in /ws/public/foo.html, and version
   /his/42/ver/3 would update /ws/public/bar.html if the workspace
   http://www.webdav.org/ws/dev/fred was merged into the workspace
   http://www.webdav.org/ws/public.

11.4 Additional OPTIONS Semantics

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.

11.5 Additional DELETE Semantics

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.

11.6 Additional CHECKIN Semantics

Additional Preconditions: (DAV:merge-must-be-complete): The DAV:merge-set and DAV:auto- merge-set of the checked-out resource MUST be empty or not exist.

12 Baseline Feature

A configuration is a set of resources that consists of a root collection and all members of that root collection except those resources that are members of another configuration. A configuration that contains a large number of resources can consume a large amount of space on a server. This can make it prohibitively expensive to remember the state of an existing configuration by creating a Depth:infinity copy of its root collection. A baseline is a version resource that captures the state of each version-controlled member of a configuration. A baseline history is a version history whose versions are baselines. New baselines are created by checking out and then checking in a special kind of version-controlled resource called a version-controlled configuration. A collection that is under baseline control is called a baseline- controlled collection. In order to allow efficient baseline implementation, the state of a baseline of a collection is limited to
Top   ToC   RFC3253 - Page 78
   be a set of versions and their names relative to the collection, and
   the operations on a baseline are limited to the creation of a
   baseline from a collection, and restoring or merging the baseline
   back into a collection.  A server MAY automatically put a collection
   under baseline control when it is created, or a client can use the
   BASELINE-CONTROL method to put a specified collection under baseline
   control.

   As a configuration gets large, it is often useful to break it up into
   a set of smaller configurations that form the logical "components" of
   that configuration.  In order to capture the fact that a baseline of
   a configuration is logically extended by a component configuration
   baseline, the component configuration baseline is captured as a
   "subbaseline" of the baseline.

   The root collection of a configuration is unconstrained with respect
   to its relationship to the root collection of any of its components.
   In particular, the root collection of a configuration can have a
   member that is the root collection of one of its components (e.g.,
   configuration /sys/x can have a component /sys/x/foo), can be a
   member of the root collection of one of its components (e.g.,
   configuration /sys/y/z can have a component /sys/y), or neither
   (e.g., configuration /sys/x can have a component /comp/bar).

12.1 Version-Controlled Configuration Properties

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.

12.1.1 DAV:baseline-controlled-collection (protected)

This property identifies the collection that contains the version- controlled resources whose DAV:checked-in versions are being tracked by this version-controlled configuration. The DAV:version- controlled-configuration of the DAV:baseline-controlled-collection of a version-controlled configuration MUST identify that version- controlled configuration. <!ELEMENT baseline-controlled-collection (href)>

12.2 Checked-Out Configuration Properties

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.
Top   ToC   RFC3253 - Page 79

12.2.1 DAV:subbaseline-set

This property determines the DAV:subbaseline-set property of the baseline that results from checking in this resource. A server MAY reject attempts to modify the DAV:subbaseline-set of a checked-out configuration. <!ELEMENT subbaseline-set (href*)>

12.3 Baseline Properties

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.

12.3.1 DAV:baseline-collection (protected)

This property contains a server-defined URL for a collection, where each member of this collection MUST either be a version-controlled resource with the same DAV:checked-in version and relative name as a version-controlled member of the baseline-controlled collection at the time the baseline was created, or be a collection needed to provide the relative name for a version-controlled resource. <!ELEMENT baseline-collection (href)>

12.3.2 DAV:subbaseline-set (protected)

The URLs in the DAV:subbaseline-set property MUST identify a set of other baselines. The subbaselines of a baseline are the baselines identified by its DAV:subbaseline-set and all subbaselines of the baselines identified by its DAV:subbaseline-set. <!ELEMENT subbaseline-set (href*)>

12.4 Additional Resource Properties

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

12.4.1 DAV:version-controlled-configuration (computed)

If the resource is a member of a version-controlled configuration (i.e. the resource is a collection under baseline control or is a member of a collection under baseline control), this property identifies that version-controlled configuration.
Top   ToC   RFC3253 - Page 80
   <!ELEMENT version-controlled-configuration (href)>

12.5 Additional Workspace Properties

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

12.5.1 DAV:baseline-controlled-collection-set (computed)

This property identifies each member of the workspace that is a collection under baseline control (as well as the workspace itself, if it is under baseline control). <!ELEMENT baseline-controlled-collection-set (href*)>

12.6 BASELINE-CONTROL Method

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.
Top   ToC   RFC3253 - Page 81
      <!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.
Top   ToC   RFC3253 - Page 82
      (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.

12.6.1 Example - BASELINE-CONTROL

>>REQUEST BASELINE-CONTROL /src HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:baseline-control xmlns:D="DAV:"> <D:href>http://www.webdav.org/repo/blh/13/ver/8</D:href> </D:baseline-control> >>RESPONSE HTTP/1.1 200 OK Cache-Control: no-cache Content-Length: 0
Top   ToC   RFC3253 - Page 83
   In this example, the collection /src is placed under baseline
   control, and is populated with members from an existing baseline.  A
   new version-controlled configuration (/repo/vcc/128) is created and
   associated with /src, and /src is initialized with version-controlled
   members whose DAV:checked-in versions are those selected by the
   DAV:baseline-collection (/repo/bc/15) of the specified baseline
   (/repo/blh/13/ver/8).  The following diagram illustrates the
   resulting state on the server.

         +-------------------------------------+
         |Baseline-Controlled Collection       |<------+
         |/src                                 |       |
         |-------------------------------------|       |
         |DAV:version-controlled-configuration +---+   |
         +-------------------------------------+   |   |
                                                   |   |
                                                   |   |
         +-------------------------------------+   |   |
         |Version-Controlled Configuration     |<--+   |
         |/repo/vcc/128                        |       |
         |-------------------------------------|       |
         |DAV:baseline-controlled-collection   +-------+
         |-------------------------------------|
         |DAV:checked-in                       +-------+
         +-------------------------------------+       |
         |DAV:version-history                  +---+   |
         +-------------------------------------+   |   |
                                                   |   |
                                                   |   |
         +------------------------+                |   |
         |Baseline History        |<---------------+   |
         |/repo/blh/13            |                    |
         |------------------------+                    |
         |DAV:version-set         +----------------+   |
         +------------------------+    |   |   |   |   |
                                       v   |   v   v   |
                                           |           |
         +------------------------+        |           |
         |Baseline                |<-------+-----------+
         |/repo/blh/13/ver/8      |
         |------------------------+     +--------------+
         |DAV:baseline-collection +---->|Collection    |
         +------------------------+     |/repo/bc/15   |
                                        +--------------+
Top   ToC   RFC3253 - Page 84
   In order to create new baselines of /src, /repo/vcc/128 can be
   checked out, new versions can be created or selected by the version-
   controlled members of /src, and then /repo/vcc/128 can be checked in
   to capture the current state of those version-controlled members.

12.7 DAV:compare-baseline Report

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)>
Top   ToC   RFC3253 - Page 85
   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.

12.7.1 Example - DAV:compare-baseline Report

>>REQUEST REPORT /bl-his/12/bl/14 HTTP/1.1 Host: repo.webdav.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:compare-baseline xmlns:D="DAV:"> <D:href>http://repo.webdav.org/bl-his/12/bl/15</D:href> </D:compare-baseline> >>RESPONSE HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:compare-baseline-report xmlns:D="DAV:"> <D:added-version> <D:href>http://repo.webdav.org/his/23/ver/8</D:href> </D:added-version> <D:changed-version> <D:href>http://repo.webdav.org/his/29/ver/12</D:href> <D:href>http://repo.webdav.org/his/29/ver/19</D:href> </D:changed-version> <D:deleted-version> <D:href>http://repo.webdav.org/his/12/ver/4</D:href> </D:deleted-version> </D:compare-baseline-report> In this example, the differences between baseline 14 and baseline 15 of http://repo.webdav.org/bl-his/12 are identified.
Top   ToC   RFC3253 - Page 86

12.8 Additional OPTIONS Semantics

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.

12.9 Additional MKCOL Semantics

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

12.10 Additional COPY Semantics

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.

12.11 Additional CHECKOUT Semantics

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.

12.12 Additional CHECKIN Semantics

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
Top   ToC   RFC3253 - Page 87
      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.

12.13 Additional UPDATE Semantics

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
Top   ToC   RFC3253 - Page 88
      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.
Top   ToC   RFC3253 - Page 89
      (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.

12.14 Additional MERGE Semantics

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 (see Section 12.13). (DAV:cannot-modify-version-controlled-configuration): Same semantics as UPDATE (see 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.
Top   ToC   RFC3253 - Page 90
      (DAV:set-baseline-controlled-collection-members): Same semantics
      as UPDATE (see Section 12.13).

      (DAV:modify-configuration): Same semantics as UPDATE (see Section
      12.13).



(page 90 continued on part 4)

Next Section