Note that this document is laughably obsolete.  I'll leave it up here for historic reasons, and because disk space is cheap, and because I'm feeling too lazy to take it down.  But don't rely on it.  :-)

(editorial notes in red) (and there are plenty of them, because I won't be at the meeting at Intersolv, because I'll be on sabbatical)

(I will turn this HTML into plaintext later)
WEBDAV Working Group J. Stracke
<draft-ietf-webdav-versionreqs-00.html> October 21st, 1998
Expires April, 1999

Goals for Versioning Extensions to WebDAV

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on (Africa), (Northern Europe), (Southern Europe), (Pacific Rim), (US East Coast), or (US West Coast).

Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WEBDAV) working group at <>, which may be joined by sending a message with subject "subscribe" to <>.

Discussions of the WEBDAV working group are archived at<URL:>.


This document specifies goals for versioning extensions to [WEBDAV].  It supersedes the versioning-related goals of [WEBDAV-GOALS].


Status of this Memo 1
Security Considerations


Versioning and configuration management are important features for remote authoring of Web content.  Versioning management is concerned with tracking and accessing the history of important states of a single Web resource, such as a standalone Web page.  Configuration management addresses the problems of tracking and accessing multiple interrelated resources over time as sets of resources, not simply individual resources.  Traditionally, artifacts of software development, including code, design, test cases, requirements, help files, and more have been a focus of configuration management.  Web sites, comprised of multiple interlinked resources (HTML, graphics, sound, CGI, and others), are another class of complex information artifacts that benefit from the application of configuration management.

The WebDAV working group originally focused exclusively on defining version management capabilities for remote authoring applications, and group consensus on these features is reflected in [WEBDAV-GOALS]. However, as the WebDAV working group has constructed protocols for versioning functionality, it has become clear that while versioning functionality alone provides useful functionality for a range of content authoring scenarios involving one, or a small set of resources, versioning alone is insufficient for managing larger sets of content. Protocol support for simple remote configuration management of Web resources provides functionality for managing large sets of interrelated content.

This document describes functional goals for configuration management of Web resources which replace the existing functional goals for versioning capability described in [WEBDAV-GOALS], section 5.9.  (This document formerly included goals for variants; but, at the FileNet meeting, we agreed that variants were an orthogonal problem.)


  1. versioned resource is an abstraction for a resource which is subject to version control; that is, as it is edited, the editor submits interim states to be stored indefinitely, so that the evolution of the resource can be tracked.  Versioned resources may not actually exist as resources; it is a concept that makes it easier to discuss versioning.
  2. revision is a particular version of a versioned resource.
  3. revision name is a unique name which can be used to refer to a revision of a versioned resource.  (This is a superclass of revision ID and label, to make it easier to talk about the combined space.)
  4. revision ID is a revision name which is assigned by the server when the revision is created and which cannot be changed to refer to a different revision.  (This is slightly different from the wording agreed on at FileNet, which was "A revision ID is a unique, immutable name which can be used to refer to a revision of a versioned resource, and which is assigned by the server when the revision is created".  I moved the "uniqueness" and the "refer to" clause to the superclass, and replaced "immutable" with its definition.)
  5. label is a revision name which may be assigned to a revision at some time after the revision is created, and which can be changed to refer to a different revision.  (Again, this is slightly changed because of the superclassing; the agreed wording before was "A label is a movable name which, within a versioned resource, serves as an alias for a revision ID".)
  6. revision history (also called a version graph) is a resource (there was a proposal to strike "resource", but we did not reach consensus--I believe it should not be struck; see of [WEBDAV-GOALS]) which represents relationships among revisions of a single versioned resource as a directed acyclic graph (DAG).
  7. Branching is a capability which permits a revision to have multiple successors.
  8. A configuration set is a set of versioned resources and versioned collections.
  9. A configuration is a set of resources where each resource is a revision of one versioned resource or collection contained by a configuration set.
  10. Configuration management (CM) is the ability to access and manipulate configurations as first-order entities, rather than by working on each versioned resource independently.
  11. All the configuration definitions are to be refined.
  12. A working resource is an editable resource created at checkout time.


(The "map reasonably well to most existing version repositories" goal was struck as being both too vague and too obvious.)

(I have left goal numbers unchanged; we'll renumber them once it's ready to publish as a Draft.)

1. It must be possible to version resources of any media type.

2.  Every revision of a versioned resource must itself be a resource, with its own URI.

See section of [WEBDAV-GOALS].  This goal has two motivations: first, to permit revisions to be referred to, so that (for example) a document comparing two revisions can include a link to each; second, so that revisions can be treated as resources for the purposes of DAV methods such as PROPFIND (assuming they reside on DAV servers, which may not always be the case: for example, if one were to develop an RFC using DAV, then the URIs for the RFC and the published Drafts would be ftp: URLs.)

3.  It should be possible for a client to specify meaningful labels to apply to individual revisions, and to change a label to refer to a different revision.

Although unique revision IDs are assigned by the server, human-meaningful aliases are often useful.  For example, a label called "CustomerX" could be assigned to the latest revision of a document which has been delivered to customer X; when X calls to inquire about the document, the author(s) can simply refer to the label, rather than maintaining a separate database of which revisions have been shipped to which customers.  In addition, it is possible to implement configuration management by applying the same alias to one revision of each of a set of resources, as in [CVS].

3a.  It must be possible to use the same label for different versioned resources.  (Came out of the FileNet meeting.)

4.  The labels and revision IDs within a Vgraph are names in a common namespace, in which each name must be unique.  The server may partition this namespace syntactically, in order to distinguish labels from IDs.

That is, the same label cannot apply to multiple revisions; the same revision ID cannot apply to multiple revisions; and no label can also be a revision ID, or vice versa.  To enforce uniqueness, a server will have to reject labels which it might eventually use as revision IDs; the simplest way to do this is to partition the namespace.

5.  Given a URI to a versioned resource, and a revision name, it must be possible for a client to obtain a URI which refers to that revision.  These URIs should be compatible with relative URLs.

It would be a useful feature if a server used a consistent scheme for constructing these URIs, so that a server-aware client could construct them without quering.  However, this scheme probably cannot be standardized, as that would impose too much syntactic meaning on URIs.

6.  If the DAV server supports searching, it should be possible to narrow the scope of a search to the revisions of a particular versioned resource.

It is often the case that one needs to find, for example, the first revision at which a particular phrase was introduced, or all the revisions authored by a particular person.  Given search capabilities for collections, it would be far more sensible to leverage those capabilities than to define a separate search protocol for version graphs.  For example, if the server supports [DASL], then the version graphs could be searched via DASL operations.

(This goal was originally written as "If the DAV server supports [DASL]...", but JimW pointed out that this document might be consulted at some hypothetical future time when DASL has been supplanted by, say, WISHING [Wildly Interactive Search Harness Including No Gaps].)

6a.  If the DAV server supports searching, revision IDs and label names should be searchable properties.

(I have this recorded as a goal, but I'm not sure quite what this means--searchable properties of what? The revision?)

7.  The CM protocol must be an optional extension to the base versioning protocol.

There is some debate in the working group over the value of CM.  Everyone more or less agrees that CM is usually necessary for software, and rarely necessary in the case of simple textual documents; the debate is over whether a typical Web site is closer to software or to text.  The truce agreed to at the Chicago meeting was to continue work on CM, but not to make it a mandatory part of the protocol.

8.  Revisions are immutable: once a revision has been checked in (frozen), its contents and dead properties can never be changed.

8a.  On each frozen revision, there may be properties whose values may be changed without creating a new revision.  The list of these properties must be discoverable.

8b. Deleting a revision should be a high-privilege operation.

8c.  Once a revision has been deleted, its ID cannot be reused.

In many cases, it is necessary to be able to guarantee (as far as possible) that one can retrieve the exact state of a resource at a particular point in history, and/or all the states which the resource has ever taken on.  For example, if a company is sued for violating a warranty which the plaintiff read on the company's Web site, it may be useful to be able to prove that the warranty never contained the provision which the plaintiff says it did (contrariwise, it may be useful for the plaintiff to be able to prove that it did).  A version graph all of whose revisions were immutable would provide this sort of ability.

Of course, DAV cannot preclude the possibility of an out-of-band method to change or delete a revision; an implementation may provide an administrative interface to do it, and one can always go directly to the filesystem.  But such access would at least be limited to trusted administrators.

(Goals 9 and 10 are tentative; they must wait until we've defined configurations better.  I have left them in place for the time being, for informational purposes.)

9.  It should be possible to assign a configuration a simple identifier known as a configuration identifier.

This identifier would serve the same role as a label: it would permit a client to refer to a given configuration via a meaningful name.

10.  It should be possible to check out, or check in, a configuration set in a single operation.

11.  It must be possible to query a revision history to learn the predecessors and successors of a particular revision, as well as the root and default revisions.

If a client wishes to present a user interface for browsing the revisions of a particular versioned resource, it must be able to read the relationships represented within the DAG.

12.  It should be possible to obtain the entire revision history of a versioned resource in one operation.

A client which wishes to display a map of the Vgraph should not have to make queries on each individual revision within the DAG; it should be able to obtain all the information at once, for efficiency's sake.

13. The protocol must support branching as an optional capability.

14.  The protocol must support the following operations:

  1. Creating revisions:
    1. Obtain the URI of a revision
    2. Check out a revision
    3. Check in a working resource
  2. Labels:
    1. Create a label
    2. Change the revision to which a label refers
  3. Branches:
    1. Create a branch
    2. merge a branch (probably by hand)
  4. Configurations:
    1. create a configuration
    2. add/remove revisions from a configuration
Some of these operations come from [WEBDAV-GOALS], section  Not all of the operations in that section are replicated here; some of them (e.g., locking) fall out naturally from the fact that a revision is a resource.

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

15.  For each operation that the protocol defines, the protocol must define that operation's interaction with all existing [WebDAV] methods on all existing WebDAV resources.

16.   Versioning Policies. Many writers, 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.

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

18. There must be a way to refer to a server-defined default revision of a versioned resource.

The server should return a default revision of a resource for requests that ask for the default revision, 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 revision of a versioned resource. For example, there may be a current revision for editing that is different from the default revision. For a graph with several branches, it may be useful to be able to request the tip revision of any branch.

19. It must be possible, given a reference to a revision of a versioned resource, to find out which versioned resource that revision belongs to.

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


(This section is copied verbatim from [WEBDAV-GOALS], section 5.9.3.)

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.

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.


These nongoals enumerate functionality which the working group has explicitly agreed to exclude from this document; they are documented here for explanatory purposes.  (I invite comments on the explanations of why the nongoals are not goals, as these explanations are largely out of my own head--all I wrote down at the meeting was the nongoals themselves.)
  1. Revisions in multiple version graphs (see [WEBDAV-GOALS], sections and  This capability was felt to be too rarely useful.
  2. Federated version graphs (that is, version graphs which are not stored on a single server).  This capability would introduce great difficulties.  A server implementor who needs it can use out-of-band server-to-server communication; but this communication is arguably out of the scope of WebDAV, which is a client-to-server protocol.
  3. Client-proposed version identifiers (see [WEBDAV-GOALS], section  Labels do the job better.

Security Considerations

To be written.  It is likely that implementing features to meet the goals described here will present few or no new security risks beyond those of base DAV.  One possible exception is that it may become more difficult to hide the contents of a resource when there may exist other versions with different access control lists.


[WEBDAV]Y.Y. Goland, E.J. Whitehead, Jr., A. Faizi, S.R. Carter, D. Jensen, "Extensions for Distributed Authoring on the World Wide Web -- WEBDAV", Internet-Draft draft-ietf-webdav-protocol-08. April, 1998.
[WEBDAV-GOALS] J. Slein, F. Vitali, J. Whitehead, D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC-2291.  February 1998.
[WEBDAV-ACP] J. Slein, J. Davis, A. Babich, J. Whitehead, "WebDAV Advanced Collections Protocol", Internet-Draft draft-ietf-webdav-collection-protocol-01.txt.  July 1998.
[DASL] S. Reddy, D. Jensen, S. Reddy, R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating", Internet-Draft draft-reddy-dasl-protocol-02.txt.  July 1998.