INTERNET-DRAFT Geoffrey Clemm, Rational Software draft-ietf-webdav-versioning-02.txt Chris Kaler, Microsoft Expires December 25, 1999 June 25, 1999 Versioning Extensions to WebDAV Status of this Memo. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a set of methods, headers, and resource-types that define the WebDAV Versioning extensions to the HTTP/1.1 protocol. WebDAV Versioning will minimize the complexity of clients so as to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV Versioning includes: - Automatic versioning support for versioning-unaware clients, - Linear versioning , and - Support for parallel development and configuration management. Clemm, Kaler [Page 1]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 Table of Contents VERSIONING EXTENSIONS TO WEBDAV...........................1 STATUS OF THIS MEMO.......................................1 ABSTRACT..................................................1 TABLE OF CONTENTS.........................................2 1 INTRODUCTION...........................................4 1.1 Relationship to DAV.................................4 1.2 Terms...............................................5 1.3 Notational Conventions..............................5 2 CONCEPTS AND DEFINITIONS...............................5 3 WEBDAV VERSIONING SEMANTICS...........................10 3.1 Creating Versioned Resources.......................10 3.2 Modifying a Versioned Resource.....................11 3.3 Naming Revisions: Revision Ids and Labels..........11 3.4 Parallel Development and Activities................12 3.5 Revision Selection and Workspaces..................12 3.6 Configurations.....................................13 3.7 Versioned Collections..............................13 4 VERSIONING RESOURCE TYPES AND PROPERTIES..............14 4.1 Property Attributes................................14 4.1.1 Writeable/Readonly Properties....................14 4.1.2 Immutable/Mutable Properties.....................14 4.1.3 Property Resources...............................14 4.2 Resource Properties................................15 4.2.1 DAV:author (immutable) [Core]...................15 4.2.2 DAV:comment (immutable) [Core]..................15 4.3 Revision Properties................................15 4.3.1 DAV:revision-id (readonly) [Core]................15 4.3.2 DAV:predecessor (readonly, resource) [Core]......15 4.3.3 DAV:successors (readonly, mutable, collection)...15 4.3.4 DAV:single-checkout (mutable) [Core].............15 4.3.5 DAV:auto-version (mutable) [Core]................16 4.3.6 DAV:revision-labels (mutable) [Core].............16 4.3.7 DAV:checkin-date (readonly) [Core]...............16 4.3.8 DAV:working-resources (readonly, collection) ....16 4.3.9 DAV:history-uuid (readonly) [Core]...............16 4.3.10DAV:history (readonly, resource) [Core]..........16 4.3.11DAV:merge-predecessors (mutable, collection).....16 4.3.12DAV:merge-successors ............................17 4.4 Working Resource Properties........................17 4.4.1 DAV:workspace (readonly, resource) [Core]........17 4.4.2 DAV:predecessor (read-only, resource) [Core].....17 4.4.3 DAV:checkin-policy [Core]........................17 4.4.4 DAV:merge-predecessors (collection) [Merging]....18 Clemm, Kaler [Page 2]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 4.4.5 DAV:activity (readonly, resource) [Activity].....18 4.5 Workspace Properties...............................18 4.5.1 DAV:working-resources (readonly, collection) ....18 4.5.2 DAV:revision-selection-rule [Core]..............18 4.5.3 DAV:label [Core].................................19 4.5.4 DAV:activity [Activity]..........................19 4.6 Activity Properties................................19 4.6.1 DAV:revisions (readonly, collection) [Activity]..19 4.6.2 DAV:required-activities (collection) [Activity]..19 4.6.3 DAV:workspace (resource) [Activty]...............19 4.7 Configuration Properties...........................19 4.7.1 DAV:roots (immutable, collection) [Configuration]20 4.8 Versioned Collection Properties....................20 4.8.1 DAV:baselines (resource) [Baseline]..............20 4.9 History Resource Properties........................20 4.9.1 DAV:uuid (readonly) [Core].......................20 4.9.2 DAV:revisions (readonly, collection) [Core]......20 4.9.3 DAV:revision-labels (collection) [Core]..........20 5 VERSIONING METHODS....................................21 5.1 Existing Methods...................................21 5.1.1 GET..............................................21 5.1.2 BIND.............................................21 5.1.3 PUT..............................................21 5.1.4 PROPFIND.........................................22 5.1.5 PROPPATCH........................................22 5.1.6 DELETE...........................................22 5.1.7 COPY.............................................22 5.1.8 MOVE.............................................22 5.1.9 LOCK.............................................23 5.1.10 OPTIONS..........................................23 5.2 New Methods........................................23 5.2.1 MKRESOURCE.......................................23 5.2.2 REPORT...........................................24 5.3 New Versioning Methods.............................24 5.3.1 CHECKOUT.........................................24 5.3.2 CHECKIN..........................................25 5.3.3 UNCHECKOUT.......................................25 5.4 New Versioning Headers.............................26 5.4.1 Target-Selector..................................26 6 THE DAV VERSIONING XML ELEMENTS.......................26 6.1 Revision Selection Rule Elements...................26 6.1.1 DAV:rsr-configuration............................26 6.1.2 DAV:rsr-activity-latest..........................26 6.1.3 DAV:rsr-label....................................27 6.1.4 DAV:rsr-revision-id..............................27 6.1.5 DAV:rsr-latest...................................27 6.1.6 DAV:rsr-or.......................................27 6.1.7 DAV:rsr-merge....................................27 6.2 Report Elements....................................28 6.2.1 Conflicts Report.................................28 6.2.2 Compare Report...................................28 Clemm, Kaler [Page 3]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 7 INTERNATIONALIZATION CONSIDERATIONS...................29 8 SECURITY CONSIDERATIONS...............................29 9 SCALABILITY...........................................29 10 AUTHENTICATION......................................30 11 IANA CONSIDERATIONS..................................30 12 INTELLECTUAL PROPERTY................................30 13 ACKNOWLEDGEMENTS.....................................30 14 INDEX................................................30 15 REFERENCES...........................................31 16 AUTHORS ADDRESSES....................................31 17 OPEN ISSUES..........................................31 1 INTRODUCTION This document defines DAV Versioning extensions, an application of HTTP/1.1 for handling resource versioning in a DAV environment. [VerGoal] describes the motivation and requirements for DAV Versioning. DAV Versioning will minimize the complexity of clients so as to facilitate widespread deployment of applications capable of utilizing the DAV services. As well, DAV Versioning supports a rich level of versioning options for versioning-aware clients. DAV Versioning consists of: - Automatic versioning support for versioning-unaware clients, - Linear versioning , and - Support for parallel development and configuration management. 1.1 Relationship to DAV To maximize interoperability and use of existing protocol functionality, versioning support is designed as extensions to the WebDAV [RFC2518] and advanced-collection protocols [AdvCol]. In particular, DAV Versioning relies on the resource and property model defined by [RFC2518] and the binding model defined by [AdvCol]. The versioning protocol is designed so that WebDAV locking (class 2) support is optional. The effect of a lock on versioning methods and content-types will be defined to provide interoperability of servers that provide locking support. Clemm, Kaler [Page 4]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 Versioning support is defined in the form of Core versioning support, supplemented by a set of orthogonal extensions to the Core: Activity, Merging, Configuration, Versioned Collection, and Baseline versioning support. Core support provides versioning of largely independent resources. It allows authors to concurrently create and access distinct revisions of a resource. Activity support extends Core support with logical change tracking and management through activities. Merging support extends Core support with conflict detection and resolution through merging. Configuration support extends Core support with the creation of sets of consistent revisions. Versioned Collection support extends Core support with the ability to version the URL namespace. Baseline support extends Configuration and Versioned Collection support with the ability to create and compare configurations of all revisions in a URL subtree. Throughout this specification the [xyz] notation is used to indicate that a property is introduced at the "xyz" level of versioning support. The levels of versioning support provided by a server can be discovered via an OPTIONS request. 1.2 Terms This draft uses the terms defined in [RFC2068] and [RFC2518]. 1.3 Notational Conventions The augmented BNF used by this document to describe protocol elements is exactly the same as the one described in Section 2.1 of [RFC2068]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2068], those rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2 CONCEPTS AND DEFINITIONS The section presents the versioning concepts and terms/definitions used in this protocol. Versionable Resource A versionable resource is a resource that can be placed under version control. A null resource is a versionable resource. Versioned Resource A versioned resource is a resource that is under version control. To update a resource under version control, it must be checked out and then subsequently checked in. The checked in states of a versioned resource are saved by the server to capture the history of that resource. Revision Clemm, Kaler [Page 5]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 A revision contains a particular state of a versioned resource. An immutable revision is a revision whose body and immutable properties cannot be modified. A mutable revision is a revision whose state can be overwritten by a subsequent check in request. Revision Name A revision name is a name that can be used to identify a single revision of a versioned resource. There are two types of revision names: revision identifiers and revision labels. Revision Identifier A revision identifier (or revision ID) is a revision name that is assigned by the server when the revision is created and cannot be changed to refer to a different revision. Revision Label A revision label is a revision name that is assigned by a client and may later be changed to refer to a different revision. The same label may be assigned to many different versioned resources. Initial Revision An initial revision is the first revision of a versioned resource. Predecessor, Successor A predecessor of a revision is the previous revision that was checked out to create the revision. A successor of a revision is a revision whose predecessor is that revision. Each revision has a single predecessor (except for the initial revision which has no predecessor) and zero or more successors. Merge Predecessor, Merge Successor A merge predecessor of a revision is a revision that has been merged into this revision. A merge successor of a revision is a revision into which that revision has been merged. A revision can have zero or more merge predecessors and zero or more merge successors. Line Of Descent A line of descent to a specified revision is a sequence of revisions connected by successor relationships from the initial revision to that revision. The following diagram illustrates several of the previous definitions. Versioned --> Foo.htm Resource +----+ \ Label --> "initial" | V1 | | | \ +----+ | | \ | | | \ v | | \ +----+ | Line | -> "beta1" | V2 | | of | Clemm, Kaler [Page 6]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 +----+ | Descent | / | | | v v | | +----+ +----+ | | Revision Id --> | V3 | | V4 | | | History +----+ +----+ | | ^ | | | | | v v | | Predecessor | +----+ +----+ v | | V5 | | V6 | | +----+ +----+ | \ | | Successor | | v v | | Merge Successor | +----+ v | v | V7 | | +----+ / Immutable/Mutable Property An immutable property is a property of an immutable revision that cannot be changed. A mutable property is a property of an immutable revision that can be changed. Only properties of revisions can be immutable or mutable. Working Resource A working resource is an editable resource created by checking out a revision of a versioned resource. Checkout/Checkin Model The checkout/checkin model is the process by which updates are made to a versioned resource. A versioned resource is checked out to create an editable working resource. The working resource is updated or augmented as desired, and then checked in to make it part of the revision history of the versioned resource. The following diagram illustrates the checkout/checkin process. ===CHECKOUT==> ===CHECKIN==> Foo.htm | Foo.htm | Foo.htm | | +----+ | +----+ | +----+ | V1 | | | V1 | | | V1 | +----+ | +----+ | +----+ | | | | | v | v | v +----+ | +----+ | +----+ | V2 | | | V2 | | | V2 | +----+ | +----+ | +----+ | | | | | v | v | +----+ | +----+ | | WR | | | V3 | | +----+ | +----+ Clemm, Kaler [Page 7]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 Activity An activity is a resource that selects a set of revisions that correspond to some unit of work or conceptual change. An activity can contain revisions of multiple versioned resources, and multiple revisions of the same versioned resource. If an activity contains multiple revisions of the same versioned resource, all of those revisions must be on a single line of descent to one of those revisions, and this revision is called the latest revision selected by that activity for that versioned resource. The following diagram illustrates activities. Revision V3 is the latest revision of Foo.htm selected by activity 2, and revision V7 is the latest revision of Bar.htm selected by activity 2. Foo.htm | Bar.htm | +----+ | +----+ | V1 | | | V5 | +----+ | +----+ | Activity | | Activity v 1 | v 2 +----+ | +----+ | V2 | | | V6 | +----+ | +----+ | Activity | | Activity v 2 | v 2 +----+ | +----+ | V3 | | | V7 | +----+ | +----+ | | Activity | v 3 | +----+ | | V8 | | +----+ Workspace A workspace is a resource that is used to identify working resources. A workspace can also contain a revision selection rule that specifies what revision of an arbitrary versioned resource should be accessed when the resource is referenced in the context of that workspace. A revision selection rule provides revision selection based on criteria such as revision name, latest in an activity, and membership in a configuration. A workspace that does not contain a revision selection rule (and therefore can only be used to identify working resources) is called a basic workspace. A workspace that contains a revision selection rule (and therefore can be used to specify revision selection) is called an extended workspace. The following diagram illustrates an extended workspace. Foo.htm Bar.htm Bing.htm Clemm, Kaler [Page 8]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 +----+ +----+ | V1 | | V1 | +----+ +----+ | | | | +-----------------|------------|------------------+ | v v | | +----+ +----+ +----+ | | | V1 | | V2 | | WR | Workspace X | | +----+ +----+ +----+ | | | | +-----------------|-------------------------------+ | v +----+ | V3 | +----+ Target The target of a versioned resource is the working resource or revision of that versioned resource that is selected by the current workspace. Conflict Report A conflict report lists all versioned resources for which the revision selection rule of a workspace selects multiple revisions on different lines of descent. A conflict is resolved by checking out one of the selected revisions, modifying the resulting working resource so that it represents the logical merge of all selected revisions, and then indicating these merges by adding these revisions as merge predecessors of the working resource. Checking in this working resource creates a new revision that resolves the conflict. Default Workspace A server MUST provide a default workspace that is used to perform version selection for versioning-unaware clients. The revision selection rule of the default workspace MAY be a modifiable by a client. Default Target The default target of a versioned resource is the target selected by the default workspace. Configuration A configuration selects a particular revision from each of a set of versioned resources. Unlike a workspace, which can select both working resources and revisions, a configuration can only select revisions. Also, while the revision selected by a workspace for a versioned resource can change as a result of a change to the versioned resource (such as adding a label), the revision selected by a configuration can change only by explicitly modifying the Clemm, Kaler [Page 9]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 configuration itself. Unlike an activity, a configuration can select at most one revisions of a given versioned resource. Unlike both a workspace and an activity, a configuration can be versioned. The following diagram illustrates a configuration. Foo.htm Bar.htm Bing.htm +----+ | V1 | +----+ | | +-----------------|-------------------------------+ | | | | +----+ +----+ +----+ Configuration | | | V1 | | V2 | | V1 | V1.1 | | +----+ +----+ +----+ | | | | | +-----------------|------------|------------------| | | v v +----+ +----+ | V3 | | V2 | +----+ +----+ Versioned Collection A versioned collection is a type of versioned resource that results from placing a collection under version control. The members of a versioned collection revision are all versioned resources. Baselined Collection A baselined collection is a special type of versioned collection that is associated with a versioned configuration. A revision of the associated versioned configuration is called a baseline of the baselined collection. A baseline contains a revision of the versioned collection and a revision of every member of every versioned collection revision in that baseline. History Resource A history resource for a versioned resource contains all revisions of that versioned resource. 3 WEBDAV VERSIONING SEMANTICS 3.1 Creating Versioned Resources A resource may or may not be versioned. When a resource is created by a PUT or MKRESOURCE request, it is commonly created as an unversioned resource. Some unversioned resources can be put under version control; these are called versionable resources. After a Clemm, Kaler [Page 10]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 resource is put under version control, it becomes a versioned resource, and an initial revision is created that is a copy of the versionable resource. This initial revision becomes the target of the versioned resource. 3.2 Modifying a Versioned Resource A versioned resource must be checked out before it can be modified. Checking out a versioned resource produces a new resource, called a working resource. A working resource is a modifiable copy of the revision, and is identical to an unversioned resource in all respects other than that it is associated with a particular revision of a particular versioned resource. It may be edited by setting its properties or contents any number of times. When the author is satisfied that the working resource is in a state that should be retained in the versioned resource history, the author checks in the working resource to create a new revision of the versioned resource. The revision that was checked out is the predecessor of the new revision. The use of checkout/checkin and working resources to update a versioned resource addresses the lost update problem by ensuring that each author is updating his or her own working resource rather than a shared resource, and by ensuring that the predecessor of the updated resource is reliably tracked. Authors can use checkout/checkin to register intent to modify a versioned resource similar to the way lock /unlock are used in WebDAV level 2, but the underlying semantics are very different. With lock/unlock, work is serialized and avoiding lost updates depends on clients using the lock/unlock protocol. With checkout/checkin, work can be performed in parallel, and the server prevents lost updates by retaining all saved states (revisions) of the resource. A revision may be created as either immutable or mutable. An immutable revision cannot be changed and provides a stable environment for history management, change recovery, merging, and configuration management. A mutable revision is more suitable for situations where versioning is treated more informally, and it is not necessary or desirable to maintain strict version histories, or to guarantee the possibility of backtracking to a previous saved state. If the revision is mutable, the author may request that a subsequent checkin should overwrite the revision that was checked out, instead of creating a new revision. In this case, the previous state captured by that revision is lost. Servers may choose to support only immutable revisions, only mutable revisions, or both. 3.3 Naming Revisions: Revision Ids and Labels Revision names are used to distinguish a revision of a versioned resource from other revisions of that versioned resource. A revision name is either a revision id or any number of revision labels. A revision of a versioned resource is given a server assigned revision id when it is created. This revision id acts as a Clemm, Kaler [Page 11]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 persistent, immutable identifier distinguishing this revision from all others of the same versioned resource. The revision id cannot be changed, assigned to another revision, or reused. A user may assign revision labels to a revision in order to provide a more meaningful name for the revision. A given revision label can be assigned to at most one revision of a given versioned resource, but may be reassigned to any revision of the versioned resource at any time. Revisions of different versioned resources may have the same label. 3.4 Parallel Development and Activities In a locking model, when a resource is locked for modifications by one author, all other authors are supposed to respect that lock and not work on a copy of that resource until the lock has been released. To avoid the work serialization inherent in the locking model, a versioning model allows multiple authors in different workspaces to check out the same revision at the same time, work on their respective working resources in parallel, check in their respective working resources as soon as their changes are complete, and then merge the resulting revisions at some later time. Although a simple versioning model works well for isolated changes to independent resources, the required merge process becomes unmanageable when sequences of inter-related changes are performed on sets of related resource. To address this merge problem, resources can be checked out in the context of an activity. An activity captures the set of revisions that form a set of related changes an author is making to one or more versioned resources. Each activity represents a thread of development, where any thread can be isolated from other threads to provide a stable environment for parallel work. In case parallel work on isolated activities results in branches in the underlying versioned resource histories, the activities can be unified through a merge operation. 3.5 Revision Selection and Workspaces Resources, working resources, and revisions of versioned resources are all accessed using a URL. When a client accesses a versioned resource, it is necessary to provide additional information to specify which working resource or which revision of the versioned resource should be accessed. Specifying the resource URL and a revision name can access a specific revision of the versioned resource. However, this requires the user to add and remember labels for each revision; it does not provide a way of accessing a consistent set of revisions captured by an activity or contained in a configuration; it does not enable non-versioning aware clients to access revisions; and it does not provide a client with access to a working resource of a versioned resource. To address the restrictions inherent in revision-name based revision selection, the revision selected when a specific revision name is not specified is resolved through a workspace. A workspace Clemm, Kaler [Page 12]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 is a resource whose primary purpose is to identify working resources. If the workspace contains no working resource for a given versioned resource, it can also be used to select an appropriate revision of the versioned resource. This allows versioned resources and unversioned resources to be accessed consistently by both versioning-aware and versioning-unaware clients. In order to specify revision selection, a workspace contains a revision selection rule. A revision selection rule can specify revision names, activities, configurations, or use operators that combine several of these rule elements. A revision name selects a revision with that name. An activity selects the latest revision that was created in that activity. Configurations select the revision contained in the configuration. The "or" operator contains a sequence of rule elements, and applies them in order until the first match is found. If there is no matching revision, then a resource-not-found status is returned. If a request is made and no workspace is specified, a server determined default workspace is used. This is the workspace used by all versioning-unaware clients. A server MAY allow modifications to the revision selection rule of the default workspace. 3.6 Configurations A workspace selects a volatile set of revisions. Changes to selected activities or changes to labels may result in the selection of different revisions. A configuration is a resource that selects a set of immutable revisions. A workspace whose version selection rule contains a configuration will always select the same revisions as long as the configuration is not modified and no checkouts are performed in that workspace. Configurations are convenient for defining a persistent set of revisions that relate to each other in some specific way at some point in time. This can be useful for a variety of purposes such as publishing consistent versions of resources to deploy an application, or for recovering a specific state for legal or maintenance reasons. 3.7 Versioned Collections A collection contains a set of named bindings to other resources that are the members of that collection. For a versioned collection, the bindings are to versioned resources, not to particular revisions. To modify the state of a versioned collection (i.e. add or remove a binding), the versioned collection must be checked out, just like any other versioned resource. Requests that modify the state of a collection member, such as checking it out or checking in a new revision, have no effect on the state of the collection. Conversely, requests that modify the state of a versioned collection, such as deleting or adding a binding to resource, have no effect on the state of that resource. In Clemm, Kaler [Page 13]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 particular, the resource will remain bound in any other revisions of the collection of which it was a member. If a URL identifies a sequence of nested versioned collections, revision selection is performed for each versioned collection in the sequence, to select the versioned collection revision that will be used to map the next segment of the URL to the appropriate versioned resource. 4 VERSIONING RESOURCE TYPES AND PROPERTIES This section defines the new resource types and properties introduced by WebDAV versioning. 4.1 Property Attributes There are several important attributes of properties that will be defined for every property introduced by this document. 4.1.1 Writeable/Readonly Properties A writeable property can be modified by a client, while a readonly property can only be modified by the server. All properties defined in this document are writeable unless explicitly marked as "readonly". 4.1.2 Immutable/Mutable Properties An immutable resource is a resource whose value cannot change. An immutable property is a property whose value cannot change when it appears on an immutable resource. A mutable property is a property whose value can change, even when it appears on an immutable resource. All properties defined in this document are immutable unless explicitly marked as "mutable". 4.1.3 Property Resources There are various properties whose contents can be represented as an HTTP resource. Doing so allows a client to use the full set of HTTP methods to manipulate the contents of that property, rather than being limited to the functionality provided by PROPFIND and PROPPATCH. This is particularly valuable for a property value that is naturally represented as a collection resource. By default, PROPFIND returns an XML document as the value of a property resource; however, when a DAV:property-resource-URL element is specified in the PROPFIND request body, PROPFIND will return the URL of the property resource. Servers MAY support DAV:property- resource-URL for a property, but MUST support the default XML value. Clemm, Kaler [Page 14]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 All properties that are property resources are explicitly marked as "resource". If the property resource is a collection, the property is marked as "collection". 4.2 Resource Properties WebDAV versioning introduces the following additional properties for a resource: 4.2.1 DAV:author (immutable) [Core] This property is used to track the author of a resource. 4.2.2 DAV:comment (immutable) [Core] This property is used to track a brief comment about a resource. 4.3 Revision Properties WebDAV versioning introduces the following additional properties for a revision: 4.3.1 DAV:revision-id (readonly) [Core] The DAV:revision-id is an identifier assigned to a revision by the server. Whenever a revision is created or modified by a CHECKIN, it must be assigned a new DAV:revision-id. A revision cannot be given a DAV:revision-id that has been given to any other revision of that versioned resource, even a revision that has been deleted. 4.3.2 DAV:predecessor (readonly, resource) [Core] The DAV:predecessor of a revision is the revision that was checked out to produce a working resource that was checked in to produce this revision. The XML document for DAV:predecessor contains the revision-id of the DAV:predecessor. 4.3.3 DAV:successors (readonly, mutable, collection) [Core] The DAV:successors collection of a revision contains the revisions whose DAV:predecessor is that revision. The XML document for DAV:successors contains a list of the revision-id's of the DAV:successors. 4.3.4 DAV:single-checkout (mutable) [Core] When the DAV:single-checkout property of a revision is set, only one working resource can be checked out from that revision at any time. Clemm, Kaler [Page 15]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 4.3.5 DAV:auto-version (mutable) [Core] When the DAV:auto-version property of a revision is set, a PUT request (or any request that modifies an immutable aspect of the revision) to this revision is automatically preceded by a CHECKOUT into the default workspace and followed by a CHECKIN. This allows a versioning-unaware client to modify a version-controlled resource. The DAV:auto-version value can take the same values as the DAV:checkin-policy of a working resource, and the DAV:checkin- policy of the automatically created working resource is set to be the DAV:auto-version policy of the revision. 4.3.6 DAV:revision-labels (mutable) [Core] This property is used to identify labels that are associated with a specific revision. 4.3.7 DAV:checkin-date (readonly) [Core] This property contains the date when the revision was checked in. This property is automatically assigned and is formatted using ISO8061. 4.3.8 DAV:working-resources (readonly, collection) [Core] This property is a collection of the workspaces that contain working resources whose DAV:predecessor is this revision. The XML document for DAV:working-resources contains a description of these working resources. 4.3.9 DAV:history-uuid (readonly) [Core] The DAV:history-uuid of a revision is the DAV:uuid of the history resource whose DAV:revisions collection contains this revision. 4.3.10 DAV:history (readonly, resource) [Core] The DAV:history of a revision is the history resource whose DAV:revisions collection contains this revision. The XML document for DAV:history contains a description of revisions that form the line-of-descent to this revision. 4.3.11 DAV:merge-predecessors (mutable, collection) [Merging] The DAV:merge-predecessors collection of a revision contains the revisions whose contents were explicitly merged by the client into that revision. The client is free to add or delete members to this collection to more accurately reflect the contents of that revision. The XML document for DAV:merge-predecessors contains the revision id's of the DAV:merge-predecessors. Clemm, Kaler [Page 16]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 4.3.12 DAV:merge-successors (mutable, collection, readonly) [Merging] The DAV:merge-successors collection of a revision contains a binding to each revision whose DAV:merge-predecessors collection contains a binding to that revision. The XML document for DAV:merge-successors contains the revision id's of the DAV:merge- successors. 4.4 Working Resource Properties WebDAV versioning introduces the following additional properties for a working resource: 4.4.1 DAV:workspace (readonly, resource) [Core] The DAV:workspace of a working resource is the workspace that contains this working resource. The XML document for DAV:workspace contains the URL of this workspace. 4.4.2 DAV:predecessor (read-only, resource) [Core] This property contains the revision that was checked out to create this working resource. The XML document for DAV:predecessor contains the revision id of DAV:predecessor. 4.4.3 DAV:checkin-policy [Core] The DAV:checkin-policy property of a working resource indicates how this working resource should be checked in. The following are defined values for DAV:checkin-policy. The default value is DAV:immutable. DAV:identical-abort - the CHECKIN should fail if the working resource is identical to its DAV:predecessor. DAV:identical-uncheckout - an UNCHECKOUT should be applied instead of CHECKIN if the working resource is identical to its DAV:predecessor. DAV:overwrite - the working resource should be copied into its DAV:predecessor instead of creating a new revision. DAV:mutable - a new revision is created that can be overwritten by a subsequent DAV:overwrite CHECKIN. DAV:immutable - a new revision is created that cannot be overwritten by a subsequent DAV:overwrite CHECKIN. DAV:keep-checked-out - create a new revision but does not delete the working resource. The DAV:predecessor of the working resource is changed to be the new revision. DAV:baseline - instead of creating a new revision of the versioned collection, create a new baseline for it (the CHECKIN fails unless Clemm, Kaler [Page 17]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 it is applied to a versioned collection with a DAV:baselines property). 4.4.4 DAV:merge-predecessors (collection) [Merging] The DAV:merge-predecessors collection of a working resource contains the revisions whose contents were explicitly merged by the client into that working resource. The client adds and deletes members of this collection to reflect the set of revisions that were merged by the client into the working resource. The name of a DAV:merge-predecessors binding is the DAV:revision-id of that revision. The XML document for DAV:merge-predecessors contains the revision id's of the DAV:merge-predecessors. 4.4.5 DAV:activity (readonly, resource) [Activity] The DAV:activity property of a working resource is the DAV:activity of the workspace when the working resource was checked out. The XML document for DAV:activity is the URL for the activity. 4.5 Workspace Properties WebDAV versioning introduces the following additional properties for a workspace: 4.5.1 DAV:working-resources (readonly, collection) [Core] The DAV:working-resources collection contains the versioned resources that are checked out into this workspace. The XML document for DAV:working-resources contains a description of these working resources. 4.5.2 DAV:revision-selection-rule [Core] The DAV:revision-selection-rule of a workspace can contain an XML document that describes how revision selection will be performed in that workspace. The working resources checked out into a workspace take priority over revisions selected by the revision selection rule, thus target of a versioned resource in a workspace is the working resource in that workspace for that versioned resource, else the revision selected by the workspace revision selection rule. To ensure that working resources continue to be visible in a workspace after they are checked in, the DAV:label or DAV:activity of a workspace is usually the first element of the DAV:revision- selection-rule. If the DAV:revision-selection-rule is not set or is empty, the revision selection rule will select no revision for any versioned resource. Standard revision selection rule elements are defined in this document, but additional revision selection rule elements may be supported by a WebDAV server. Clemm, Kaler [Page 18]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 4.5.3 DAV:label [Core] The DAV:label property of a workspace can contain a revision label. When a working resource in a workspace is checked in, it will be given this label. 4.5.4 DAV:activity [Activity] The DAV:activity property of a workspace is the activity that is currently being performed in that workspace. A new working resource in a workspace will have its DAV:activity property set to this activity. The XML document for DAV:activity contains the URL of DAV:activity. 4.6 Activity Properties WebDAV versioning introduces the following additional properties for an activity: 4.6.1 DAV:revisions (readonly, collection) [Activity] The DAV:revisions collection of an activity contains all revisions whose DAV:activity property contains this activity. The XML document for DAV:revisions contains the URL's of these revisions. 4.6.2 DAV:required-activities (collection) [Activity] The DAV:required-activities collection of an activity contains the other activities that form a part of the logical change being captured by the activity. The DAV:needed-activities of an activity contribute to the revision selection behavior of that activity when it is used in a revision selection rule. The purpose of this property is to identify other activities that are a prerequisite to this activity. The XML document for DAV:required-activities contains the URL's of these activities. 4.6.3 DAV:workspace (resource) [Activty] The DAV:workspace property of an activity contains the workspace that currently has that activity as its DAV:current activity. This implies that at most one workspace can be working in a given activity at a time. If any working resource of a workspace is checked out into a given activity, the DAV:workspace of that activity can only be that workspace. The XML document for DAV:workspace contains the URL of the workspace. 4.7 Configuration Properties WebDAV versioning introduces the following properties for a configuration: Clemm, Kaler [Page 19]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 4.7.1 DAV:roots (immutable, collection) [Configuration] The DAV:roots collection of a configuration contains the versioned resources that are not named by versioned collection revisions in that configuration. The XML document for DAV:roots contains the URL's of these versioned resources. 4.8 Versioned Collection Properties WebDAV versioning introduces the following additional properties for a versioned collection: 4.8.1 DAV:baselines (resource) [Baseline] The DAV:baselines of a versioned collection is a versioned configuration whose DAV:roots contains only that versioned collection. A revision of the DAV:baselines of a versioned collection effectively provides a "deep-revision" of that versioned collection. The XML document for DAV:baselines contains the URL of the versioned configuration. 4.9 History Resource Properties WebDAV versioning introduces the following additional properties for a history resource: 4.9.1 DAV:uuid (readonly) [Core] The DAV:uuid is an identifier assigned to a history resource by the server. A history resource cannot be given a DAV:uuid that has been given to any other history resource, even a history resource that has been deleted. 4.9.2 DAV:revisions (readonly, collection) [Core] The DAV:revisions collection of a history resource contains all revisions of that history resource, where the name of a revision in the DAV:revisions collection is its DAV:revision-id. If a revision id contains a URL reserved character, that character is escaped in the DAV:revisions name. The XML document for DAV:revisions contains the URL's of the revisions. 4.9.3 DAV:revision-labels (collection) [Core] The DAV:revision-labels collection of a history resource contains a binding for each label assigned to any revision of that history resource, where the binding name is that label (reserved URL characters are escaped) and the binding is to the revision selected by that label. The client can label and unlabel revisions by adding and deleting members of the DAV:revision-labels collection. Clemm, Kaler [Page 20]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 The XML document for DAV:revision-labels contains the URL's of the members of the DAV:revision-labels collection. 5 VERSIONING METHODS 5.1 Existing Methods This section describes the extensions to the existing WebDAV methods. Under versioning, the methods inherit all of the WebDAV functionality with the following extensions. 5.1.1 GET When GET is applied to a versioned resource, it returns the body of the target of that versioned resource. The result of GET on a workspace, activity, or history resource is undefined. 5.1.2 BIND When BIND creates a binding in a working resource for a versioned collection, it MUST fail if the request URL of the BIND is not a versioned resource. 5.1.3 PUT When PUT is applied to a versioned resource whose target is a working resource, the PUT is applied to that working resource. When PUT is applied to a versioned resource whose target is a revision, the PUT MUST fail except in the following two cases. If the revision has a DAV:auto-version property and no Target-Selector header has been specified, the revision is checked out into the default workspace, the PUT is applied to the resulting working resource, and the working resource is checked in. If the revision is a revision of a baselined collection and the value of DAV:checkin-policy is DAV:baseline, a new revision of the DAV:baselines configuration is created by the CHECKIN. When PUT is applied directly to a revision (i.e. not indirectly via a versioned resource), it MUST fail. When PUT is applied to a null resource that is an internal member of a versioned collection whose target is a working resource, a new versioned resource is created at the request URL of the PUT. When the target is a versioned collection revision, the PUT request fails unless the revision has a DAV:auto-version property and no Target-Selector header has been specified. If DAV:auto-version is set, the versioned collection revision is checked out into the default workspace, a new versioned resource is created as a member of the working collection, and the working collection is checked in. Clemm, Kaler [Page 21]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 When a PUT is applied to a workspace, activity or history resource, it fails. 5.1.4 PROPFIND If a DAV:property-resource-URL is specified under a DAV:prop element in a PROPFIND request body, the property resource URL of that property will be returned in the PROPFIND response instead of the default XML document for that property resource. If a DAV:property-resource-URL is specified directly under the DAV:propfind element, the property resource URL will be returned for all of the property resources in the PROPFIND response. 5.1.5 PROPPATCH When PROPPATCH is applied to a versioned resource, its behavior is similar to that of PUT. In particular, when PROPPATCH is applied to an immutable property of a revision, it MUST fail unless the revision has a DAV:auto-version property. 5.1.6 DELETE When DELETE is applied to a versioned resource whose target is a revision, the versioned resource is deleted from the collection that contains it, but the revision is unaffected. When DELETE is applied to a workspace, the workspace and all working resources of that workspace are deleted. When DELETE is applied to a member of the DAV:revisions collection of a history resource, it fails unless the All-Bindings header is specified. When DELETE is applied to a history resource, the history resource and all members of the DAV:revisions collection of that history resource are deleted. 5.1.7 COPY When COPY is applied to a versioned resource, it is applied to the target of the versioned resource. That is, only the selected revision is copied, not the full version history. When a COPY request is applied to a workspace, activity, or history resource, it fails. 5.1.8 MOVE When MOVE is applied to a versioned resource, the MOVE request MUST fail unless a binding to that versioned resource can be created at the Destination of the MOVE. When a MOVE request is applied to an activity or a history resource, it fails. Clemm, Kaler [Page 22]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 Any request to MOVE a specific revision, and not the versioned resource, MUST fail. 5.1.9 LOCK A write lock on a versioned resource is applied to the target of that versioned resource. A write lock on a revision prevents unauthorized modifications to the properties of that revision. A write lock on a working resource prevents unauthorized changes to the body or properties of that working resource. A write lock on an activity prevents unauthorized modifications to the properties of that activity. A write lock on a history resource places a write lock on all revisions of that history resource. A write lock on a workspace prevents unauthorized modifications to the properties of that workspace. 5.1.10 OPTIONS The OPTIONS method allows the client to discover the level of versioning support provided by a server. The following defines the BNF for the Versioning header: Versioning := "Versioning" ":" Ver-type-list Ver-type-list := Ver-type | (Ver-type-list "," Ver-type) Ver-type := "Core" | "Activity" | "Merging" | "Configuration" | "Versioned-Collection" | "Baseline" 5.2 New Methods WebDAV versioning introduces two new methods, MKRESOURCE and REPORT, that are not specific to versioning but are needed to support the versioning extensions. 5.2.1 MKRESOURCE The MKRESOURCE method requests the simultaneous creation of a resource, identified by the Request URI, and initialization of its properties. Creation of the resource and initialization of its properties MUST both occur, or neither occurs. The request message body of the MKRESOURCE method is the same as for the PROPPATCH method, i.e. it MUST contain the DAV:propertyupdate XML element, defined in section 12.13 of [RFC2518]. The property update directives in the request message body provide the initial values of the properties of the new resource. The type of the created Clemm, Kaler [Page 23]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 resource is specified by the DAV:resourcetype property, if present. If the DAV:resourcetype property is not specified, the created resource is an ordinary (i.e. untyped) resource. Like PROPPATCH, instruction processing MUST occur in the order instructions are received (i.e. from top to bottom). Instructions MUST all be executed, or none executed. If MKRESOURCE is applied to an existing resource, that resource is deleted prior to MKRESOURCE processing. The behavior of MKRESOURCE on an existing resource can be explicitly controlled through use of the Overwrite header. MKRESOURCE can be used to create a new activity in a repository DAV:activities collection. When MKRESOURCE is used to create a repository from an existing versionable collection, every member of that versionable collection is also placed under version control as a history resource in that repository. Status Codes: 201 (Created) - The new resource has successfully been created. 207 (Multi-Status) - If any error was encountered in the creation of the resource, this response is generated. Status codes defined for use with PROPPATCH (defined in section 8.2.1 of [RFC2518]) SHOULD be used to represent error cases in setting the value of properties. TBD - Explain effect on existing resource types TBD - Give request/response example 5.2.2 REPORT The REPORT request is an extensible mechanism for obtaining information about a resource. This differs from OPTIONS because the information is not static. That is, it is typically a report that requires server processing in order to generate. The REPORT method takes an XML body document that specifies the type of report. If no report is requested, the method returns a list of available reports. TBD - More details on error codes TBD - Give request/response example 5.3 New Versioning Methods WebDAV versioning introduces three new methods to support the checkout/checkin versioning model. 5.3.1 CHECKOUT A CHECKOUT request can only be applied to a versioned resource. When a CHECKOUT request is applied to a versioned resource whose target is a revision, a new working resource is created that is a copy of the revision, and the DAV:predecessor of the working resource is set to be that revision. If the DAV:predecessor has a Clemm, Kaler [Page 24]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 DAV:single-checkout property and is already checked out into a workspace, the CHECKOUT request fails. The DAV:workspace of the working resource is set to be the workspace specified in the Target-Selector header. If the Target-Selector is not a workspace or if there is no Target-Selector header, the DAV:workspace for that working resource is allocated by the server. The body of the CHECKOUT request can be used to initialize the DAV:checkin-policy of the working resource. When a CHECKOUT request is applied to a versioned resource whose target is a working resource, the CHECKOUT request MUST fail. On CHECKOUT, the DAV:activity of the new working resource is set to be the DAV:activity of the current workspace. If DAV:activity is not set, a server with activity support automatically assigns an activity to the new working resource. The CHECKOUT request fails if neither DAV:activity nor DAV:label is set. TBD - Failures must include "policy not supported" TBD - More details on error codes TBD - Give request/response example 5.3.2 CHECKIN When a CHECKIN request is applied to a versioned resource whose target is a working resource, a copy of the working resource is made a new revision of that versioned resource and the working resource is deleted. The new revision is added to the DAV:successors collection of the DAV:predecessor of the new revision, and the workspace of the working resource is deleted from the DAV:working-resources collection of the DAV:predecessor. The body of a CHECKIN request can be used to override the current DAV:checkin-policy values of the working resource. The effect of DAV:checkin-policy on a CHECKIN request is described in the definition of the DAV:checkin-policy property. When the CHECKIN method is applied to a resource that is versionable, but not currently versioned, the resource is put under version control. If a versionable collection is put under version control, all members of that collection are put under version control as well. TBD - More details on error codes TBD - Explain effect on existing resource types TBD - Give request/response example 5.3.3 UNCHECKOUT When an UNCHECKOUT request is applied to a versioned resource whose target is a working resource, the DAV:workspace of that working resource is deleted from the DAV:working-resources collection of the DAV:revision of the working resource, and the working resource Clemm, Kaler [Page 25]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 is deleted. This effectively cancels the CHECKOUT request that produced the working resource. TBD - More details on error codes TBD - Explain effect on existing resource types TBD - Give request/response example 5.4 New Versioning Headers 5.4.1 Target-Selector The Target-Selector header contains a workspace URL or a revision name. The Target-Selector header is used to specify which working resource or revision of a versioned resource should be its target. If a Target-Selector header is omitted in a request on a versioned resource, the default workspace is implicitly used as the Target- Selector. 6 THE DAV VERSIONING XML ELEMENTS 6.1 Revision Selection Rule Elements A revision selection rule document is the value of the DAV:revision-selection-rule property of a workspace. Semantically, a revision selection rule (or RSR) element can be applied to an arbitrary versioned resource, and will either select a particular revision of that versioned resource or select no revision of that versioned resource. If it selects a particular revision, it may also detect a conflict (e.g. when there were multiple candidates for selection). A document describing the conflicts can be obtained through a conflict REPORT request. 6.1.1 DAV:rsr-configuration A DAV:rsr-configuration element contains the URL of a configuration. If the configuration contains a revision of the versioned resource, that revision is selected by the DAV:rsr- configuration element; otherwise, no revision is selected. A DAV:rsr-configuration element never generates a conflict. 6.1.2 DAV:rsr-activity-latest A DAV:rsr-activity-latest element contains the URL of an activity. If the DAV:revisions collection of the activity contains one or more revisions of the versioned resource, then the latest revision in that activity is selected. The semantics of activities ensures that there always is a unique latest revision for an activity. If the activity contains no revisions of a versioned resource, the Clemm, Kaler [Page 26]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 DAV:rsr-activity-latest element selects no revisions of that versioned resource. If the DAV:needed-activities collection of an activity is non- empty, then the DAV:rsr-activity element acts like a DAV:rsr-merge element that contains that activity and each of the DAV:needed- activities. A DAV:rsr-activity-latest element can generate conflicts only if the DAV:needed-activities collection is non- empty. 6.1.3 DAV:rsr-label A DAV:rsr-label element contains a label. If a revision of the versioned resource has that label, that revision is selected by the DAV:rsr-label element; otherwise, no revision is selected. A DAV:rsr-label element never generates a conflict. 6.1.4 DAV:rsr-revision-id A DAV:rsr-revision-id element contains a revision id. If a revision of the versioned resource has that revision id, that revision is selected by the DAV:rsr-revision-id element; otherwise, no revision is selected. A DAV:rsr-revision-id element never generates a conflict. 6.1.5 DAV:rsr-latest A DAV:rsr-latest element selects the revision of that versioned resource with the latest DAV:creationdate. A DAV:rsr-latest element never generates a conflict. 6.1.6 DAV:rsr-or A DAV:rsr-or element contains a sequence of RSR elements. The behavior of a DAV:rsr-or element is identical to the behavior of the first element in this sequence that selects a revision of the versioned resource. If no element selects a revision, then the DAV:rsr-or element selects no revision of that versioned resource. 6.1.7 DAV:rsr-merge A DAV:rsr-merge element contains a sequence of RSR elements. If one of the elements in this sequence selects a revision that is the descendent of all of the other revisions selected by elements in this sequence, then that revision is selected by the DAV:rsr-merge element. If no selected revision is a descendent of all the other selected revisions, then the result of the DAV:rsr-merge is a "conflict". A conflicts REPORT request can be used to identify the conflicts. Clemm, Kaler [Page 27]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 6.2 Report Elements 6.2.1 Conflicts Report A conflicts report describes the conflicts in a specified workspace for a specified resource or for all the members of a specified versioned collection. 6.2.1.1 DAV:conflicts-report-request A DAV:conflicts-report-request contains the URL of a workspace and the URL of a versioned resource. 6.2.1.2 DAV:conflicts-report-response A DAV:conflicts-report-response contains a DAV:conflict element for each versioned resource for which the revision selection rule specified in the DAV:conflicts-report-request produced a conflict. The DAV:conflict element identifies the versioned resource which generated a conflict, as well as information about how to resolve the conflict (such as the revisions that would need to be merged). 6.2.1.3 DAV:conflict The DAV:conflict element contains the URL of a versioned resource for which the revision selection rule generated a conflict, a DAV:common-ancestor for the conflict, and two or more DAV:contributor elements for the conflict. 6.2.1.4 DAV:common-ancestor The DAV:common-ancestor element identifies a revision that is a common ancestor of all the DAV:contributor elements for a particular conflict. 6.2.1.5 DAV:contributor The DAV:contributor element identifies a revision that is selected by an element of the revision selection rule but that is not an ancestor of any of the other revisions selected by the revision selection rule. 6.2.2 Compare Report 6.2.2.1 DAV:compare-report-request A DAV:compare-report-request contains the URL's of two resources of the same type. Clemm, Kaler [Page 28]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 6.2.2.2 DAV:compare-report-response A DAV:compare-report-response identifies the differences between two resources of the same type. These differences are indicated by appropriate DAV:added, DAV:deleted, and DAV:changed elements. In particular, if a DAV:compare-report-request is applied to two configuration revisions. The DAV:compare-report-response contains the revisions, needed-configurations, and activities that are selected by one configuration revision but not the other. 6.2.2.3 DAV:added A DAV:added element identifies something that appears in the second resource but not in the first. 6.2.2.4 DAV:deleted A DAV:deleted element identifies something that appears in the first resource but not in the second. 6.2.2.5 DAV:changed A DAV:changed element identifies something that is in both resources but that is in some way different in the two resources. For example, when two configurations are being compared, a DAV:changed element can identify a versioned resource, a versioned collection, or an activity. A versioned resource has changed if the configurations select different revisions of that versioned resource. A versioned collection has changed if the configurations select different revisions or different baselines of that versioned collection. An activity has changed if both configurations contain that activity but the DAV:revisions or DAV:needed- activities of that activity were different when those configurations were created. 7 INTERNATIONALIZATION CONSIDERATIONS To be supplied. NOTE: If a revision label contains a URL reserved character, that character is escaped in the DAV:revision-labels name. 8 SECURITY CONSIDERATIONS To be supplied. 9 SCALABILITY To be supplied. Clemm, Kaler [Page 29]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 10 AUTHENTICATION Authentication mechanisms defined in WebDAV will also apply to DAV Versioning. 11 IANA CONSIDERATIONS This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to DAV Versioning. 12 INTELLECTUAL PROPERTY The following notice is copied from RFC 2026 [RFC2026], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13 ACKNOWLEDGEMENTS This protocol is the collaborative product of the Delta-V design team: Jim Amsden (IBM, DeltaV Chair), Geoffrey Clemm (Rational), Bruce Cragun (Novell), David Durand (INSO), Chris Kaler (Microsoft), Jeff McAffer (OTI), Bradley Sergeant (Merant), and Jim Whitehead (UCI). We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV and DeltaV working groups. 14 INDEX To be supplied. Clemm, Kaler [Page 30]
INTERNET-DRAFT WebDAV Versioning June 25, 1999 15 REFERENCES [RFC2068] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine, DEC, MIT/LCS, January 1997. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 1997. [RFC2518] Y. Goland, E.J. Whitehead, A. Faizi, S.R. Carter, D. Jenson, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, Microsoft, UCIrvine, Netscape, Novell, February. 1999. [AdvCol] http://www.ietf.org/internet-drafts/draft-ietf-webdav- collection-protocol-03.txt [VerGoal] http://www.ietf.org/internet-drafts/draft-ietf-webdav- version-goals-02.txt 16 AUTHORSÆ ADDRESSES Geoffrey Clemm Rational Software 20 Maguire Road Lexington MA 02421-3104 Email: geoffrey.clemm@rational.com Christopher Kaler Microsoft One Microsoft Way Redmond WA 9085-6933 Email: ckaler@microsoft.com 17 OPEN ISSUES The following list identifies key open issues against this document: @ TODO: Add the appropriate DAV:resourcetype properties to workspace, history resource, activity, and configuration. @ TODO: Flush out details on methods: e.g., request/response examples needed. @ TODO: DTDs and semantics of properties @ TODO: Lots of details @ ISSUE: How are policies discovered? @ ISSUE: Does Versioning have to be a header, or can it be the body of the OPTIONS response? @ ISSUE: Couldn't MKRESOURCE be handled just by allowing PROPPATCH to be applied to a null resource? Clemm, Kaler [Page 31]
