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]