information must be standardized so that the basic information can be
   used by all clients. Other specialized formats should be
   accommodated, for servers and clients that require information that
   cannot be included in the standard topology.

   5.9.2.8. A client must be able to propose a version identifier to be
   used for a new member of a version graph. The server may refuse to
   use the client's suggested version identifier.  The server should
   tell the client what version identifier it has assigned to the new
   member of the version graph.

   5.9.2.9. A version identifier must be unique across a version graph.

   5.9.2.10. A client must be able to supply version-specific properties
   to be associated with a new member of a version graph. (See Section
   5.1 "Properties" above.) At a minimum, it must be possible to
   associate comments with the new member, explaining what changes were
   made.

   5.9.2.11. A client must be able to query the server for information
   about a version tree, including which versions are locked, which are
   reserved for editing, and by whom (Session Tracking).

5.9.3. Rationale

   Versioning in the context of the world-wide web offers a variety of
   benefits:

   It provides infrastructure for efficient and controlled management of
   large evolving web sites. Modern configuration management systems are
   built on some form of repository that can track the revision history
   of individual resources, and provide the higher-level tools to manage
   those saved versions. Basic versioning capabilities are required to
   support such systems.







 
RFC 2291          Distributed Authoring and Versioning     February 1998


   It allows parallel development and update of single resources. Since
   versioning systems register change by creating new objects, they
   enable simultaneous write access by allowing the creation of variant
   versions. Many also provide merge support to ease the reverse
   operation.

   It provides a framework for coordinating changes to resources. While
   specifics vary, most systems provide some method of controlling or
   tracking access to enable collaborative resource development.

   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.

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

   It allows explicit semantic representation of single resources with
   multiple states. A versioning system directly represents the fact
   that a resource has an explicit history, and a persistent identity
   across the various states it has had during the course of that
   history.

5.10. Variants

   Detailed requirements for variants will be developed in a separate
   document.

5.10.1. Functional Requirements

   It must be possible to send variants to the server, describing the
   relationships between the variants and their parent resource.  In
   addition, it must be possible to write and retrieve variants of
   property labels, property descriptions, and property values.

5.10.2. Rationale

   The HTTP working group is addressing problems of content negotiation
   and retrieval of variants of a resource.  To extend this work to an
   authoring environment, WEBDAV must standardize mechanisms for authors
   to use when submitting variants to a server.  Authors need to be able
   to provide variants in different file or document formats, for
   different uses. They need to provide variants optimized for different




 
RFC 2291          Distributed Authoring and Versioning     February 1998