rfc3253.txt

RFC 的详细文档！

                      |    |           |       |
         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.

1.4 Property Values

1.4.1 Initial Property Value

   Unless an initial value of a property of a given type is defined by
   this document, the initial value of a property of that type is
   implementation dependent.




Clemm, et al.               Standards Track                    [Page 11]

RFC 3253            Versioning Extensions to WebDAV           March 2002


1.4.2 Protected Property Value

   When a property of a specific kind of resource is "protected", the
   property value cannot be updated on that kind of resource except by a
   method explicitly defined as updating that specific property.  In
   particular, a protected property cannot be updated with a PROPPATCH
   request.  Note that a given property can be protected on one kind of
   resource, but not protected on another kind of resource.

1.4.3 Computed Property Value

   When a property is "computed", its value is defined in terms of a
   computation based on the content and other properties of that
   resource, or even of some other resource.  When the semantics of a
   method is defined in this document, the effect of that method on
   non-computed properties will be specified; the effect of that method
   on computed properties will not be specified, but can be inferred
   from the computation defined for those properties.  A computed
   property is always a protected property.

1.4.4 Boolean Property Value

   Some properties take a Boolean value of either "false" or "true".

1.4.5 DAV:href Property Value

   The DAV:href XML element is defined in RFC 2518, Section 12.3.

1.5 DAV Namespace XML Elements in Request and Response Bodies

   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.

1.6 Method Preconditions and Postconditions

   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.




Clemm, et al.               Standards Track                    [Page 12]

RFC 3253            Versioning Extensions to WebDAV           March 2002


   In order to allow better client handling of 403 and 409 responses, 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.

1.6.1 Example - CHECKOUT request with DAV:must-be-checked-in response

   >>REQUEST

     CHECKOUT /foo.html HTTP/1.1
     Host: www.webdav.org

   >>RESPONSE

     HTTP/1.1 409 Conflict
     Content-Type: text/xml; charset="utf-8"
     Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <D:error xmlns:D="DAV:">
       <D:must-be-checked-in/>
     </D:error>

   In this example, the request to CHECKOUT /foo.html fails because
   /foo.html is not checked in.

1.7 Clarification of COPY Semantics with Overwrite:T

   RFC 2518, Section 8.8.4 states:

   "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



Clemm, et al.               Standards Track                    [Page 13]

RFC 3253            Versioning Extensions to WebDAV           March 2002


   of its corresponding member.  If a client wishes all resources at 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.

1.8 Versioning Methods and Write Locks

   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.

2  Basic Versioning Features

   Each basic versioning feature defines extensions to existing HTTP and
   WebDAV methods, as well as new resource types, live properties, and
   methods.

2.1 Basic Versioning Packages

   A server MAY support any combination of versioning features.
   However, in order to minimize the complexity of a WebDAV basic
   versioning client, a WebDAV basic versioning server SHOULD support
   one of the following three "packages" (feature sets):

   -  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





Clemm, et al.               Standards Track                    [Page 14]

RFC 3253            Versioning Extensions to WebDAV           March 2002


   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.











Clemm, et al.               Standards Track                    [Page 15]

RFC 3253            Versioning Extensions to WebDAV           March 2002


2.2 Basic Versioning Semantics

2.2.1 Creating a Version-Controlled Resource

   In order to track the history of the content and dead properties of a
   versionable resource, a user can put the resource under version
   control with a VERSION-CONTROL request.  A VERSION-CONTROL request
   performs three distinct operations:

   1) It creates a new "version history resource".  In basic versioning,
      a version history resource is not assigned a URL, and hence is not
      visible in the http scheme URL space.  However, when the version-
      history feature (see Section 5) is supported, this changes, and
      each version history resource is assigned a new distinct and
      unique server-defined URL.

   2) It creates a new "version resource" and adds it to the new version
      history resource.  The body and dead properties of the new version
      resource are a copy of those of the versionable resource.

      The server assigns the new version resource a new distinct and
      unique URL.

   3) It converts the versionable resource into a "version-controlled
      resource".  The version-controlled resource continues to be
      identified by the same URL that identified it as a versionable
      resource.  As part of this conversion, it adds a DAV:checked-in
      property, whose value contains the URL of the new version
      resource.

   Note that a versionable resource and a version-controlled resource
   are not new types of resources (i.e. they introduce no new
   DAV:resourcetype), but rather they are any type of resource that
   supports the methods and live properties defined for them in this
   document, in addition to all the methods and live properties implied
   by their DAV:resourcetype.  For example, a collection (whose