particular servers may restrict it in various ways.

   5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and
   Haake and Hicks [VSE], have discussed the notion of versioning styles
   (referred to here as versioning policies, to reflect the nature of
   client/server interaction) as one way to think about the different
   policies that versioning systems implement. Versioning policies
   include decisions on the shape of version histories (linear or
   branched), the granularity of change tracking, locking requirements
   made by a server, etc. The protocol should clearly identify the
   policies that it dictates and the policies that are left up to
   versioning system implementors or administrators.

   5.9.1.5. It is possible to version resources of any media type.

5.9.2. Functional Requirements

   5.9.2.1. Referring to a version graph. There must be a way to refer
   to a version graph as a whole.

   Some queries and operations apply, not to any one member of a version
   graph, but to the version graph as a whole.  For example, a client
   may request that an entire graph be moved, or may ask for a version
   history. In these cases, a way to refer to the whole version graph is
   required.




 
RFC 2291          Distributed Authoring and Versioning     February 1998


   5.9.2.2. Referring to a specific member of a version graph. There
   must be a way to refer to each member of a version graph. This means
   that each member of the graph is itself a resource.

   Each member of a version graph must be a resource if it is to be
   possible for a hypertext link to refer to specific version of a page,
   or for a client to request a specific version of a document for
   editing.

   5.9.2.3. A client must be able to determine whether a resource is a
   version graph, or whether a resource is itself a member of a version
   graph.

   A resource may be a simple, non-versioned resource, or it may be a
   version graph, or it may be a member of a version graph.  A client
   needs to be able to tell which sort of resource it is accessing.

   5.9.2.4. There must be a way to refer to a server-defined default
   member of a version graph.

   The server should return a default version of a resource for requests
   that ask for the default version, as well as for requests where no
   specific version information is provided. This is one of the simplest
   ways to guarantee non-versioning client compatibility. This does not
   rule out the possibility of a server returning an error when no
   sensible default exists.

   It may also be desirable to be able to refer to other special members
   of a version graph. For example, there may be a current version for
   editing that is different from the default version.  For a graph with
   several branches, it may be useful to be able to request the tip
   version of any branch.

   5.9.2.5. It must be possible, given a reference to a member of a
   version graph, to find out which version graph(s) that resource
   belongs to.

   This makes it possible to understand the versioning context of the
   resource. It makes it possible to retrieve a version history for the
   graphs to which it belongs, and to browse the version graph. It also
   supports some comparison operations: It makes it possible to
   determine whether two references designate members of the same
   version graph.

   5.9.2.6. Navigation of a version graph.  Given a reference to a
   member of a version graph, it must be possible to discover and access
   the following related members of the version graph.





 
RFC 2291          Distributed Authoring and Versioning     February 1998


        o root member of the graph
        o predecessor member(s)
        o successor member(s)
        o default member of the graph

   It must be possible in some way for a versioning client to access
   versions related to a resource currently being examined.

   5.9.2.7. Version Topology. There must be a way to retrieve the
   complete version topology for a version graph, including information
   about all members of the version graph. The format for this