rfc3253.txt

RFC 的详细文档！

   16.3 Security Through Obscurity...................................108
   16.4 Denial of Service............................................108
   17  IANA Considerations...........................................109
   18  Intellectual Property.........................................109
   19  Acknowledgements..............................................109
   20  References....................................................110
   Appendix A - Resource Classification..............................111
   A.1 DeltaV-Compliant Unmapped URL.................................111
   A.2 DeltaV-Compliant Resource.....................................111
   A.3 DeltaV-Compliant Collection...................................112
   A.4 Versionable Resource..........................................112
   A.5 Version-Controlled Resource...................................112
   A.6 Version.......................................................113
   A.7 Checked-In Version-Controlled Resource........................113
   A.8 Checked-Out Resource..........................................113
   A.9 Checked-Out Version-Controlled Resource.......................114
   A.10 Working Resource.............................................114
   A.11 Version History..............................................114
   A.12 Workspace....................................................115
   A.13 Activity.....................................................115
   A.14 Version-Controlled Collection................................115
   A.15 Collection Version...........................................115
   A.16 Version-Controlled Configuration.............................116
   A.17 Baseline.....................................................116
   A.18 Checked-Out Version-Controlled Configuration.................116
   Authors' Addresses................................................117
   Full Copyright Statement..........................................118

1  Introduction

   This document specifies a set of methods, headers, and properties
   that define the WebDAV (Web Distributed Authoring and Versioning)
   versioning extensions to the HTTP/1.1 protocol.  Versioning is
   concerned with tracking and accessing the history of important states
   of a web resource, such as a standalone web page.  The benefits of
   versioning in the context of the worldwide web include:







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


   -  A resource has an explicit history and a persistent identity
      across the various states it has had during the course of that
      history.  It allows browsing through past and alternative versions
      of a resource.  Frequently the modification and authorship history
      of a resource is critical information in itself.

   -  Resource states (versions) are given stable names that can support
      externally stored links for annotation and link server support.
      Both annotation and link servers frequently need to store stable
      references to portions of resources that are not under their
      direct control.  By providing stable states of resources, version
      control systems allow not only stable pointers into those
      resources, but also well defined methods to determine the
      relationships of those states of a resource.

   WebDAV Versioning defines both basic and advanced versioning
   functionality.

   Basic versioning allows users to:

   -  Put a resource under version control
   -  Determine whether a resource is under version control
   -  Determine whether a resource update will automatically be captured
      as a new version
   -  Create and access distinct versions of a resource

   Advanced versioning provides additional functionality for parallel
   development and configuration management of sets of web resources.

   This document will first define the properties and method semantics
   for the basic versioning features, and then define the additional
   properties and method semantics for the advanced versioning features.
   An implementer that is only interested in basic versioning should
   skip the advanced versioning sections (Section 10 to Section 14).

1.1 Relationship to WebDAV

   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.




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


1.2 Notational Conventions

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

1.3 Terms

   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.



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


   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.



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


   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.




























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


   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
                      ^  +---+       +---+