wdiff draft-ietf-webdav-versioning-01.txt draft-ietf-webdav-versioning-02.txt

INTERNET-DRAFT Chris Kaler, Microsoft, Editor
draft-ietf-webdav-versioning-01.txt Jim Amsden, IBM
Goeff Geoffrey Clemm, Rational
Bruce Cragun, Novell
David Durand, BU
Bradley Sergeant, Microfocus
Jim Whitehead, UC Irvine Software
draft-ietf-webdav-versioning-02.txt Chris Kaler, Microsoft

Expires June 20, December 25, 1999 January 20, June 25, 1999

Versioning Extensions to WebDAV

Status of this Memo Memo.

This document is an Internet draft. Internet drafts 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 areas, and its working groups. Note that other groups
may also distribute working information documents as Internet drafts.

Internet Drafts Internet-Drafts.

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

To learn the current status progress."

The list of any Internet draft please check the
"lid-abstracts.txt" listing contained in the Internet drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.isi.edu (US East coast) or
ftp.isi.edu (US West coast). Further information about the IETF current Internet-Drafts can be found accessed at URL: http://www.ietf.org/

Distribution of this document is unlimited. Please send comments
to the mailing
http://www.ietf.org/ietf/1id-abstracts.txt

The list at <ietf-dav-versioning@w3.org>, which may be
joined by sending a message with subject "subscribe" to <ietf-dav-
versioning-request@w3.org>.

Discussions of the list are archived Internet-Draft Shadow Directories can be accessed at
<URL:http://www.w3.org/Archives/Public/ietf-dav-versioning/>.
http://www.ietf.org/shadow.html.

Abstract

This document specifies a set of methods, headers, and content-
types composing DAV resource-types
that define the WebDAV Versioning extensions, an application of extensions to the HTTP/1.1 protocol protocol.
WebDAV Versioning will minimize the complexity of clients so as to version DAV resources.
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.

Table of Contents

VERSIONING EXTENSIONS TO WEBDAV ...........................1 WEBDAV...........................1

STATUS OF THIS MEMO.......................................1

ABSTRACT..................................................1

TABLE OF CONTENTS .........................................2

1. INTRODUCTION ..........................................4
1.1.DAV Versioning ........................................4
1.2.Relationship CONTENTS.........................................2

1 INTRODUCTION...........................................4
1.1 Relationship to DAV ...................................4
1.3.Terms .................................................4
1.4.Definitions ...........................................4
1.5.Notational Conventions ................................5

2. BASIC DAV.................................4
1.2 Terms...............................................5
1.3 Notational Conventions..............................5

2 CONCEPTS AND DEFINITIONS...............................5

3 WEBDAV VERSIONING ......................................5
2.1.Discovery .............................................6
2.2.Immutable and Mutable Properties ......................7
2.3.Versioning SEMANTICS...........................10
3.1 Creating Versioned Resources.......................10
3.2 Modifying a Resource .................................8
2.4.Immutable Versioned Resource.....................11
3.3 Naming Revisions: Revision Ids and Mutable Revisions .......................8
2.5.Versioning Labels..........11
3.4 Parallel Development and COPY/MOVE ..............................9
2.6.Sharing ...............................................9
2.7.Default Revision .....................................10
2.8.Collection Versioning ................................11
2.9.Basic Activities................12
3.5 Revision Properties ............................11
2.10. Basic Versioning Headers ...........................13
2.10.1. Revision-Id .....................................13
2.10.2. Branch-Id .......................................14
2.10.3. Override-Checkin ................................14
2.10.4. Revision-Path ...................................14

3. CHECKING OUT/IN RESOURCES ............................15
3.1.Checkout .............................................15
3.2.Checkin ..............................................17
3.3.Cancelling Checkout ..................................17
3.4.Enumeration ..........................................18

4. BRANCHING RESOURCES ..................................18

5. Selection and Workspaces..................12
3.6 Configurations.....................................13
3.7 Versioned Collections..............................13

4 VERSIONING RESOURCE REPORTS .....................................19
5.1.Available Reports ....................................20
5.2.Default History ......................................21
5.3.Active Checkouts .....................................22
5.4.Direct Lineage .......................................23
5.5.Full Lineage .........................................24

6. CONFIGURATION BASICS .................................26
6.1.Discovery ............................................27
6.2.Creating Configurations ..............................28
6.3.Access Using Configurations ..........................30
6.4.Deleting Configurations ..............................30
6.5.Resolution Queues ....................................30
6.6.Configuration Properties .............................31
6.7.Headers ..............................................32

7. CONFIGURATION REPORTS ................................33
7.1.Configuration Derivation .............................33
7.2.Configuration Merge Graph ............................34

8. DYNAMIC CONFIGURATIONS ...............................35

9. WORKSPACE CONFIGURATIONS .............................37
9.1.Managing Configuration Content .......................37
9.2.Default 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
4.4.5 DAV:activity (readonly, resource) [Activity].....18
4.5 Workspace Configurations .....................38

10. CHECKIN SETS .........................................38

11. VERSION MAPPING ......................................39
11.1. Discovery ..........................................40
11.2. Mapping Configurations .............................41
11.3. Mapping 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 Versions ..........................41

12. 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 GRAMMAR ...........................42

13. 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
7 INTERNATIONALIZATION CONSIDERATIONS ..................42

14. CONSIDERATIONS...................29

8 SECURITY CONSIDERATIONS ..............................43

15. SCALABILITY ..........................................43

16. AUTHENTICATION .......................................43

17. CONSIDERATIONS...............................29

9 SCALABILITY...........................................29

10 AUTHENTICATION......................................30

11 IANA CONSIDERATIONS ..................................43

18. COPYRIGHT ............................................43

19. CONSIDERATIONS..................................30

12 INTELLECTUAL PROPERTY ................................43

20. REFERENCES ...........................................43

21. AUTHOR'S ADDRESSES ...................................44

22. PROPERTY................................30

13 ACKNOWLEDGEMENTS.....................................30

14 INDEX................................................30

15 REFERENCES...........................................31

16 AUTHORS ADDRESSES....................................31

17 OPEN ISSUES ..........................................44

23. CHANGE HISTORY .......................................45
1. ISSUES..........................................31

1 INTRODUCTION

1.1. DAV Versioning

This document defines DAV Versioning extensions, an application of
HTTP/1.1 for handling resource versioning in a DAV environment.
[DAVVERREQ]
[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 HTTP/1.1-based versioning-unaware clients,

- Basic Linear versioning for DAV Versioning-aware clients,

- File branching for basic parallel development, , and

- Configuration support Support for sophisticated parallel development.

1.2. 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
[WebDAV]. DAV Versioning does not alter this model. Instead, DAV
Versioning allows clients to version and access DAV-modeled
resources [RFC2518] and histories.

1.3. Terms

This draft uses the terms binding model defined in [RFC2068], [WebDAV], and
[DAVVERREQ].

1.4. Definitions by
[AdvCol]. The section defines several terms versioning protocol is designed so that are used throughout the
document specific to DAV versioning.

Versioned Resource - This refers to WebDAV
locking (class 2) support is optional. The effect of a resource lock on
versioning methods and content-types will be defined to provide
interoperability of servers that provide locking support.

Versioning support is subject to
versioning (independent defined in the form of any specific version)

Revision - This refers to Core versioning
support, supplemented by a specific version set of a versioned
resource

Revision History - This refers orthogonal extensions to the set
Core: Activity, Merging, Configuration, Versioned Collection, and
Baseline versioning support. Core support provides versioning of changes to a versioned
resource
Working Resource - This refers
largely independent resources. It allows authors to a resource that is an
intermediate revision concurrently
create and access distinct revisions of a versioned resource. That is, 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
versioned resource has been "checked out" 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 where changes
are made until it is ready used to be "checked in". Note
indicate that working
resources are not versioned.

Revision Thread - This refers to a sequence property is introduced at the "xyz" level of revisions that have
been branched for a specific purpose.

Line
versioning support. The levels of Descent - versioning support provided by a
server can be discovered via an OPTIONS request.

1.2 Terms

This refers to the sequence of revisions that
have occurred from draft uses the initial revision to a specified revision.

1.5. 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. BASIC VERSIONING

2 CONCEPTS AND DEFINITIONS

The base level of versioning support defined by this specification
includes both automatic versioning and section presents the basic versioning
properties defined for all 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
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 |
+----+ | 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 |
| +----+ | +----+
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
+----+ +----+
| 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. To support basic versioning, Unlike a workspace, which can select both
working resources MUST allow 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
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 versioning to occur automatically on
selected 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 whenever immutable aspects can be put under
version control; these are changed, called versionable resources. After a
resource is put under version control, it becomes a versioned
resource, and
support 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 defined or contents any number of times. When the
author is satisfied that the working resource is in this section.

Resources a state that support DAV:versioning MUST also provide additional
versioning semantics for versioning-aware clients. This section
describes these new semantics which include enhancements
should be retained in the versioned resource history, the author
checks in the working resource to
existing DAV methods, create a new revision of the
versioned resource. The revision that was checked out is the
predecessor of the new headers, revision.

The use of checkout/checkin and new versioning-specific
methods.

Although working resources to update a
versioned resource addresses the semantics can vary, most versioning systems support 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 notion predecessor of indicating the
updated resource is reliably tracked. Authors can use
checkout/checkin to register intent to modify a document (check-out) 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 then submission the server prevents lost updates by retaining all
saved states (revisions) of the modified 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 (check-in). Typically
this involves some form of locking (either shared histories, or exclusive).
As well, many systems support
to guarantee the ability possibility of backtracking to cancel a check-out or
undo previous saved
state. If the revision is mutable, the author may request that a recent check-in. These options
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 available 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
persistent, immutable identifier distinguishing this revision from
all others of the same versioned resource. The revision id cannot
be changed, assigned to the owner another revision, or reused.

A user may assign revision labels to a revision in order to provide
a more meaningful name for the Administrator.

Users revision. A given revision label
can generally enumerate the current check-outs although they
may not be able assigned to determine the user in all cases. Likewise,
users can review check-ins at most one revision of a given versioned
resource, but may be reassigned to see any revision of the change history. Most systems
allow users to select versioned
resource at any time. Revisions of different versions from versioned resources
may have the change history same label.

3.4 Parallel Development and present Activities

In a comparison of the versions.

Note that locks are not covered in this specification as they are
addressed locking model, when a resource is locked for modifications by [WebDAV].

2.1. Discovery

The OPTIONS method allows the client
one author, all other authors are supposed to discover if respect that lock and
not work on a resource
supports versioning. The presence copy of Versioning in that resource until the response
header indicates support for DAV versioning. This header indicates lock has been
released. To avoid the level of support.

The following defines work serialization inherent in the BNF for locking
model, a versioning model allows multiple authors in different
workspaces to check out the Versioning header:

Versioning := "Versioning" ":" URI

The valid values of same revision at the URI are:

- DAV:basicversioning

- TBD

This example shows that 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 /somefolder resource supports
versioning.

>> Request

OPTIONS /somefolder/ HTTP/1.1
Host: foobar.com
Content-Length: 0

>> Response

HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF, FREEZE, THAW,
CHECKIN,
CHECKOUT, UNCHECKOUT, BRANCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF, FREEZE, THAW,
CHECKIN,
CHECKOUT, UNCHECKOUT, BRANCH
Versioning: DAV:basicversioning
Content-Length: 0

Since resulting revisions at some aspects of DAV versioning require clients to know
additional information, clients can include later time.

Although a request body that
specifies that DAV simple versioning information is desired. The
information is returned in the response body, formatted in XML.

>> Request

OPTIONS /somefolder/ HTTP/1.1
Host: foobar.com
Content-Length: xxx
Content-Type: text/xml

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo/>
</D:options>

>> Response

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo>
...
</D:verinfo>
</D:options>

The details of model works well for isolated changes
to independent resources, the tags returned required merge process becomes
unmanageable when sequences of inter-related changes are described throughout performed
on sets of related resource. To address this
specification.

2.2. Immutable and Mutable Properties merge problem,
resources can be checked out in the context of an activity. An immutable property is defined as
activity captures the set of revisions that form a property that, when changed,
causes set of related
changes an author is making to one or more versioned resources.
Each activity represents a new revision 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 to be created.
Likewise, a mutable property is a property that histories,
the activities can be changed
without having unified through a new revision created.

Resources can support both mutable merge operation.

3.5 Revision Selection and immutable properties
although there MAY be restrictions that the mutability is
consistent across all resources.

This specification doesn't cover the discovery or management Workspaces

Resources, working resources, and revisions of
property mutability.

2.3. Versioning versioned resources
are all accessed using a Resource

By default, URL. When a resource may not be subject to versioning. This can
be discovered by examining the DAV:isversioned property. To place client accesses a non-versioned resource under version control, clients use the
VERSION method and versioned
resource, it is necessary to provide additional information to
specify the URI which working resource or which revision of the versioned
resource to version.
Note that if should be accessed. Specifying the specified resource is URL and a collection, then
revision name can access a specific revision of the Depth
header is used to identify versioned
resource. However, this requires the scope user to add and remember
labels for each revision; it does not provide a way of the operation. A depth accessing a
consistent set of
infinity is assumed revisions captured by default.

The DAV:isautoversioned property indicates if an activity or contained in
a resource is
automatically versioned when any immutable aspect of configuration; it is changed.
Resources with automatic versioning allow HTTP/1.1 does not enable non-versioning aware clients to have
changes versioned without explicit versioning commands. This
applies
access revisions; and it does not provide a client with access to any method that modifies a
working resource (e.g., PUT, MKCOL,
COPY, MOVE, DELETE, PROPPATCH, ...)

Using the DAV:versioningenabled and DAV:autoversioning tags,
clients can establish the versioning policy.

>> Request

VERSION /somefolder/ HTTP/1.1
Host: foobar.com
Depth: infinity
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:versioning xmlns:D="DAV:">
<D:versioningenabled>On</D:versioningenabled>
<D:autoversioning>On</D:autoversioning>
</D:versioning>

>> Response

HTTP/1.1 200 OK
Content-Length: 0

2.4. Immutable and Mutable Revisions

By default, the contents of a versioned resource.

To address the restrictions inherent in revision-name based
revision are immutable. That is,
once selection, the revision selected when a specific revision is created, it cannot be altered. However, in many
document management systems this
name is not specified is resolved through a workspace. A workspace
is a resource whose primary purpose is to identify working
resources. If the case. To address these
scenarios, the THAW/FREEZE methods are introduced. Note that
support workspace contains no working resource for THAW and FREEZE are optional, but these operations MUST
fail if not supported.

The THAW method specifies that the indicated revision should be
made mutable so that subsequent methods a
given versioned resource, it can alter the immutable
aspects also be used to select an
appropriate revision of the versioned resource. The FREEZE method indicates that all
changes have been made This allows
versioned resources and the revision should unversioned resources to be marked immutable
again.

The DAV:canthaw property indicates if 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 be thawed.
Similarly, the DAV:hasthawed property indicates if specify
revision names, activities, configurations, or use operators that
combine several of these rule elements. A revision name selects a
revision has
ever been thawed. Finally, with that name. An activity selects the DAV:isthawed property specifies if latest revision
that was created in that activity. Configurations select the
revision is currently thawed (frozen if not).

The following example shows contained in the use configuration. The "or" operator contains
a sequence of THAW and FREEZE.

>>Request

THAW /foo/bar.htm HTTP/1.1
Revision-Id: VER:FHF45409
Host: www.foobar.com
Content-Length: 0
...

PUT /foo/bar.htm HTTP/1.1
Revision-Id: VER:FHF45409
Host: www.foobar.com
Content-Length: xxx
...

FREEZE /foo/bar.htm HTTP/1.1
Revision-Id: VER:FHF45409
Host: www.foobar.com
Content-Length: 0
...

2.5. Versioning rule elements, and COPY/MOVE

When 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 COPY method request is issued against made and no workspace is specified, a versioned resource or
revision, only server
determined default workspace is used. This is the workspace used by
all versioning-unaware clients. A server MAY allow modifications to
the "current" revision selection rule of the versioned resource default workspace.

3.6 Configurations

A workspace selects a volatile set of revisions. Changes to
selected activities or
the specified revision is copied changes to labels may result in the specified destination.
That is, the entire history is NOT copied.

When a MOVE method
selection of different revisions. A configuration is issued against a versioned resource
that selects a set of immutable revisions. A workspace whose
version selection rule contains a configuration will always select
the
"move" SHOULD be represented in same revisions as long as the revision history. That is, configuration is not modified and
no checkouts are performed in that workspace.

Configurations are convenient for defining a
MOVE operation CANNOT persistent set of
revisions that relate to each other in some specific way at some
point in time. This can be represented as useful for a delete and variety of purposes such as
publishing consistent versions of resources to deploy an add. A
MOVE operation cannot be issued against
application, or for recovering a specific revision.

2.6. Sharing

Many versioning systems today provide the ability to have state for legal or
maintenance reasons.

3.7 Versioned Collections

A collection contains a given
resource visible in multiple parts set of named bindings to other resources
that are the namespace. In these
situations, members of that collection. For a resource is shared. That is, changes to versioned
collection, the resource bindings are visible to all versions.

The WebDAV Advanced Collections working group addresses this need
with direct referential members. Support for direct referential
members is required for DAV versioning.

2.7. Default Revision

If a Revision-Id (or Branch-Id) header is versioned resources, not specified when
referring to
particular revisions. To modify the state of a resource, then versioned collection
(i.e. add or remove a binding), the tip (latest) revision (from versioned collection must be
checked out, just like any other versioned resource. Requests that
modify the
primary branch) is used, unless a default revision has been
identified. To mark state of a specified revision collection member, such as the default checking it out or
checking in a new revision,
clients use have no effect on the SETDEFAULT method. Note state of the
collection. Conversely, requests that PUT modify the state of a
versioned collection, such as deleting or CHECKIN will
remove any default version. Also note that branching adding a resource
has binding to
resource, have no effect on the default revision state of that resource. In
particular, the resource, even if resource will remain bound in any other revisions
of the
default collection of which it was a member.

If a URL identifies a sequence of nested versioned collections,
revision selection is branched. If performed for each versioned collection in
the default is removed, sequence, to select the
default versioned collection revision is that will
be used to map the tip revision next segment of the initial (primary)
branch of URL to the appropriate
versioned resource.

Setting the default revision to DAV:none cancels

4 VERSIONING RESOURCE TYPES AND PROPERTIES

This section defines the default
revision.

>>Request

SETDEFAULT /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:setdefault xmlns:D="DAV:">
<D:href>VER:HT58GHDW49</D:href>
</D:setdefault>

>>Response

HTTP/1.1 200 OK
Content-Length: 0

>>Request

SETDEFAULT /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:setdefault xmlns:D="DAV:">
<D:none/>
</D:setdefault>

>>Response

HTTP/1.1 200 OK
Content-Length: 0

If a new resource is shared, servers MUST support the ability to set
different default revisions at each point types and properties
introduced by WebDAV versioning.

4.1 Property Attributes

There are several important attributes of the share.

Clients properties that will be
defined for every property introduced by this document.

4.1.1 Writeable/Readonly Properties

A writeable property can determine the default revision be modified by a client, while a readonly
property can only be modified by examining the
DAV:revisionid from the default revision.

>>Request

PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:revisionid/>
</D:prop>
</D:propfind>

2.8. Collection Versioning

Collections 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 versioned just like non-collection resources,
however, they are only versioned when represented as
an HTTP resource. Doing so allows a direct change is made client to use the collection.

It is up to each collection resource to determine if it supports
default versions. If it doesn't, then SETDEFAULT requests MUST
fail.

The Revision-Path header is used to identify specific revisions
that are part full set of
HTTP methods to manipulate the "path" contents of that property, rather
than being limited to the resource. functionality provided by PROPFIND and
PROPPATCH. This header servers is particularly valuable for a property value that
is naturally represented as a collection resource. By default,
PROPFIND returns an alternative to "URL munging". This header can be specified
on all methods and qualifies XML document as the resource named value of a property
resource; however, when a DAV:property-resource-URL element is
specified in the method.

2.9. Basic Revision Properties

For resources that PROPFIND request body, PROPFIND will return the
URL of the property resource. Servers MAY support versioning, they DAV:property-
resource-URL for a property, but MUST support the
following default XML
value.

All properties using the "DAV:" namespace. Note that 0/1 is
used are property resources are explicitly marked as a FALSE (0) / TRUE (1) indicator.

DAV:isversioned - 0/1 to indicate if
"resource". If the property resource is versionable.
Note that this can be implemented as a read-only property.

DAV:autoversion - 0/1 to indicate if collection, the resource property
is automatically
versioned when modified. Note that this can be implemented this marked as "collection".

4.2 Resource Properties

WebDAV versioning introduces the following additional properties
for a read-only property.

DAV:revisionid - resource:

4.2.1 DAV:author (immutable) [Core]

This property is used to track the author of a read-only resource.

4.2.2 DAV:comment (immutable) [Core]

This property that returns is used to track a brief comment about a server
determined id for this specific revision of the resource. Every
revision of

4.3 Revision Properties

WebDAV versioning introduces the following additional properties
for a resource will have revision:

4.3.1 DAV:revision-id (readonly) [Core]

The DAV:revision-id is an identifier assigned to a unique DAV:revisionid. A revision id may be by the
server. Whenever a URL revision is created or modified by a CHECKIN, it may
must be an arbitrary server-defined
string. However, it assigned a new DAV:revision-id. A revision cannot contain the "," character. Because it
is not required to be given
a URL, the DAV:revisionurl property is
required DAV:revision-id that has been given to obtain any other revision of that
versioned resource, even a URI for the specific revision that has been deleted.

4.3.2 DAV:predecessor (readonly, resource) [Core]

The DAV:predecessor of the resource.

DAV:vresourceid - This is a read-only property revision is the revision that returns was checked
out to produce a
server determined id working resource that was checked in to produce
this revision. The XML document for DAV:predecessor contains the versioned resource. That is, all
revisions
revision-id of the resource have DAV:predecessor.

4.3.3 DAV:successors (readonly, mutable, collection) [Core]

The DAV:successors collection of a revision contains the same DAV:vresourceid. This MUST
be preserved over MOVE requests and should be globally unique.

DAV:previousrevisionids - This revisions
whose DAV:predecessor is a read-only property that returns
the server defined id revision. The XML document for
DAV:successors contains a list of the previous revision revision-id's of the resource.
An empty value indicates that there are no previous revisions.
Note that there could be multiple previous versions. If there are
multiple revisions, they are returned as
DAV:successors.

4.3.4 DAV:single-checkout (mutable) [Core]

When the DAV:single-checkout property of a comma-separated list.
Note revision is set, only
one working resource can be checked out from that this revision at any
time.

4.3.5 DAV:auto-version (mutable) [Core]

When the DAV:auto-version property returns previous revisions of a revision is set, a PUT
request (or any request that modifies an immutable aspect of the server
determines. That is,
revision) to this does not include user identified merged
revisions.

DAV:distinguishedpredecessorid - This read-only property indicates
the primary predecessor for a revision in is automatically preceded by a CHECKOUT
into the event they are
multiple predecessors.

DAV:nextrevisionids - default workspace and followed by a CHECKIN. This is allows
a read-only property that returns versioning-unaware client to modify a version-controlled
resource. The DAV:auto-version value can take the
server defined id for same values as
the DAV:checkin-policy of a working resource, and the next revision DAV:checkin-
policy of the resource. An empty
value indicates that there automatically created working resource is no subsequent revision. Note that
there could set to be multiple next revisions. If there are multiple
revisions, they are returned as a comma-separated list. Note that
this property returns successor revisions that
the server
determines. That is, this does not include user identified merged
revisions.

DAV:revisionurl - DAV:auto-version policy of the revision.

4.3.6 DAV:revision-labels (mutable) [Core]

This is a read-only property is used to identify labels that returns are associated with a URL
for this
specific revision.

DAV:revisionlabel -

4.3.7 DAV:checkin-date (readonly) [Core]

This property allows contains the specification 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
textual names the workspaces that refer to contain
working resources whose DAV:predecessor is this version 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 the resource. If there
are multiple labels, they are returned as a comma separated list.
Labels MUST be unique for revision is the versioned resource. That is, no two
revisions DAV:uuid of the same versioned history
resource can have the same
DAV:revisionlabel. As well, DAV:revisionlabel and DAV:revisionid
properties share the same namespace and there can be no duplicates.
Servers MAY reserve specific portions of whose DAV:revisions collection contains this namespace and return
an error if a client uses a reserved name as revision.

4.3.10 DAV:history (readonly, resource) [Core]

The DAV:history of a revision label.
This property MUST be mutable.

DAV:mergedfrom - This property specifies is the history resource whose
DAV:revisions collection contains this revision. The XML document
for DAV:history contains a comma separated list description of
revision ids from which 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 is purported to be derived.
This information is provided and managed contains the
revisions whose contents were explicitly merged by the client. This client into
that revision. The client is a
mutable property.

DAV:mergedto - This property specifies a comma separated list of
revision ids from which free to add or delete members to this revision is purported
collection to be merged
into. This information is provided and managed by more accurately reflect the client. This
is a mutable property.

DAV:mergedfromunion - This read-only property specified a comma
separated list contents of that
revision. The XML document for DAV:merge-predecessors contains the
revision ids from which this revision is derived.

This is a union id's of the DAV:mergedfrom and DAV:previousrevisionids
properties.

DAV:revisioncomment - This property contains DAV:merge-predecessors.

4.3.12 DAV:merge-successors (mutable, collection, readonly) [Merging]

The DAV:merge-successors collection of a client-defined
property associated with the revision. This as revision contains a mutable property.
This is
binding to each revision whose DAV:merge-predecessors collection
contains a mutable property.

DAV:author - binding to that revision. The creator XML document for
DAV:merge-successors contains the revision id's of the revision. This 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 an arbitrary
string.

DAV:canthaw - This property indicates if the revision can be THAWed workspace that
contains this working resource. The XML document for modification. Servers MAY implement DAV:workspace
contains the URL of this as read-only.

DAV:hasthawed - workspace.

4.4.2 DAV:predecessor (read-only, resource) [Core]

This read-only property indicates if contains the revision
has ever been thawed.

DAV:isthawed - This read-only 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 revision working
resource is
currently thawed (or frozen if not).

DAV:lastcheckin identical to its DAV:predecessor.

DAV:identical-uncheckout - This read-only property specifies an UNCHECKOUT should be applied instead
of CHECKIN if the date this
revision was "checked in" in ISO8601 format.

2.10. Basic Versioning Headers

The following sub-sections describe 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 version headers revision.

DAV:mutable - a new revision is created that
MUST can be supported for resources that support DAV:versioning.

2.10.1. Revision-Id

The Revision-Id header overwritten by
a subsequent DAV:overwrite CHECKIN.

DAV:immutable - a new revision is used to identify created that cannot be
overwritten by a specific revision of subsequent DAV:overwrite CHECKIN.

DAV:keep-checked-out - create a
versioned new revision but does not delete
the working resource. This header can be specified on all methods
and qualifies The DAV:predecessor of the working resource named in the method. As well, this
header
is included in all replies changed to indicate be the new revision.

DAV:baseline - instead of creating a new revision of the versioned resource used or created.

The BNF
collection, create a new baseline for this header it (the CHECKIN fails unless
it is as follows.

Revision-Id := "Revision-Id" ":" RID
RID := "*" | Time-Ref | ANY
Time-Ref := "Time" "(" ISO8601 ")"

This property allows the specification of criteria that selects applied to a
specific revision 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. This includes a DAV:revisionid or
any The client adds and deletes
members of the DAV:revisionlabel values to refer this collection to a specific revision reflect the set of revisions that
were merged by the client into the working resource. As well, The name of a configuration (described later) can be
referenced here to select
DAV:merge-predecessors binding is the DAV:revision-id of that
revision. The XML document for DAV:merge-predecessors contains the default
revision associated with id's of the
configuration. DAV:merge-predecessors.

4.4.5 DAV:activity (readonly, resource) [Activity]

The use DAV:activity property of the Time operator a working resource is to select the "current" revision as DAV:activity
of the specified time. workspace when the working resource was checked out. The use of Revision-Id: *
XML document for DAV:activity is only permitted with PROPFIND to obtain the URL for the activity.

4.5 Workspace Properties

WebDAV versioning introduces the following additional properties across all
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.

2.10.2. Branch-Id

The Branch-Id header is used to identify a branch (revision
thread). The BNF for the header is as follows:

Branch-Id := "Branch-Id" ":" ANY

The Branch-Id can be used anywhere resource in a revision-id workspace is used. When
specified, it indicates that the latest version of
working resource in that workspace for that versioned resource,
else the indicated
branch is to be revision selected as by the workspace revision to use for the operation.

2.10.3. Override-Checkin

It is possible selection
rule. To ensure that the check-in operation will detect working resources continue to be visible in a conflict.
For example, version 5 was checked out shared, and before it is
workspace after they are checked back in, version 6 was created. In these situations, the
check-in MUST fail indicating a conflict. Clients can choose to
branch the resource, merge on the client, DAV:label or overwrite. To
circumvent this check, clients can use the Override-Checkin header.
This specifies that DAV:activity
of a workspace is usually the check-in operation SHOULD NOT fail (either first element of the client has merged to resolve DAV:revision-
selection-rule. If the conflict, DAV:revision-selection-rule is not set or desires an
overwrite). The BNF is as follows:

Override-Checkin := "Override-Checkin" ":" ("Yes" | "No")

2.10.4. Revision-Path

The Revision-Path header allows clients to identify specific
versions of collections that should be used rather than
empty, the default
revisions.

The BNF for this header is as follows.

Revision-Path := "Revision-Path" ":" Path
Path := PItem | (Path PItem)
PItem := "/" ANY Rev
Rev := | (";" RID)
RID := "*" | ANY | "(" ANY ")"

>>Request

GET /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Revision-Path: /foo;VER:HT58GHDW49/bar.htm
Content-Length: 0

The use of * for a revision is only permitted with PROPFIND to
obtain properties across all revisions of a selection rule will select no revision for any
versioned resource.

3. CHECKING OUT/IN RESOURCES

For versioning-aware clients, more advanced requests allow them to
perform specific versioning operations. These methods

Standard revision selection rule elements are directed
at a specific URI to alter.

If a resource supports DAV:versioning then it MUST support the
methods defined in this section.

3.1. Checkout

Using the CHECKOUT method, clients
document, but additional revision selection rule elements may be
supported by a WebDAV server.

4.5.3 DAV:label [Core]

The DAV:label property of a workspace can request resources to be
"checked out". This involves creating contain a revision label.
When a working resource that in a workspace is
not automatically versioned. Checked out resources must be checked
in or cancelled. The diagram below illustrates in, it will be
given this process:

Revisions label.

4.5.4 DAV:activity [Activity]

The DAV:activity property of foo.htm: V1

Checkout a workspace is performed: V1
|
+-> Working Resource

Checkin the activity that is performed: V1 -> V2
currently being performed in that workspace. A new working
resource in a workspace will have its DAV:activity property set to
this activity. The body XML indicates document for DAV:activity contains the URL
of DAV:activity.

4.6 Activity Properties

WebDAV versioning introduces the following additional properties
for an optional checkout comment, activity:

4.6.1 DAV:revisions (readonly, collection) [Activity]

The DAV:revisions collection of an optional
user token, and locking actions. activity contains all revisions
whose DAV:activity property contains this activity. The response indicates XML
document for DAV:revisions contains the
working resource as well as any requested locks. URL's of these revisions.

4.6.2 DAV:required-activities (collection) [Activity]

The CHECKOUT method causes DAV:required-activities collection of an activity contains the creation
other activities that form a part of the working copy which
is specified logical change being
captured by the Location header in activity. The DAV:needed-activities of an activity
contribute to the response.

Clients can optionally request locks revision selection behavior of that activity when
it is used in a revision selection rule. The purpose of this
property is to be taken as part 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
CHECKOUT operation. 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 locks cannot DAV:workspace of that
activity can only be obtained, the CHECKOUT
operation MUST fail. that workspace. The following table identifies XML document for
DAV:workspace contains the different
lock options:

Lock Tags Used Description
Target (DAV: assumed)

working wrlocktype, Limits access to URL of the workspace.

4.7 Configuration Properties

WebDAV versioning introduces the following properties for a
configuration:

4.7.1 DAV:roots (immutable, collection) [Configuration]

The DAV:roots collection of a configuration contains the newly created
resource wrlockscope working resource

revision revisionlockty Blocks CHECKOUT/INs against this
pe, revision
revisionlocksc
ope
branch branchlocktype Blocks CHECKOUT/INs against
, versioned
resources that are not named by versioned collection revisions in this branch
branchlockscop
e

versioned vrlocktype, Blocks CHECKOUT/INs against any
resource vrlockscope revision
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
resource. collection:

4.8.1 DAV:baselines (resource) [Baseline]

The semantics DAV:baselines of a versioned collection is a versioned
configuration whose DAV:roots contains only that versioned
collection. A revision of the tags match those DAV:baselines of DAV:locktype and
DAV:lockscope as specified a versioned
collection effectively provides a "deep-revision" of that versioned
collection. The XML document for DAV:baselines contains the LOCK method.

>>Request

CHECKOUT /foo/bar HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:checkout xmlns:D="DAV:">
<D:comment>checkout comment</D:comment>
<D:owner>client-defined token</D:owner>
<D:wrlocktype><D:write/></D:locktype>
<D:wrlockscope><D:exclusive/></D:lockscope>
</D:checkout>

>>Response

HTTP/1.1 201 CREATED
Location: http://www.foobar.com/tmp/VRJHJWE3493409
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8"?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:wrlocktype><D:write/></D:locktype>
<D:wrlockscope><D:exclusive/><D:lockscope>
<D:owner>client-define token</D:owner>
<D:locktoken>
<D:href>opaquelocktoken:rejrei-43343-rereffre</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>

Servers MUST fail this operation if URL of
the versioned configuration.

4.9 History Resource Properties

WebDAV versioning introduces the following additional properties
for a branch history resource:

4.9.1 DAV:uuid (readonly) [Core]

The DAV:uuid is required.

3.2. Checkin

When an identifier assigned to a history resource by the client
server. A history resource cannot be given a DAV:uuid that has completed changes been
given to any other history resource, even a history resource and wishes it
to become part 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 history, the client must check in
the resource. This DAV:revisions collection is performed using its DAV:revision-id. If a revision
id contains a URL reserved character, that character is escaped in
the CHECKIN method against DAV:revisions name. The XML document for DAV:revisions
contains the working copy. URL's of the revisions.

4.9.3 DAV:revision-labels (collection) [Core]

The DAV:keepcheckedout tag can be specified DAV:revision-labels collection of a history resource contains a
binding for each label assigned to indicate any revision of that history
resource, where the
resource should remain checked out. That is, create a new
revision, but leave binding name is that label (reserved URL
characters are escaped) and the working copy checked out.

Using XML tags in binding is to the request body, clients revision selected
by that label. The client can specify optional
checkin information.

>>Request

CHECKIN /tmp/VRJHJWE3493409 HTTP/1.1
Host: www.foobar.com
Lock-Token: <opaquelocktoken:rejrei-43343-rereffre>
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:checkin xmlns:D="DAV:">
<D:comment>checkin comment</D:comment>
</D:checkin>

>>Response

HTTP/1.1 201 CREATED
Revision-Id: VER:FREFRI49349
Content-Length: 0 label and unlabel revisions by
adding and deleting members of the DAV:revision-labels collection.

The reply MUST include XML document for DAV:revision-labels contains the Revision-Id URL's of the newly created
revision.

It is possible that
members of the check-in operation will detect a conflict.
Servers MUST fail this operation if a branch is required. The
Override-Checkin header is used to resolve these conflicts.

3.3. Cancelling Checkout

If a client chooses DAV:revision-labels collection.

5 VERSIONING METHODS

5.1 Existing Methods

This section describes the extensions to cancel a checkout request, the UNCHECKOUT
method against existing WebDAV
methods. Under versioning, the working copy. As well, optional XML body tags
can be used to supply additional information.

>>Request

UNCHECKOUT /tmp/VRJHJWE3493409 HTTP/1.1
Host: www.foobar.com
Lock-Token: <opaquelocktoken:rejrei-43343-rereffre>
Content-Type: text/xml
Content-Length: xxxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:uncheckout xmlns:D="DAV:">
<D:comment>cancel checkout comment</D:comment>
</D:uncheckout>

>>Response

HTTP/1.1 200 OK
Content-Length: 0

3.4. Enumeration

Refer to methods inherit all of the Resource Reports section for details on check-out
enumeration.

4. BRANCHING RESOURCES

For more sophisticated clients, basic resource branching WebDAV
functionality with the following extensions.

5.1.1 GET

When GET is
required. Resource branching means that for applied to a given versioned resource, it returns the
history is not linear. That is, there are different lines body of
descent.
the target of that versioned resource. The diagram below illustrates this.

Revision result of GET on a
workspace, activity, or history V1 -> V2 -> V3
Of foo.htm: |
+-> V1.1 -> V1.2
|
+-> V1.1.1

Individual resource branching is common in many versioning systems
today. Project branching (configurations) are described undefined.

5.1.2 BIND

When BIND creates a binding in a later
section. Note that when working resource for a collection is branched, versioned
collection, it MUST fail if the depth request URL of the
branch BIND is infinity. There not a
versioned resource.

5.1.3 PUT

When PUT is no way applied to change this.

A revision a versioned resource whose target is branched using a
working resource, the BRANCH method. The resource PUT is applied to be
branched that working resource.
When PUT is specified as the target URI for the method.

As well, clients can specify a branch label applied to identify a created
branch using the DAV:branchlabel tag. The reply MUST include a
Branch-Id header specifying a versioned resource defined branch id or the
specified branch label if a branch whose target is created. The label or id can
be specified in a Branch-Id or Revision-Id header to determine
revision, the
revision to access.

>>Request

BRANCH VER:FHHR4959 HTTP/1.1
Host: www.foobar.com
Content-Type: text/html
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:branch xmlns:D="DAV:">
<D:branchlabel>MyBranch</D:branchlabel>
<D:comment>branch comment</D:comment>
</D:branch>

>>Response

HTTP/1.1 201 CREATED
Branch-Id: MyBranch
Revision-Id: VER:REUU48583
Content-Length: 0

When a branch is created, PUT MUST fail except in the following two cases. If
the reply MUST include a Branch-Id
header.

5. RESOURCE REPORTS

Revision history graphs and other reports of revision has a resource are
accessed via PROPFIND.

Note that resources MAY support multiple styles of history DAV:auto-version property and
reports. To enumerate no Target-Selector
header has been specified, the supported history graphs and reports,
clients use PROPFIND and revision is checked out into the <DAV:availablereports> property. The
results indicate a list of
default workspace, the different reports which can,
themselves, be requested via PROPFIND.

For PUT is applied to the examples in this section, assume that resulting working
resource, and the working resource /foo.htm
has is checked in. If the following revision graph:

Revision history V1 -> V2 -> V3
Of foo.htm: |
+-> V1.1 -> V1.2
|
+-> V1.1.1

Clients have specified the following merge annotations:

- V1.2
is a merge revision of V1.1 and V1.1.1

- V3 is a merge of V2 baselined collection and V1.2

As well, the default revision history (those revisions marked as the default) value of
DAV:checkin-policy is as follows:

- V1 (the initial revision was created)

- V2 (a DAV:baseline, a new revision was created)

- V1 (a client changed the default revision)

- V3 (an updated revision was created)

Also, the following labels have been specified:

- V2: Test1

- V1.1: Test2, Good

- V1.2: Tested

Additionally, when the V1.1 branch was created, it was labeled
"MyBranch".

5.1. Available Reports

Clients can obtain of the available reports for a resource
DAV:baselines configuration is created by
obtaining its DAV:availablereports property.

>>Request

PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:availablereports/>
</D:prop>
</D:propfind>

>>Response

...
<D:multistatus>
<D:response>
<D:href>http:/www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:availablereports>
<D:report>DAV:defaulthistory</D:report>
<D:report>DAV:directlineage</D:report>
<D:report>DAV:fulllineage</D:report>
</D:availablereports>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
...

Note that the report styles MUST be specified as DAV:href values. CHECKIN.

When clients issue PROPFIND requests PUT is applied directly to obtain reports, they may
include other properties in the request. These properties are
returned for each report item.

5.2. Default History

Resources a revision (i.e. not indirectly
via a versioned resource), it MUST support the DAV:defaulthistory report. This
enumerates the historical record of revisions that have been
visible as the default revision.

Clients can specify the limit parameter fail.

When PUT is applied to limit the number
revisions returned. By definition, revisions are returned in
reverse chronological order starting with the most recent.

>>Request

PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:defaulthistory limit=20/>
</D:propfind>

>>Response

...
<D:multistatus>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V3</D:revision>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1</D:revision>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V2</D:revision>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1</D:revision>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

5.3. Active Checkouts

Clients can obtain a list of the active checkouts against null resource that is an internal member
of a versioned collection whose target is a working resource, a new
versioned resource using PROPFIND and DAV:activecheckouts.

>>Request

PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Revision-Id: VER:FHRJ494059
Depth: 0
Content-Type: text/xml
Content-Length: xxxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:activecheckouts/>
</D:propfind>

>>Response

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:checkout>
<D:owner>user-specified</D:owner>
<D:revisionid>VER:FHER4949</D:revision>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:workingcopy>
<D:href>http://www.foobar.com/tmp/FHFH34949</D:href>
</D:workingcopy>
</D:checkout>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

5.4. Direct Lineage

Resources SHOULD support the DAV:directlineage report. This
enumerates is created at the direct parent revisions request URL of the resource.

Clients can PUT. When
the target is a versioned collection revision, the PUT request that
fails unless the revision has a report be based on DAV:auto-version property and no
Target-Selector header has been specified. If DAV:auto-version is
set, the namespace entry
specified, or versioned collection revision is checked out into the associated DAV:vresourceid. Clients use
default workspace, a new versioned resource is created as a member
of the
scope parameter to specify (name or id).

Clients can specify working collection, and the limit parameter working collection is checked
in.

When a PUT is applied to limit the number
revisions returned.

>>Request a workspace, activity or history resource,
it fails.

5.1.4 PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:directlineage scope="name"/>
</D:propfind>

>>Response

...
<D:multistatus>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V2</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V1</D:derivedfrom>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V3</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V3</D:derivedfrom>
<D:revisionlabel>Test1</D:label>
<D:mergedfrom>V2</D:mergedfrom>
<D:mergedfrom>V1.2</D:mergedfrom>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

5.5. Full Lineage

Resources SHOULD support

If a DAV:property-resource-URL is specified under a DAV:prop
element in a PROPFIND request body, the DAV:fulllineage report. This
enumerates property resource URL of
that property will be returned in the full graph PROPFIND response instead of revisions
the default XML document for this resource.

Clients can request that property resource. If a report be based on
DAV:property-resource-URL is specified directly under the namespace entry
specified, or
DAV:propfind element, the associated DAV:vresourceid. Clients use property resource URL will be returned
for all of the
scope parameter property resources in the PROPFIND response.

5.1.5 PROPPATCH

When PROPPATCH is applied to specify (name or id).

Clients can specify 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 limit parameter
revision has a DAV:auto-version property.

5.1.6 DELETE

When DELETE is applied to limit a versioned resource whose target is a
revision, the number
revisions returned.

>>Request

PROPFIND /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:fulllineage scope="name"/>
</D:propfind>

>>Response

...

<D:multistatus>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V2</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V1</D:derivedfrom>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V3</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V2</D:derivedfrom>
<D:revisionlabel>Test1</D:label>
<D:mergedfrom>V2</D:mergedfrom>
<D:mergedfrom>V1.2</D:mergedfrom>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1.1</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V1</D:derivedfrom>
<D:revisionlabel>Test2</D:label>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1.2</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V1.1</D:derivedfrom>
<D:branchid>MyBranch</D:branchid>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foobar.com/foo/bar.htm</D:href>
<D:propstat>
<D:prop>
<D:revisionid>V1.1.1</D:revision>
<D:vresourceid>VER:FFHJE</D:vresource>
<D:revisioncomment>Update it</D:comment>
<D:derivedfrom>V1.1</D:derivedfrom>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

6. CONFIGURATION BASICS

Many clients require more sophisticated management and organization
of their versioned data. For this reason, configuration support resource is
defined as part of this specification.

Configuration management deleted from the collection
that contains it, but the revision is unaffected. When DELETE is
applied to a large space. This specification
addresses several types workspace, the workspace and all working resources of configurations:

- Dynamic: A dynamic configuration
that workspace are deleted.

When DELETE is applied to a collection member of specific
revisions the DAV:revisions collection
of selected versioned resources based on selection
rules. This can be used for labels, floating labels, etc.

- Workspace: A workspace configuration is a mechanism for tracking
and managing parallel changes history resource, it fails unless the All-Bindings header is
specified. When DELETE is applied to multiple resources.

Configurations provide a mechanism for organizing resources history resource, the
history resource and
quick access to specific revisions all members of resources. Clients can
access resources in the context DAV:revisions collection of a configuration. By referencing
a configuration, requests
that history resource are automatically mapped deleted.

5.1.7 COPY

When COPY is applied to a versioned resource, it is applied to the correct
revision
target of the versioned resource. This allows configurations to
be used as a reference mechanism without breaking URL hyperlinks.

A configuration can be derived from another configuration. That is, only the new configuration selected
revision is based on the versions in copied, not the "parent"
configuration. Optionally, derived configurations can
automatically inherit new versions in 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 parent configuration
(assuming there are no conflicts). However, MOVE request MUST
fail unless a configuration binding to that versioned resource can be
derived from created at most one other configuration.

Clients can specify configuration ids wherever a revision id can be
specified. This requests that
the default revision for Destination of the
specified configuration be used. Requests that include both MOVE.

When a
revision id and MOVE request is applied to an activity or a configuration id MUST fail if history
resource, it fails.

Any request to MOVE a specific revision, and not the specified
revision versioned
resource, MUST fail.

5.1.9 LOCK

A write lock on a versioned resource is not part of applied to the specified configuration. Typically
both target of
that versioned resource.

A write lock on a revision id and prevents unauthorized modifications to
the properties of that revision.

A write lock on a configuration id are not needed since working resource prevents unauthorized changes to
the
revision URI is unique across all configurations.

6.1. Discovery

Configuration support is optional. This example shows body or properties of that working resource.

A write lock on an activity prevents unauthorized modifications to
the
/somefolder properties of that activity.

A write lock on a history resource supports configurations.

>> Request

OPTIONS /somefolder/ HTTP/1.1
Host: www.foobar.com
Content-Length: xxx
Content-Type: text/xml

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo/>
</D:options>

>> Response

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo>
<D:configroot>
<D:href>http://www.foobar.com/cfgs/</D:href>
</D:configroot>
</D:verinfo>
</D:options>
6.2. Creating Configurations

Servers maintain configurations in places a private portion write lock on all
revisions of that history resource.

A write lock on a workspace prevents unauthorized modifications to
the
namespace. properties of that workspace.

5.1.10 OPTIONS

The root OPTIONS method allows the client to discover the level of this namespace is determined
versioning support provided by examining
the OPTIONS extended reply. All configurations names MUST be
unique on a server. Using

The following defines the configuration namespace, clients can
create and manage configurations.

Clients create BNF for the Versioning header:

5.2 New Methods

WebDAV versioning introduces two new configurations by issuing methods, MKRESOURCE and
REPORT, that are not specific to versioning but are needed to
support the MKCONFIG versioning extensions.

5.2.1 MKRESOURCE

The MKRESOURCE method
against the configuration namespace. This requests the server to
create a new configuration.

When simultaneous creation of a configuration is created, special tags can be used to define
resource, identified by the characteristics Request URI, and relationships (e.g. derivations) for the
configuration. The following table enumerates these tags.

Tag Description

<DAV:configurationtype> This tag defines initialization of its
properties. Creation of the type resource and initialization of configuration:
xxx DAV:Dynamic its
properties MUST both occur, or
</DAV:configurationtype> DAV:Workspace.

<DAV:derivedfrom> This tag allows neither occurs. The request message
body of the client
"xxx" to specify a URI to
</DAV:derivedfrom> identify another
configuration from which
this new configuration MKRESOURCE method is
to be derived.

<DAV:inheritancetype> The configuration
automatically inherits
DAV:Auto changes from its derived-
</DAV:inheritancetype> from configuration.
Conflicts are recorded the same as for the PROPPATCH
method, i.e. it MUST contain the DAV:propertyupdate XML element,
defined in
resolution queues (see
later section).

<DAV:inheritancetype> section 12.13 of [RFC2518]. The configuration inherits
changes from its derived-
DAV:Manual from configuration, but
</DAV:inheritancetype> they are not automatically
inserted into the
configuration. Instead
they are recorded property update
directives in
resolution queues (see
Tag Description

later section).

<DAV:inheritancetype>
snapshot the request message body provide the initial values
of the current
DAV:None versions in properties of the derived-
DAV:inheritancetype> from configuration. There new resource. The configuration is a
is no inheritance type of
changes. This is the
default type if no type is
specified.

<DAV:basetime>"xxx" The configuration created
resource is based
</DAV:basetime> on specified by the current versions in DAV:resourcetype property, if present.
If the derived-from
configuration at DAV:resourcetype property is not specified, the
indicated time. Note that
use of this tag created
resource is
incompatible with DAV:Auto
inheritance types and
usage in this way MUST
return an error.

When a non-derived configuration is created, it contains no
resources. Configurations that are derived from another
configuration include the resources ordinary (i.e. untyped) resource. Like PROPPATCH,
instruction processing MUST occur in the derived order instructions are
received (i.e. from
configuration at the specified time top to bottom). Instructions MUST all be
executed, or using the default revisions.

The example below illustrates creating a new configuration none executed. If MKRESOURCE is applied to an
existing resource, that resource is
derived from, and auto-inherits another configuration. For this
example, the root deleted prior to MKRESOURCE
processing. The behavior of MKRESOURCE on an existing resource can
be explicitly controlled through use of the configuration namespace has been
determined to Overwrite header.

MKRESOURCE can be /cfgs.

>>Request

MKCONFIG /cfgs/ HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:createconfiguration xmlns:D="DAV:">
<D:configurationtype>DAV:Workspace</D:configurationtype>

<D:derivedfrom>http://www.foobar.com/cfgs/DDEJRJ445</D:derivedfrom>
<D:inherit>Auto</D:inherit>
</D:createconfiguration>

>>Response

HTTP/1.1 201 Created
Location: http://www.foobar.com/cfgs/RYURUS99009
Content-Length: 0

6.3. Access Using Configurations

Configurations are maintained as used to create a special new activity in a repository
DAV:activities collection.
Configurations maintain referential members When MKRESOURCE is used to all revisions that
are part 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 configuration. Consequently, one approach to
enumerating the contents creation
of a configuration the resource, this response is to generated. Status codes defined
for use PROPFIND with PROPPATCH (defined in section 8.2.1 of [RFC2518])
SHOULD be used to
discover represent error cases in setting the contents value of the collection.

Alternatively, clients can request a specific
properties.

TBD - Explain effect on existing resource from types

TBD - Give request/response example

5.2.2 REPORT

The REPORT request is an extensible mechanism for obtaining
information about a
configuration. resource. This approach allows clients to use differs from OPTIONS because
the URL they
are familiar with. If a client requests a resource that information is not
part of a configuration, then an error static. That is, it is returned.

>>Request

GET /foo/bar.htm HTTP/1.1
Host: www.foobar.com
Configuration-Id: /cfgs/DFEE2034
Content-Length: 0

6.4. Deleting Configurations

To delete typically a configuration, use the location returned from the
configuration creation. Note that configurations SHOULD NOT allow
delete if other configurations are derived from them.

>>Request

DELETE /cfgs/RYURUS99009 HTTP/1.1
Host: www.foobar.com
Content-Length: 0

6.5. Resolution Queues

There are times when an operation cannot be blocked report
that will
result requires server processing in a state order to generate.

The REPORT method takes an XML body document that requires user action. For example, when
configurations inherit, there specifies the
type of report. If no report is requested, the potential for conflicts.
Resolution queues provide a mechanism for discovering these
conditions.

Configurations track and maintain method returns a
list of issues that need 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
resolved as a result of actions. These lists are referred applied to as
resolution queues. Clients can a versioned resource.
When a CHECKOUT request the resolution issues and
react accordingly. The configuration will continue is applied to report the
condition until it a versioned resource whose
target is resolved.

The resolution queue a revision, a new working resource is created that is obtained by obtaining the
DAV:resolutionqueue property from the configuration. This property
contains all of the identified issues.

>>Request

PROPFIND /cfgs/FDJE4949 HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:resolutionqueue/>
</D:prop>
</D:propfind>

>>Response

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foobar.com/cfgs/FDJE4949</D:href>
<D:propstat>
<D:prop>
<D:resolutionqueue>
<D:resolutionitem xmlns:D="DAV:">
<D:resolutiontype><D:conflict/></D:resolutiontype>
<D:resource>http:/foo/bar.htm</D:resource>
<D:newversion>DAV:FDFEE55544</D:newversion>
</D:resolutionitem>
</D:resolutionqueue>
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>

Once a client has resolved an issue it will automatically be
removed from
copy of the resolution queue.

6.6. Configuration Properties

The standard PROPFIND revision, and PROPPATCH methods can be used on the
configuration DAV:predecessor of the working
resource to get and is set properties on a
configuration. Configurations MUST provide configuration
properties if configurations are supported. The following list
identifies pre-defined properties that MUST to be supported:

DAV:configurationtype - The type of that revision. If the configuration.
Configurations can choose to make this DAV:predecessor has a read-only property.

DAV:derivedfrom - The configuration from which the configuration
DAV:single-checkout property and is
derived. Configurations can choose to make this already checked out into a read-only
property.

DAV:inheritancetype -
workspace, the CHECKOUT request fails. The type DAV:workspace of inheritance for the
configuration. Configurations can choose to make this a read-only
property.

DAV:basetime - The base time used
working resource is set to create be the configuration.
Configurations can choose to make this a read-only property.

DAV:defaultconfiguration - This property on workspace specified in the configuration root
identifies
Target-Selector header. If the default Target-Selector is not a workspace configuration to use
or if one there is not
specified.

DAV:resolutionqueue - A list of identified issues that require
client attention.

6.7. Headers

To support configurations, two new headers are introduced 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 with a variety to initialize the DAV:checkin-policy
of the DAV and HTTP methods. The following
list identifies these headers:

Configuration-Id - This header working resource.

When a CHECKOUT request is used applied to identify a versioned resource whose
target is a working resource, the
configuration that CHECKOUT request MUST fail.

On CHECKOUT, the DAV:activity of the new working resource is set to
be used when performing an operation.

For workspace configurations, this can be specified to set default
revisions per-configuration, enumeration the DAV:activity of checkouts/checkins
against the current workspace. If DAV:activity is
not set, a specific configuration, or server with activity support automatically assigns an
activity to establish locks specific 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 configuration.

If a configuration versioned resource whose
target is not specified, a working resource, a copy of the default workspace
configuration working resource is used. All servers have
made a default workspace where
resources reside. new revision of that versioned resource and the working
resource is deleted. The configuration "*" can be specified with
PROPFIND new revision is added to locate properties irrespective the
DAV:successors collection of configuration.

Configuration-Id := "Configuration-Id" ":" (URL | "*")

Note that the configuration id can be used in place DAV:predecessor of a revision
id. In this case, the revision selected is new
revision, and the default revision workspace of the versioned working resource within the specified configuration.

Target-Configuration - This header is used to specify deleted from
the DAV:working-resources collection of the DAV:predecessor.

The body of a target
configuration when dealing with cross-configuration operations.
For example, resources CHECKIN request can be copied from one configuration used to
another using override the Configuration-Id and Target-Configuration headers
with current
DAV:checkin-policy values of the COPY method. Note that resources CANNOT be MOVEd from one
configuration to another.

Target-Configuration := "Target-Configuration" ":" URL

7. CONFIGURATION REPORTS

Revision history and configuration dependency graphs are accessed
via PROPFIND. Note that configurations MAY support multiple styles working resource. The effect of history and dependency. To enumerate
DAV:checkin-policy on a CHECKIN request is described in the supported history
graphs, clients use PROPFIND and
definition of the <DAV:availablereports> DAV:checkin-policy property. The results indicate the different graphs and reports,
which can, themselves, be requested via PROPFIND.

>>Request

PROPFIND /cfgs/FHJRH3994 HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:enumreport/>
</D:prop>
</D:propfind>

>>Response

...
<D:multistatus>
<D:response>
<D:href>http://www.foobar.com/cfgs/FHJRH3994</D:href>
<D:propstat>
<D:prop>
<D:enumreport>
<D:report>DAV:configurationderivation</D:report>
<D:report>DAV:configurationmerge</D:report>
</D:enumreport>
</D:prop>
</D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
...

When clients issue PROPFIND requests the CHECKIN method is applied to obtain reports, they may
include other properties in a resource that is
versionable, but not currently versioned, the request. These properties resource is put under
version control. If a versionable collection is put under version
control, all members of that collection are
returned for each report item.

7.1. Configuration Derivation

Configurations MUST support the DAV:configurationderivation report.
This enumerates 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 full derivation DAV:workspace of a configuraiton. Note that working
resource is deleted from the limit parameter can be specified to limit the number DAV:working-resources collection of items
returned. By definition
the order DAV:revision of the configurations is
immediate predecessor.

>>Request

PROPFIND /cfgs/BHFR59593 HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:configurationderivation limit=100/>
</D:propfind>

>>Response

...
<D:multistatus>
<D:response>
<D:href>http:/www.foobar.com/cfgs/234</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http:/www.foobar.com/cfgs/345</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
...

7.2. Configuration Merge Graph

Configurations SHOULD support working resource, and the DAV:configurationmerge report. working resource
is deleted. This enumerates effectively cancels the derivation of a configuration including merges
from one configuration to another.

>>Request

PROPFIND /cfgs/BHFR59593 HTTP/1.1
Host: www.foobar.com
Depth: 0
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:configurationmerge/>
</D:propfind>

>>Response

...

<D:multistatus>
<D:response>
<D:href>http:/www.foobar.com/cfgs/234</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http:/www.foobar.com/cfgs/3FF</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
...

8. DYNAMIC CONFIGURATIONS

Dynamic configurations provide a mechanism to identify all
revisions that match specific criteria. For example, "all
revisions CHECKOUT request that have
produced the label Beta1". 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 dynamic configuration is Target-Selector header contains a view onto the resources and workspace URL or a revision
name. The Target-Selector header is updated automatically as resources
and revisions are created, deleted, and modified.

All dynamic configurations support the DAV:rsrtypes property. This
identifies the different styles of dynamic configurations used to specify which working
resource or revision of a versioned resource should be
supported. This specification defines its target.
If a single common type,
DAV:basicrsr.

>>Request

PROPFIND /cfgs/FHHE49495 HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:rsrtypes/>
</D:prop>
</D:propfind>

>>Response

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foobar.com/cfgs/FHHE49495</D:href>
<D:propstat>
<D:prop>
<D:rsrtypes>
<D:basicrsr/>
</D:rsrtypes>
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>

Clients establish Target-Selector header is omitted in a selection criteria by setting the
DAV:selectionrule property. Once set, the dynamic configuration
collection contains references to the matching resources.

>>Request

PROPPATCH /cfgs/FHHE49495 HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<D:selectionrule>
<D:basicdynamicconfig>
...
</D:basicdynamicconfig>
</D:selectionrule>
</D:prop>
</D:set>
</D:propertyupdate>

The DAV:basicrsr tag groups request on a versioned
resource, the selection criteria that are default workspace is implicitly used to
populate as the dynamic configuration. The Target-
Selector.

6 THE DAV VERSIONING XML ELEMENTS

6.1 Revision Selection Rule Elements

A revision selection criteria rule document is
specified as a set the value of tags where nesting represents the
expressional ordering. The following tags are available:

- DAV:and - The included tags MUST all
DAV:revision-selection-rule property of a workspace.
Semantically, a revision selection rule (or RSR) element can be true
applied to an arbitrary versioned resource, and will either select

- DAV:or - Any
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 included tags MUST be true to select

- DAV:not - The include tag should be inverted (logically)

- DAV:href - The resource URL MUST
conflicts can be obtained through a conflict REPORT request.

6.1.1 DAV:rsr-configuration

A DAV:rsr-configuration element contains the included URL

- DAV:label - A of a
configuration. If the configuration contains a revision MUST have of the specified label

- DAV:tip - The "tip"
versioned resource, that revision is selected

- DAV:revisionid - The specified by the DAV:rsr-
configuration element; otherwise, no revision is selected

- DAV:configurationid - The configuration MUST be 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 specified
value

- DAV:branchid - The branch MUST be URL of an activity.
If the specified value

- DAV:depth - Used with DAV:href to indicate a recursive match
TBD - provide full DTD

The following example illustrates a selection rule that includes
all DAV:revisions collection of the activity contains one or
more revisions in of the /Foo/Bar folder (and below) versioned resource, then the latest revision
in that have been
labeled as "Beta1".

<?xml version="1.0" encoding="utf-8" ?>
<D:basicrsr xmlns:D="DAV:">
<D:and>

<D:href>http:/www.foobar.com/Foo/Bar/<D:depth>infinity</D:depth><
/D:href>
<D:label>Beta1</D:label>
</D:and>
</D:basicrsr>

9. WORKSPACE CONFIGURATIONS

Branching provides activity is selected. The semantics of activities ensures
that there always is a mechanism unique latest revision for parallel changes to an activity. If
the activity contains no revisions of a versioned resource, the
DAV:rsr-activity-latest element selects no revisions of that
versioned resource.
A workspace configuration

If the DAV:needed-activities collection of an activity is non-
empty, then the DAV:rsr-activity element acts like a mechanism for parallel changes of
multiple resources.

For example, /MySite/ might contain all DAV:rsr-merge
element that contains that activity and each of the Web pages for V1 of
my companies e-commerce site. These have been put in DAV:needed-
activities. A DAV:rsr-activity-latest element can generate
conflicts only if the V1
workspace. DAV:needed-activities collection is non-
empty.

6.1.3 DAV:rsr-label

A team responsible for developing V2 DAV:rsr-label element contains a label. If a revision of the site would
create a new workspace configuration based on V1. The V2 workspace
versioned resource has that label, that revision is populated with selected by the V1 versions, but these resources can be
versioned independently. Essentially all resources have been
"branched" in a coordinated fashion. Since this
DAV:rsr-label element; otherwise, no revision is selected. A
DAV:rsr-label element never generates a branch, both conflict.

6.1.4 DAV:rsr-revision-id

A DAV:rsr-revision-id element contains a revision id. If a
revision of the V1 and versioned resource has that revision id, that
revision is selected by the V2 revisions refer to 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 same revision of that versioned resource.
This allows history and reports to be generated across workspaces.

9.1. Managing Configuration Content

Clients need to be able to access and manage
resource with the contents 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
configuration. This DAV:rsr-or element is done using several different DAV methods.

The COPY method can be used identical to copy the behavior of
the first element in this sequence that selects a specific revision of the
versioned resource. If no element selects a revision, then the
DAV:rsr-or element selects no revision of that versioned resource. However, this results

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 new versioned resource being
created.

Resources are added to and removed from workspace configurations
using revision that is the MKREF and DELREF methods defined by
descendent of all of the DAV Advanced
Collections Working Group. Note other revisions selected by elements in
this sequence, then that direct references are
required.

Clients can obtain revision is selected by the contents of DAV:rsr-merge
element. If no selected revision is a configuration using PROPFIND
to enumerate descendent of all the hierarchy under other
selected revisions, then the configuation's collection. As
well, as stated above, clients can use result of the Configuration-Id header
as described previously.

9.2. Default Workspace Configurations

Clients can establish a default workspace configuration that DAV:rsr-merge is to
be used, for all clients, if they do not specify a workspace
configuration. To do this, use the SETDEFAULT method against the
configuration root identifying
"conflict". A conflicts REPORT request can be used to identify the default configuration.

>>Request

SETDEFAULT /cfgs/ HTTP/1.1
Host: www.foobar.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:setdefault xmlns:D="DAV:">
<D:href>http://www.foobar.com/cfgs/CHFH49594/</D:href>
</D:setdefault>

>>Response

HTTP/1.1 200 OK
Content-Length: 0

10. CHECKIN SETS

Clients may desire
conflicts.

6.2 Report Elements

6.2.1 Conflicts Report

A conflicts report describes the ability to track a set of changes as conflicts in a unit.
That is, create specified workspace
for a grouping of related changes. This is achieved
using specified resource or for all the MKCHECKINSET method to create members of a special specified
versioned collection.
Clients refer to

6.2.1.1 DAV:conflicts-report-request

A DAV:conflicts-report-request contains the checkin set on all checkin (or change)
requests. The server automatically creates URL of a "share" to 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 newly
created revision selection rule
specified in the identified collection.

Checkin sets are specific to DAV:conflicts-report-request produced a configuration and are created using
the MKCHECKINSET method. conflict.
The DAV:checkinsetroot property on DAV:conflict element identifies the versioned resource which
generated a
configuration specifies 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 collection where checkin sets versioned resource
for which the configuration exist. This can be used for discovery or
creation. If revision selection rule generated a configuration doesn't support checkin sets, then
this property will be empty.

Clients create checkin sets using MKCHECKINSET. The response
includes conflict, a
DAV:common-ancestor for the location of conflict, and two or more
DAV:contributor elements for the new checkin set.

>>Request

MKCHECKINSET /cs/244 HTTP/1.1
Host: www.foobar.com
Content-Length: 0

>>Response

HTTP/1.1 201 CREATED
Host: www.foobar.com
Location: http://www.foobar.com/cs/244
Content-Length: 0 conflict.

6.2.1.4 DAV:common-ancestor

The following example illustrates use DAV:common-ancestor element identifies a revision that is a
common ancestor of checkin sets.

>>Request

CHECKIN /foo/bar HTTP/1.1
Host: www.foobar.com
Lock-Token: <opaquelocktoken:rejrei-43343-rereffre>
Checkin-Set: /cs/244
Content-Type: text/html
Content-Length: xxxx

<D:checkin>
...
</D:checkin>

The following properties MUST be supported on all checkin set
collections:

DAV:closed - This is the DAV:contributor elements for a true (1) / false (0) property that indicates
if this checkin set can be referenced in CHECKIN requests. When
particular conflict.

6.2.1.5 DAV:contributor

The DAV:contributor element identifies a
checkin set is created, this property revision that is defaulted to 0. Note 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 MAY choose to disallow clients from setting this property
to 0 once a client has set it of
the same type.

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 1. two
configuration revisions. The following properties MUST be supported on all resources:

DAV:checkinid - This read-only property returns DAV:compare-report-response contains
the checkin id
associated with this revisions, needed-configurations, and activities that are
selected by one configuration revision of but not the resource. other.

6.2.2.3 DAV:added

A checkin DAV:added element identifies something that references a checkin set MUST be made to appears in the
configuration associated with second
resource but not in the checkin set.

11. VERSION MAPPING

This specification defines headers to specify configurations and first.

6.2.2.4 DAV:deleted

A DAV:deleted element identifies something that appears in the
first resource versions. However, there are times 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 clients require two configurations are being compared, a
single URI for when working against
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 versions.
Version mapping support allows servers to create namespaces different baselines of that
map to versioned
collection. An activity has changed if both configurations and versions.

Note
contain that mappings are dynamic. That is, as resources are added,
removed, and modified, activity but the changes are reflected in any active
maps. DAV:revisions or DAV:needed-
activities of that activity were different when those
configurations were created.

7 INTERNATIONALIZATION CONSIDERATIONS

To delete be supplied.

NOTE: If a mapping, use DELETE against the URI specified revision label contains a URL reserved character, that
character is escaped in the
MKMAP request.

11.1. Discovery

Mapping support is optional and support is discovered using OPTIONS DAV:revision-labels name.

8 SECURITY CONSIDERATIONS

To be supplied.

9 SCALABILITY

To be supplied.

10 AUTHENTICATION

Authentication mechanisms defined in WebDAV will also apply to verify if the MKMAP method is supported. Using DAV
Versioning.

11 IANA CONSIDERATIONS

This document uses the request body 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 DAV:verinfo tag, clients can obtain position of the supported map
styles.

This example shows that IETF concerning
intellectual property claims made against this document.

The IETF takes no position regarding the /cfgs/DFEE2034 configuration supports
mapping validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the /map/ root implementation or use other technology described in
this document or the namespace.

>> Request

OPTIONS /cfgs/DFEE2034 HTTP/1.1
Host: foobar.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo/>
</D:options>

>> Response

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:verinfo>
<D:mapstyles>
<D:mapstyle>DAV:detailedmap </D:mapstyle>
<D:mapstyle>DAV:branchmap </D:mapstyle>
<D:mapstyle>DAV:nestedbranch </D:mapstyle>
</D:mapstyles>
</D:verinfo>
</D:options>
11.2. Mapping Configurations

The MKMAP method is used to create namespaces based on a
configuration. When a configuration is mapped extent to a new namespace,
all elements within the configuration can which any license under such rights
might or might not be directly accessed
within the namespace without requiring available; neither does it represent that it
has made any effort to identify any such rights. Information on
the configuration IETF's procedures with respect to rights in standards-track and
standards-related documentation can be
identified found in the header.

In the example below, a new namespace is created BCP-11. Copies of
claims of rights made available for accessing the
contents publication and any assurances
of the /cfgs/DFEE2034 configuration.

>> Request

MKMAP /maps/mymap HTTP/1.1
Host: foobar.com
Configuration-Id: /cfgs/DFEE2034
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:configurationmap xmlns:D="DAV:"/>

>> Response

HTTP/1.1 201 CREATED
Context-Length: 0

11.3. Mapping Resource Versions

The MKMAP method is also used licenses to create namespaces based on a
resource's versions (i.e., its revision graph). When a resource is
mapped, its revision history (revision graph) within the
configuration is be made available without requiring the Revision-Id
header. Within available, or the mapped namespace, result of an attempt made
to obtain a hierarchy is created general license or permission for the revisions.

However, there are different ways to map the history. Consider the
following revision history use of such
proprietary rights by implementers or users of this specification
can be obtained from the versioned resource bar.htm:

V1 -> V2 -> V3 (primary branch)
|
+-> V1.1 -> V1.2 ("test" branch) IETF Secretariat.

The following diagrams illustrate possible mappings:

(DAV:detailedmap) (DAV:branchmap)
(DAV:nestedbranchmap)

In 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 example below, a new namespace information to the IETF
Executive Director.

13 ACKNOWLEDGEMENTS

This protocol is created for accessing the
versions collaborative product of the /foo/bar.htm resource in the /cfgs/DFEE2034
configuration.

>> Request

MKMAP /maps/mymap2 HTTP/1.1
Host: foobar.com
Configuration-Id: /cfgs/DFEE2034
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:revisionmap xmlns:D="DAV:">
<D:href>/foo/bar.htm</D:href>
<D:mapstyle>DAV:detailedmap</D:mapstyle>
</D:revisionmap>

>> Response

HTTP/1.1 201 CREATED
Context-Length: 0

Note that resources MAY support any mapping styles, however, if
they support MKMAP, then it MUST support DAV:detailedmap as
illustrated above.

12. THE DAV VERSIONING GRAMMAR

To be supplied - Describe 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 detail the DTDs

13. INTERNATIONALIZATION CONSIDERATIONS

To be supplied.

14. SECURITY CONSIDERATIONS

To be supplied.

15. SCALABILITY

To be supplied.

16. AUTHENTICATION

Authentication mechanisms defined in WebDAV will also apply Jim
Whitehead (UCI). We would like to DAV
Versioning.

17. IANA CONSIDERATIONS

This document uses acknowledge the namespace defined by [WebDAV] foundation laid
for XML
elements. All other IANA considerations mentioned in [WebDAV] also
applicable to DAV Versioning.

18. COPYRIGHT

To be supplied.

19. INTELLECTUAL PROPERTY 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.

20.

15 REFERENCES

[DAVVERREQ] TBD, "Requirements for DAV Versioning and Variant
Authoring", October 1998, internet-draft, work-in-progress, draft-
ietf-webdav-versionreqs-00.txt

[Kaler] C. Kaler, "Versioning Extensions for WebDAV", September
1998, internet-draft, work-in-progress, draft-kaler-webdav-
versioning-00.

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

[WebDAV]

[RFC2518] Y. Goland, E.J. Whitehead, A. Faizi, S.R. Carter, D.
Jenson, "Extensions "HTTP Extensions for Distributed Authoring on the World Wide
Web", April. 1998, internet-draft, work-in-progress, draft-ietf-
webdav-protocol-08.

[White] E.J. Whitehead, "A Web Versioning Protocol", June 1998,
internet-draft, work-in-progress, draft-whitehead-webdav-
versioning-00.

21. AUTHOR'S - 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, Editor Kaler
Microsoft
One Microsoft Way
Redmond WA, WA 9085-6933
Email:ckaler@microsoft.com

Jim Amsden
IBM
Email: jamsden@us.ibm.com

Geoff Clemm
Rational
Email: gclemm@atria.com

Bruce Cragun
Novell Inc.
1555 N. Technology Way
Orem, UT 84097
Email: bcragun@novell.com

David Durand
Email: dgd@cs.bu.edu

Bradley Sergeant
MicroFocus
Email: bradley_sergeant@intersolv.com

E. James Whitehead, Jr.
Dept. of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu

22. ckaler@microsoft.com

17 OPEN ISSUES

The following list identifies key open issues against this
document:

. Can you checkout a collection? What does it mean?

. What tags do we want to use for resource/configuration report
results?
. What structure do we create for maps?

. What additional resource branching support is needed?

. Schema discovery is an issue. For example, how

@ TODO: Add the appropriate DAV:resourcetype properties to
discover/change mutable/immutable properties?

. There are several missing
workspace, history resource, activity, and configuration.

@ TODO: Flush out details on methods: e.g., request/response
examples / replies that need needed.

@ TODO: DTDs and semantics of properties

@ TODO: Lots of details

@ ISSUE: How are policies discovered?

@ ISSUE: Does Versioning have to be
specified.

23. CHANGE HISTORY

Sep 28, 1998

Initial Draft based on [White] and [Kaler].

Oct 24, 1998

Incorporate feedback from October 01-02 working group meeting.

Jan 20, 1999

Incorporate feedback from December 1998 working group meeting. 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?