| WEBDAV Working Group | J. Stracke |
| INTERNET DRAFT | Netscape |
| <draft-ietf-webdav-versionreqs-00.html> | October 21st, 1998 |
| Expires April, 1999 |
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 ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WEBDAV) working group at <w3c-dist-auth@w3.org>, which may be joined by sending a message with subject "subscribe" to <w3c-dist-auth-request@w3.org>.
Discussions of the WEBDAV working group are archived at<URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
| Status of this Memo | 1 |
| Abstract | |
| Contents | |
| Introduction | |
| Definitions | |
| Goals | |
| Nongoals | |
| Security Considerations | |
| References |
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.)
(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 5.9.2.2 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:
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.
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.