WebDAV Working Group G. Clemm INTERNET-DRAFT Rational Software draft-clemm-webdav-versioning-00 Expires July 26, 1999 January 26, 1999 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 made obsolete 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (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 , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . Abstract This document specifies a set of methods, headers, and content-types composing the DAV Versioning extensions, an application of the HTTP/1.1 protocol to version DAV resources. draft-clemm-webdav-versioning-00 [Page 1] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 1. Introduction In this proposal, WebDAV is extended with two classes of versioning support: document-management and configuration-management. To maximize interoperability and maximize use of existing protocol functionality, document-management is defined as a proper superset of the WebDAV advanced-collection protocol, and configuration-management is defined as a proper superset of the document-management protocol. 1.1. Versioning and Locking These versioning protocols are designed so that WebDAV locking (class 2) support is completely optional. A lock will have it's usual semantics, but nothing in either of the versioning protocols depends on the presence of locking support. 2. Document-Management Protocol Document-management is the simpler versioning protocol designed to support versioning of largely independent resources. It allows you to concurrently access and modify distinct mutable-revisions of a resource. 2.1. Document-Management Resource Types Document-management introduces the following additional resource types: 2.1.1. Versionable-Resource A versionable-resource is just a standard resource not yet put under version control. A null-resource is a versionable resource. 2.1.2. Versioned-Resource A versioned-resource is a resource that collects and controls all the revisions for a resource that has been put under version control. 2.1.3. Mutable-Revision A mutable-revision is a resource that is associated with a versioned-resource, and that can be in either a checked-out (writeable) or checked-in (readonly) state. 2.1.4. VPortal A vportal is a special kind of reference whose DAV:reftarget property is the URL of a versioned-resource. Reading and writing the body of draft-clemm-webdav-versioning-00 [Page 2] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 a mutable-revision can only be done through a vportal. When a PUT is successfully applied to a vportal, a server MAY make that change visible at other vportals that select that same mutable- revision. When a CHECKIN is successfully applied to a vportal, the state of the mutable-revision at that vportal MUST be made visible at all other vportals that select that same mutable-revision. This allows the server to cache the PUT information at the vportal, and only force the update when the CHECKIN is performed. A vportal otherwise has all the properties and behavior of a normal reference. [GMC: I would prefer to simplify the spec by requiring that the change is NEVER visible at another vportal until the CHECKIN is applied, but I was concerned that some would not find this acceptable]. 2.2. Document Management Properties Document-management introduces the following additional properties: 2.2.1. Versioned-Resource Properties Document-management introduces the following additional properties for a versioned-resource: 2.2.1.1. DAV:mutable-revisions (readonly collection) The DAV:mutable-revisions collection of a versioned-resource contains all mutable-revisions of that versioned-resource, where the name of a mutable-revision in the DAV:mutable-revisions collection is its DAV:mutable-revision-id. PROPFIND can then be used to gather arbitrary information about the mutable-revisions. 2.2.1.2. DAV:mutable-revision-labels (writeable collection) The DAV:mutable-revision-labels collection of a versioned-resource contains references to members of the DAV:mutable-revisions collection of that versioned-resource. The client can add and delete members of the DAV:mutable-revision-labels collection. No member of this collection can have the same name as a member of the DAV:mutable-revisions collection. 2.2.2. Mutable-Revision Properties Document-management introduces the following additional properties for a mutable-revision: draft-clemm-webdav-versioning-00 [Page 3] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 2.2.2.1. DAV:mutable-revision-id (readonly, immutable) The DAV:mutable-revision-id is an identifier assigned to a mutable- revision by the server. At most one mutable-revision of a given versioned-resource will have a particular identifier. 2.2.2.2. DAV:reservation (readonly, immutable) When the DAV:reservation property of a mutable-revision is set, the mutable-revision is in a checked-out writeable state. If the DAV:reservation is not set, the mutable-revision is in a checked-in readonly state. 2.2.2.3. DAV:predecessor (readonly, immutable) The DAV:predecessor property of a mutable-revision indicates the mutable-revision that was selected by the vportal immediately prior to the CHECKOUT-NEW request that created this mutable-revision. The DAV:predecessor property is null for the initial mutable-revision created by a CONTROL request. 2.2.2.4. DAV:successors (readonly collection, mutable) The DAV:successors collection of a mutable-revision contains references to each mutable-revisions whose DAV:predecessor property specifies this mutable-revision. 2.2.2.5. DAV:auto-check-in-out (writeable, immutable) When the DAV:auto-check-in-out property of a mutable-revision is set, an HTTP-1.1 PUT request to a vportal selecting this mutable-revision is automatically preceded by an automatic CHECKOUT and followed by an automatic CHECKIN. This allows a downlevel client to modify a version-controlled resource if it is not currently checked-out. 2.2.3. VPortal Properties Document-management introduces the following additional properties for a vportal: 2.2.3.1. DAV:mutable-revision-name (writeable) The DAV:mutable-revision-name property of a vportal contains the name of a member of either the DAV:mutable-revisions or DAV:mutable- revision-labels collections of the versioned-resource referenced by that vportal. This is the mutable-revision that this vportal will select unless an explicit Mutable-Revision-Name header is specified. draft-clemm-webdav-versioning-00 [Page 4] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 2.3. Document-Management Methods Document-management introduces the following additional methods: 2.3.1. CONTROL A CONTROL request can be applied to a versionable-resource. When a CONTROL request is applied to a versionable-resource, a new versioned-resource is created (at a server-assigned URL), an initial checked-out mutable-revision for that versioned-resource is created (again, at a server-assigned URL), the versionable resource is copied to the new mutable-revision, and then the versionable-resource is replaced with a vportal that refers to the new versioned-resource and whose DAV:mutable-revision-name property is set to be the name of the initial mutable-revision. When the versionable-resource is a null- resource, the body of the initial-revision is empty. A CONTROL request replaces the original versionable-resource with a vportal to ensure that the entire versioned-resource is not deleted when a DELETE or MOVE is applied to the original URL of the versionable-resource. This ensures that other vportals to that versioned-resource (for example, ones that select different mutable- revisions) continue to be valid, and that even when all vportals to that versioned-resource have been deleted, the versioned-resource and its revisions are retained for historical access. If the client really wants to delete that versioned-resource and all its mutable- revisions, DELETE can be applied to the URL of the versioned-resource itself. 2.3.2. MKVPORTAL A MKVPORTAL request is used by the client to create a new vportal to an existing versioned-resource. A client can modify the DAV:mutable-revision-name property of the vportal to cause it to select a different mutable-revision of that versioned-resource. [GMC: MKVPORTAL could just be an optional header to CONTROL, if we wanted to minimize the number of new methods.] 2.3.3. CHECKIN When a CHECKIN request is applied to a vportal, the mutable-revision selected by that vportal is made readonly if it is currently checked-out. A CHECKIN request will fail if the mutable-revision is already checked-in. 2.3.4. CHECKOUT When a CHECKOUT request is applied to a vportal, the mutable-revision draft-clemm-webdav-versioning-00 [Page 5] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 selected by that vportal is made writeable if it is currently checked-in. A CHECKOUT request will fail if the mutable-revision is already checked-out. 2.3.5. CHECKOUT-NEW When a CHECKOUT-NEW request is applied to a vportal, rather than checking out the mutable-revision selected by that vportal, a new mutable-revision for that versioned-resource is created, and the DAV:mutable-revision-name property of the vportal is modified to contain the name of the new mutable-revision. The new mutable- revision is created in a checked-out state and is therefore writeable until it is subsequently checked-in. The creation of a new mutable-revision of a versioned-resource has no effect on vportals that select other mutable-revisions of that versioned-resource. Similarly, the checked-in or checked-out state of one mutable-revision is independent of the checked-in or checked- out state of any other mutable-revision. 2.4. Document-Management Headers Document management introduces the following additional headers: 2.4.1. Mutable-Revision-Name The Mutable-Revision-Name header is used to override the name specified in the DAV:mutable-revision-name property of a vportal. 3. Configuration-Management Protocol Configuration management is a more comprehensive versioning protocol, designed to support consistent versioning of sets of related resources being modified in parallel by many authors at different sites. The set of resources will commonly be a subtree of the URL space at a web site, an entire web site, or a set of subtrees at several web sites. The resources are related by the use of both relative and absolute URL references. To provide a stable environment for authoring and change control, controlled sharing between distinct workspaces is supported, in addition to the branching and merging support required for reliable parallel authoring. In order to maintain the validity of inter-resource references, versioning the URL namespace (via versioned collections) is as important as versioning the individual documents. 3.1. Configuration-Management Resource Types Configuration-management introduces the following additional resource draft-clemm-webdav-versioning-00 [Page 6] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 types: 3.1.1. Working-Resource A working-resource of a versioned-resource is a writeable resource that is created by CHECKOUT or CONTROL. On a configuration- management server, a checked-out mutable-revision of a versioned- resource is just a reference to a working-resource of that versioned-resource. 3.1.2. Immutable-Revision An immutable-revision of a versioned-resource is a resource created by applying a CHECKIN request to a working-resource. The body and immutable properties of an immutable-revision cannot be modified. On a configuration-management server, a checked-in mutable-revision of a versioned-resource will always be a reference to an immutable- revision of that versioned-resource, and the "CHECKIN history" of a mutable-revision is captured by a sequence of immutable-revisions. 3.1.3. Versioned-Collection A versioned-collection is a collection that has been placed under version-control. Versioned-collections are an essential component of configuration-management, because they provide the mechanism for controlling the URL namespace of a set of related resources. A collection can be placed under version control only if every member of that collections is also under version control, therefore every member of a revision of a versioned-collection is either a vportal or a reference to a vportal. 3.1.4. Configuration A configuration of a versioned-collection provides an immutable snapshot of a URL tree of resources rooted at that versioned- collection. To be precise, a configuration of a versioned-collection selects an immutable-revision of that versioned-collection, and selects an immutable-revision of every immediate member of any versioned-collection revision in the configuration. Therefore, a configuration of the root collection of a web site specifies a specific state of the web-site as a whole. 3.1.5. Activity An activity is a resource that represents a single logical change that may involve modifications to several versioned-resources. The activity collects all immutable-revisions that are created in the process of performing that logical change. An activity is like a draft-clemm-webdav-versioning-00 [Page 7] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 mutable-revision label, in that it allows you to give a meaningful name to a particular line of descent, but instead of naming a line of descent in just a single versioned-resource, an activity names related lines of descent in a set of versioned-resources. 3.1.6. Workspace Finally, a workspace is a resource that describes how version selection is to be done across an entire web site. When a versioned-resource is checked out, it is always checked out into a specific workspace. Thus a workspace serves the same purpose for a web site as a whole, as a single working-resource does for a single versioned-resource. The root collection of a web site has a property indicating the default workspace for that web site. A Workspace header can be used to select a non-default workspace for a request. In addition, a workspace can be specified as the DAV:workspace property of a vportal to make that the default workspace of the vportal. 3.2. Configuration-Management Properties Configuration-management introduces the following additional properties: 3.2.1. Root-Collection Properties Configuration-management introduces the following additional properties for the root collection of a Web site: 3.2.1.1. DAV:default-workspace (readonly) The DAV:default-workspace property specifies which workspace will be used for a request that does contain an explicit Version-Control header. If a vportal has no explicit DAV:workspace property, the default workspace of the web site will be used. 3.2.1.2. DAV:activities (writeable collection) The DAV:activities collection of the root collection of a Web site contains the activities created at that Web site. 3.2.1.3. DAV:workspaces (writeable collection) The DAV:workspaces collection of the root collection of a Web site contains the workspaces created at that Web site. draft-clemm-webdav-versioning-00 [Page 8] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.2.2. Versioned-Resource Properties Configuration-management introduces the following additional properties for a versioned-resource: 3.2.2.1. DAV:immutable-revisions (readonly collection) The DAV:immutable-revisions collection of a versioned-resource contains all the immutable-revisions of that versioned-resource. The name of an immutable-revision in this collection is assigned by the server. 3.2.2.2. DAV:working-resources (readonly collection) The DAV:working-resources collection of a versioned-resource contains all working-resources of that versioned-resource. 3.2.3. Immutable-Revision Properties Configuration-management introduces the following additional properties for an immutable-revision: 3.2.3.1. DAV:immutable-revision-id (readonly, immutable) The DAV:immutable-revision-id is an identifier assigned to an immutable-revision by the server. At most one immutable-revision of a given versioned-resource will have a particular immutable-revision identifier. 3.2.3.2. DAV:immutable-predecessor (readonly, immutable) The DAV:immutable-predecessor is the immutable-revision that was checked-out to produce a working resource that was checked-in to produce this immutable-revision. 3.2.3.3. DAV:immutable-successors (readonly collection, mutable) The DAV:immutable-successors collection of an immutable-revision contains a reference to each immutable-revision whose DAV:predecessor is that immutable-revision. 3.2.3.4. DAV:merge-predecessors (writeable collection, mutable) The DAV:merge-predecessors collection of an immutable-revision contains references to the other immutable-revisions whose contents were explicitly merged by the client into that immutable-revision. The client is free to add or delete members to this collection in order to more accurately reflect the contents of that immutable- draft-clemm-webdav-versioning-00 [Page 9] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 revision. 3.2.3.5. DAV:merge-successors (writeable collection, mutable) The DAV:merge-successors collection of an immutable-revision contains a reference to each immutable-revision whose DAV:merge-predecessors collection contains a reference to that immutable-revision. 3.2.3.6. DAV:reservation (readonly, mutable) The DAV:reservation property of an immutable-revision contains the URL of a working-resource. When an immutable-revision is checked- out, the DAV:reservation property is set to be the working-resource resulting from the checkout. When a working-resource is checked-in, the DAV:reservation of the DAV:immutable-predecessor of the working- resource is removed. 3.2.4. Working-Resource Properties Configuration-management introduces the following additional properties for a working-resource: 3.2.4.1. DAV:immutable-predecessor (readonly) The DAV:immutable-predecessor of a working-resource is the immutable-revision that was checked-out to produce that working- resource. 3.2.4.2. DAV:merge-predecessors (writeable collection) The DAV:merge-predecessors collection of a working-resource contains references to the immutable-revisions whose contents were explicitly merged by the client into that working-resource. The client is free to add or delete members to this collection in order to more accurately reflect the contents of that working-resource. 3.2.4.3. DAV:workspace (readonly) The DAV:workspace property of a working-resource contains the URL of the current workspace when the working-resource was created by a checkout request. 3.2.4.4. DAV:activity (readonly) The DAV:activity property contains the DAV:activity value of the workspace into which the working-resource was checked out. draft-clemm-webdav-versioning-00 [Page 10] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.2.5. Workspace Properties Configuration-management introduces the following additional properties for a workspace: 3.2.5.1. DAV:revision-selection-rule (writeable) The DAV:revision-selection-rule of a workspace contains an XML document that describes how immutable-revision selection will be performed in that workspace. There will be standard elements for specifying common selection mechanisms such as by activity or by label, but additional revision-selection-rule elements may be supported by a WebDAV server. 3.2.5.2. DAV:merge-selection-rule (writeable) The DAV:merge-selection-rule of a workspace contains an XML document that describes what immutable-revisions should be merged into that workspace. The affect of the merge can be determined by a GET- CONFLICTS request to the workspace, and the merge itself can be performed by an UPDATE request. There will be standard elements for specifying common merge selection mechanisms such as by activity or by configuration, but additional merge-selection-rule elements may be supported by a WebDAV server. 3.2.5.3. DAV:auto-descendent-merge (writeable) When the DAV:auto-descendent-merge property of a workspace is set, and the merge-from immutable-revision (selected by the merge- selection-rule) is a descendent of the merge-to immutable-revision (selected by the revision-selection rule), the server performs the merge automatically when the workspace receives an UPDATE request. In particular, it checks out the merge-to immutable-revision, copies the merge-from immutable-revision to the new working-resource, adds the merge-from immutable-revision to the DAV:merge-predecessors of the working-resource, and checks in the working-resource. 3.2.5.4. DAV:activity (writeable) The DAV:activity property of a workspace contains the activity that captures the work currently being peformed in that workspace. The immutable-revisions selected by that activity take priority over the immutable-revisions selected by the revision-selection-rule. The working-resources checked-out into a workspace take priority over immutable-revisions selected by either the revision-selection-rule or by the workspace activity. Thus the version selection algorithm for a workspace is "checked-out to that workspace" else "a product of the workpace activity" else "selected by the workspace revision-selection draft-clemm-webdav-versioning-00 [Page 11] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 rule". 3.2.5.5. DAV:dynamic (writeable) The DAV:dynamic property indicates whether version selection for a workspace is computed dynamically, or whether it is computed only following an explicit UPDATE request on that workspace. 3.2.5.6. DAV:client-workspace (writeable) The DAV:client-workspace property indicates whether the working- resources for the workspace should be stored on the server or on the client. If it is on the client, the DAV:client-workspace property contains a string that indicates "where" on the client the root- collection of the workspace can be found. This string MAY take the form of a URL. 3.2.5.7. DAV:client-updates (readonly) The DAV:client-updates property contains an XML document that lists the immutable-revisions that were selected by the workspace when the most recent UPDATE on that workspace was performed, but that were not selected by the workspace when the UPDATE immediately preceding that UPDATE had been performed. This list can be used by the client to efficiently maintain a client snapshot of that workspace. The DAV:client-updates property exists only when the DAV:client-workspace property is set. 3.2.6. Activity Properties Configuration-management introduces the following additional properties for an activity: 3.2.6.1. DAV:immutable-revisions (readonly collection) The DAV:immutable-revisions collection of an activity contains references to all immutable-revisions (in any versioned-resource) whose DAV:activity property contains this activity. 3.2.6.2. DAV:branch-policy (writeable): The DAV:branch-policy contains an XML document that is used by branch-based configuration-management servers to guide the placement of immutable-revisions on branches. Some of the pre-defined values XML elements that can appear in this document are: DAV:branch-on- first-checkout, DAV:merge-on-checkin, and DAV:allow-branch-on- checkin. draft-clemm-webdav-versioning-00 [Page 12] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.2.6.3. DAV:workspace (writeable) The DAV:workspace property of an activity indicates the workspace which is currently working on that activity (and therefore has the right to extend the DAV:immutable-revisions collection of that activity). If any working-resource has its DAV:activity set to a given activity, the DAV:workspace of that activity can only be set to be the value of the DAV:workspace property of that working-resource. 3.2.7. Versioned-Collection Properties Configuration-management introduces the following additional properties for a versioned-collection: 3.2.7.1. DAV:configurations (readonly) The DAV:configurations of a versioned-collection is a versioned- resource, each of whose immutable-revisions is a configuration. New immutable-revisions of a DAV:configurations versioned-resource are created by a MAKE-CONFIGURATION request (not by CHECKOUT/CHECKIN). 3.2.8. Collection Properties Configuration-management introduces the following additional properties for a collection immutable-revision or a collection working-resource: 3.2.8.1. DAV:is-sub-configuration (writeable, immutable) In order to increase the efficiency of the creation of a new configuration for a versioned-collection, a new configuration can be composed from sub-configurations, i.e. configurations of versioned- collections that are members of that versioned-collection. The DAV:is-sub-configuration property tells the server whether to select (or create, if necessary) a sub-configuration for this versioned- collection. 3.3. Configuration-Management Headers Configuration-management introduces the following additional headers: 3.3.1. Workspace The Workspace header specifies the workspace whose version selection rules should be used when dereferencing a reference to a versioned- resource. If no Workspace header is specified, the workspace specified by the DAV:default-workspace property of the root collection is used. draft-clemm-webdav-versioning-00 [Page 13] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.4. Configuration-Management Effect on Existing Methods When invoked on a configuration-management server, the following methods will display additional behavior. 3.4.1. CONTROL A CONTROL request creates a new immutable-revision with an empty body, and creates a new working-resource which is a copy of the versionable-resource being put under version-control. The initial mutable-revision is a reference to this working-resource. 3.4.2. CHECKIN When a CHECKIN request is applied to a vportal that selects a working-resource, it creates a new immutable-revision that is a copy of the working-resource (including its properties), updates the DAV:immutable-successors collection of the predecessor to contain this new immutable-revision, removes the DAV:reservation property of the predecessor, and deletes the working-resource. The mutable- revision reference is changed to refer to this immutable-revision. A CHECKIN request fails if it is applied to a vportal that selects an immutable-revision, or if a new immutable-revision cannot be created as a descendent of the DAV:immutable-predecessor of the working- resource. 3.4.3. CHECKOUT When a CHECKOUT request is applied to a vportal that selects an immutable-revision, it creates a new working-resource that is a copy of the immutable-revision. The DAV:workspace property of the working-resource is set to be the current workspace, and the DAV:activity property of the working-resource is set to be the DAV:activity of the current workspace. The CHECKOUT request fails if the workspace DAV:activity is not set. 3.4.4. CHECKOUT-NEW A CHECKOUT-NEW request acts like a CHECKOUT request, except that it first creates a new activity, and sets the DAV:activity of the current workspace to be that activity. A server may reject a CHECKOUT-NEW request if the workspace DAV:activity property is already set. 3.5. Configuration-Management Methods draft-clemm-webdav-versioning-00 [Page 14] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.5.1. Activity and Workspace Creation Methods Activity and workspace resources can only be created as members of the DAV:activities and DAV:workspaces collections. [GMC: We could have a special MKACTIVITY and MKWORKSPACE methods, or we could just allow PUT to create them, with the body of the PUT being an XML document describing how the resource is to be initialized. I personally find the PUT method cleaner and more extensible because you don't need to add a new method to the protocol to handle a new resource type. There does seems to be some preference in the mailing group for separate object creation methods, and the use of headers to provide initial values. I'll defer these details for now.] 3.5.2. UNCHECKOUT When applied to a vportal that selects a working-resource, an UNCHECKOUT request deletes the working-resource and the DAV:reservation property of the predecessor of the working-resource. The mutable-revision is changed to refer to the predecessor of the working-resource. 3.5.3. GET-CONFLICTS When a GET-CONFLICTS request is invoked on a workspace, the body of the GET-CONFLICTS response contains an XML document that describes what versioned-resources are in conflict (commonly, a merge conflict), as well as information about how to resolve the conflict (such as the merge contributors and the merge base). Merge conflicts are determined by the server by comparing the revisions selected by the workspace DAV:merge-selection-rule against the revisions selected by the DAV:revision-selection-rule at the time of the last UPDATE request (or the current time, if DAV:dynamic-selection is set). 3.5.4. MAKE-CONFIGURATION When a MAKE-CONFIGURATION request is invoked on a versioned- collection, a new configuration is created that contains the revisions currently selected by the workspace for that versioned- collection and all its members. 3.5.5. Security Considerations TBD 3.5.6. Internationalization Considerations TBD draft-clemm-webdav-versioning-00 [Page 15] INTERNET-DRAFT Versioning Extensions to WebDAV January 26, 1999 3.5.7. IANA Considerations TBD 3.5.8. XML Element Definitions TBD 3.5.9. References TBD Author's Note: A separate document will contain the goals and requirements for these protocols. A separate document will contain use cases and examples of these protocols. Author's Address: Geoffrey M. Clemm Rational Software Lexington, MA geoffrey.clemm@rational.com draft-clemm-webdav-versioning-00 [Page 16]