between a URL hierarchy level and the notion of a collection. One
   example is a server in which the URL hierarchy level maps to a
   computational process which performs some resolution on the name. In
   this case, the contents of the URL hierarchy level can vary depending
   on the input to the computation, and the number of resources
   accessible via the computation can be very large. It does not make
   sense to implement a directory feature for such a name space.
   However, the utility of listing the contents of those URL hierarchy
   levels which do correspond to collections, such as the large number
   of HTTP servers which map their name space to a filesystem, argue for
   the inclusion of this capability, despite not being meaningful in all






 
RFC 2291          Distributed Authoring and Versioning     February 1998


   cases. If listing the contents of a URL hierarchy level does not
   makes sense for a particular URL, then a "405 Method Not Allowed"
   status code could be issued.

   The ability to create collections to hold related resources supports
   management of a name space by packaging its members into small,
   related clusters. The utility of this capability is demonstrated by
   the broad implementation of directories in recent operating systems.
   The ability to create a collection also supports the creation of
   "Save As..." dialog boxes with "New Level/Folder/Directory"
   capability, common in many applications.

5.9. Versioning

5.9.1. Background and General Principles

   5.9.1.1. Stability of versions. Most versioning systems are intended
   to provide an accurate record of the history of evolution of a
   document. This accuracy is ensured by the fact that a version
   eventually becomes "frozen" and immutable. Once a version is frozen,
   further changes will create new versions rather than modifying the
   original. In order for caching and persistent references to be
   properly maintained, a client must be able to determine that a
   version has been frozen. Any successful attempt to retrieve a frozen
   version of a resource will always retrieve exactly the same content,
   or return an error if that version (or the resource itself) is no
   longer available.

   5.9.1.2. Operations for Creating New Versions.  Version management
   systems vary greatly in the operations they require, the order of the
   operations, and how they are combined into atomic functions.  In the
   most complete cases, the logical operations involved are:

        o Reserve existing version
        o Lock existing version
        o Retrieve existing version
        o Request or suggest identifier for new version
        o Write new version
        o Release lock
        o Release reservation

   With the exception of requesting a new version identifier, all of
   these operations have applications outside of versioning and are
   either already part of HTTP or are discussed in earlier sections of
   these requirements. Typically, versioning systems combine
   reservation, locking, and retrieval -- or some subset of these --
   into an atomic checkout function.  They combine writing, releasing





 
RFC 2291          Distributed Authoring and Versioning     February 1998


   the lock, and releasing the reservation -- or some subset of these --
   into an atomic checkin function.  The new version identifier may be
   assigned either at checkout or at checkin.

   The WebDAV extensions must find some balance between allowing
   versioning servers to adopt whatever policies they wish with regard
   to these operations and enforcing enough uniformity to keep client
   implementations simple.

   5.9.1.3. The Versioning Model.  Each version typically stands in a
   "derived from" relationship to its predecessor(s).  It is possible to
   derive several different versions from a single version (branching),
   and to derive a single version from several versions (merging).
   Consequently, the collection of related versions forms a directed
   acyclic graph.  In the following discussion, this graph will be
   called a "version graph".  Each node of this graph is a "version" or
   "member of the version graph".  The arcs of the graph capture the
   "derived from" relationships.

   It is also possible for a single resource to participate in multiple
   version graphs.

   The WebDAV extensions should support this versioning model, though