INTERNET-DRAFT                        Geoffrey Clemm, Rational Software
  draft-ietf-deltav-versioning-01.txt   Chris Kaler, Microsoft
  
  Expires April 22, 2000           October 22, 1999
  
                       Versioning Extensions to WebDAV
  
  Status of this Memo
  
  This document is an Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.
  
  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups. Note that other groups
  may also distribute working documents as Internet-Drafts.
  
  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet- Drafts as reference material
  or to cite them other than as "work in progress."
  
  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt
  
  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.
  
  Abstract
  
  This document specifies a set of methods, headers, and resource-types
  that define the WebDAV Versioning extensions to the HTTP/1.1 protocol.
  WebDAV Versioning will minimize the complexity of clients so as to
  facilitate widespread deployment of applications capable of utilizing
  the WebDAV Versioning services. WebDAV Versioning includes:
  
       - Basic versioning with automatic versioning for versioning-unaware
          clients,
  
       - Activity and configuration management ,
  
       - URL namespace versioning.
  
  Clemm, Kaler                                        [Page 1]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  Table of Contents
  
  VERSIONING EXTENSIONS TO WEBDAV...........................1
  
  STATUS OF THIS MEMO.......................................1
  
  ABSTRACT..................................................1
  
  TABLE OF CONTENTS.........................................2
  
  1 INTRODUCTION...........................................5
  1.1  Relationship to DAV.................................5
  1.2  Terms...............................................5
  1.3  Notational Conventions.............................11
  
  2 WEBDAV VERSIONING SEMANTICS...........................11
  2.1  Creating Versioned Resources.......................11
  2.2  Modifying a Versioned Resource.....................11
  2.3  Naming Revisions: Revision Ids and Revision Labels.12
  2.4  Revision Selection and Workspaces..................13
  2.5  Parallel Development and Activities <Activity>.....13
  2.6  Configurations <Activity>..........................14
  2.7  Versioned Collections <Versioned-Collection>.......14
  2.8  Repositories <Versioned-Collection>................15
  
  3 VERSIONING PROPERTIES BY RESOURCE TYPE................15
  3.1  Property Characteristics...........................15
   3.1.1 Writeable/Readonly Properties....................15
   3.1.2 Mutable Properties...............................15
   3.1.3 Property Resources...............................15
  3.2  Common Property Values.............................16
   3.2.1 boolean Syntax...................................16
   3.2.2 segment Syntax...................................16
   3.2.3 date-time Syntax.................................16
   3.2.4 href XML Element.................................16
  3.3  Resource Properties................................16
   3.3.1 DAV:author.......................................16
   3.3.2 DAV:comment......................................16
  3.4  Versioned Resource Properties......................16
   3.4.1 DAV:versioned-resource-id (readonly).............17
   3.4.2 DAV:default-workspace (readonly, resource).......17
   3.4.3 DAV:revisions (readonly, collection).............17
   3.4.4 DAV:labeled-revisions (collection)...............17
   3.4.5 DAV:single-checkout..............................17
   3.4.6 DAV:auto-version.................................17
   3.4.7 DAV:baselines (readonly, collection)
         <Versioned-Collection>...........................18
   3.4.8 DAV:repository (readonly, resource)
         <Versioned-Collection>...........................18
  3.5  Revision Properties................................18
   3.5.1 DAV:revision-id (readonly).......................18
   3.5.2 DAV:predecessor (readonly, resource).............18
   3.5.3 DAV:successors (readonly, mutable, collection)...19
   3.5.4 DAV:labels (readonly, mutable)...................19
   3.5.5 DAV:checkin-date (readonly)......................19
  
  Clemm, Kaler                                        [Page 2]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
   3.5.6 DAV:workspaces (readonly, collection)............19
   3.5.7 DAV:versioned-resource (readonly, resource)......19
   3.5.8 DAV:activity (readonly, resource) <Activity>.....19
   3.5.9 DAV:merge-predecessors (mutable, collection)
         <Activity>.......................................20
   3.5.10DAV:merge-successors (mutable, collection)
         <Activity>.......................................20
  3.6  Working Resource Properties........................20
   3.6.1 DAV:predecessor (read-only, resource)............20
   3.6.2 DAV:checkin-policy...............................20
   3.6.3 DAV:merge-predecessors (collection) <Activity>...21
   3.6.4 DAV:activity (readonly, resource) <Activity>.....21
  3.7  Workspace Properties...............................21
   3.7.1 DAV:working-resources (readonly, collection).....21
   3.7.2 DAV:revision-selection-rule......................21
   3.7.3 DAV:no-checkout..................................23
   3.7.4 DAV:current-label................................23
   3.7.5 DAV:current-activity (resource) <Activity>.......23
  3.8  Activity Properties <Activity>.....................24
   3.8.1 DAV:revisions (readonly, collection).............24
   3.8.2 DAV:required-activities (collection).............24
   3.8.3 DAV:workspaces (readonly, collection)............24
  3.9  Baseline Properties <Versioned-Collection>.........24
   3.9.1 DAV:baseline-id (readonly).......................24
   3.9.2 DAV:predecessor (readonly, resource).............24
   3.9.3 DAV:successors (readonly, mutable, collection)...25
   3.9.4 DAV:versioned-resource (readonly, resource)......25
   3.9.5 DAV:merge-predecessors (mutable, collection).....25
   3.9.6 DAV:merge-successors (mutable, collection).......25
   3.9.7 DAV:activity (readonly, resource)................25
  3.10 Repository Properties <Versioned-Collection>.......25
   3.10.1DAV:versioned-resources (readonly, collection)...25
   3.10.2DAV:root-versioned-collection (readonly, resource)26
   3.10.3DAV:activities (collection)......................26
   3.10.4DAV:configurations (collection)..................26
   3.10.5DAV:workspaces (collection)......................26
   3.10.6DAV:default-workspace (resource).................26
  
  4 EXISTING METHODS......................................26
  4.1  GET................................................27
  4.2  PUT................................................27
  4.3  PROPFIND...........................................27
  4.4  PROPPATCH..........................................27
  4.5  COPY...............................................28
  4.6  DELETE.............................................28
  4.7  BIND...............................................28
  4.8  MOVE...............................................28
  4.9  LOCK...............................................28
  4.10 UNLOCK.............................................29
  4.11 OPTIONS............................................29
  
  5 NEW METHODS...........................................29
  5.1  MKRESOURCE.........................................29
   5.1.1 New DAV:resourcetype Values......................30
   5.1.2 Example - MKRESOURCE.............................30
  5.2  REPORT.............................................31
  
  Clemm, Kaler                                        [Page 3]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
   5.2.1 DAV:report-request...............................32
   5.2.2 DAV:report-response..............................32
  5.3  Available REPORT...................................32
   5.3.1 DAV:available-report-request.....................32
   5.3.2 DAV:available-report-response....................32
   5.3.3 Example - Available REPORT.......................32
  5.4  Conflict REPORT....................................33
   5.4.1 DAV:conflict-report-request......................33
   5.4.2 DAV:conflict-report-response.....................33
   5.4.3 DAV:conflict.....................................34
   5.4.4 DAV:common-ancestor..............................34
   5.4.5 DAV:contributor..................................34
   5.4.6 Example - Conflict REPORT........................34
  5.5  Compare REPORT.....................................35
   5.5.1 DAV:compare-request..............................35
   5.5.2 DAV:compare-response.............................35
   5.5.3 DAV:added........................................35
   5.5.4 DAV:deleted......................................36
   5.5.5 DAV:changed......................................36
   5.5.6 Example - Compare REPORT.........................36
  
  6 NEW VERSIONING METHODS................................37
  6.1  CHECKOUT...........................................37
   6.1.1 Example - CHECKOUT...............................38
  6.2  CHECKIN............................................39
   6.2.1 Example - CHECKIN................................40
  
  7 NEW VERSIONING HEADERS................................41
  7.1  Target-Selector....................................41
  
  8 INTERNATIONALIZATION CONSIDERATIONS...................42
  
  9 SECURITY CONSIDERATIONS...............................42
  
  10  SCALABILITY..........................................42
  
  11  AUTHENTICATION.......................................42
  
  12  IANA CONSIDERATIONS..................................42
  
  13  INTELLECTUAL PROPERTY................................42
  
  14  ACKNOWLEDGEMENTS.....................................43
  
  15  INDEX................................................43
  
  16  REFERENCES...........................................43
  
  17  AUTHORS' ADDRESSES...................................43
  
  18  OPEN ISSUES..........................................44
  
  Clemm, Kaler                                        [Page 4]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  1  INTRODUCTION
  
       This document defines WebDAV Versioning extensions, an application
       of HTTP/1.1 for handling resource versioning in a WebDAV
       environment.  [Goals] describes the motivation and requirements for
       WebDAV Versioning.
  
       WebDAV Versioning will minimize the complexity of clients so as to
       facilitate widespread deployment of applications capable of
       utilizing the WebDAV services.  WebDAV Versioning defines three
       levels of versioning functionality for versioning-aware clients:
  
       - Basic versioning with automatic versioning for versioning-unaware
          clients,
  
       - Activity and configuration management ,
  
       - URL namespace versioning.
  
  1.1 Relationship to DAV
  
       To maximize interoperability and the use of existing protocol
       functionality, versioning support is designed as extensions to the
       WebDAV [RFC2518] and Binding protocols [Binding].  In particular,
       WebDAV Versioning relies on the resource and property model defined
       by [RFC2518] and the binding model defined by [Binding].  The
       versioning protocol is designed so that WebDAV LOCK/UNLOCK requests
       can be mapped into versioning CHECKOUT/CHECKIN requests.  This
       provides interoperability between locking clients and versioning
       servers.
  
       This protocol defines three levels of versioning support: Core,
       Activity, and Versioned-Collection support.  Core support provides
       versioning of largely independent resources.  It allows authors to
       concurrently create and access distinct revisions of a resource.
       Activity support extends Core support with logical change tracking
       and configuration management.  Versioned-Collection support extends
       Activity support with the ability to version the URL namespace.
       Throughout this specification, the notations <Activity> and
       <Versioned-Collection> indicate concepts that are introduced by
       Activity and Versioned-Collection, respectively. The level of
       versioning support provided by a server can be discovered via an
       OPTIONS request.
  
  1.2 Terms
  
       This draft uses the terms defined in [RFC2068] and [RFC2518].  In
       addition, the following terms are defined:
  
     Versionable Resource
  
       A versionable resource is a resource that can be placed under
       version control.
  
     Versioned Resource
  
  Clemm, Kaler                                        [Page 5]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       A versioned resource is a resource that is under version control.
       A versioned resource tracks the history of its significant states,
       called revisions of that versioned resource.  To update a resource
       under version control, it must be checked out and then subsequently
       checked in.
  
     Revision
  
       A revision of a versioned resource is created by a CHECKIN
       operation, and captures the current state of the versioned
       resource.
  
     Mutable Property
  
       A mutable property is a property of a revision that can be changed
       without checking out that revision.
  
     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.
  
  Clemm, Kaler                                      [Page 5.1]
  
  INTERNET-DRAFT       WebDAV Versioning     October 20, 1999
  
     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  ----> "stable" | V1 |       |           |
                 \              +----+       |           |
                  \                |         |           |
                   \               v         |           |
                    \           +----+       | Line      |
                     -> "beta1" | V2 |       | of        |
                                +----+       | Descent   |
                               /   |         | to        |
                              v    v         | V6        |
                         +----+ +----+       |           |
         Revision Id --> | V3 | | V4 |       |           | History
                         +----+ +----+       |           | of
                      ^     |      |         |           | Foo.htm
         Predecessor  |     v      v         |           |
                      |  +----+ +----+       v           |
                         | V5 | | V6 |                   |
                         +----+ +----+                   |
                      |            |                     |
         Successor    |            v                     |
                      v         +----+                   |
                                | V7 |                   |
                                +----+                  /
  
  Clemm, Kaler                                        [Page 6]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
     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 |
                      |    +----+     |    +----+
  
     Working Resource
  
       A working resource is an editable resource created by checking out
       a revision of a versioned resource.
  
  Clemm, Kaler                                        [Page 7]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
     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 |
                         +----+
  
     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.
  
     Target
  
       Whenever a server encounters a versioned resource while it is
       processing an HTTP request, it is required to act on the "target"
       of the versioned resource, rather than the versioned resource
       itself.  Target selection is performed based on the value of the
       Target-Selector header of the request.  Commonly, the Target-
       Selector header specifies a workspace that selects a working
       resource or revision of the versioned resource to be the target.  A
       special Target-Selector value can be specified to select the
       versioned resource itself to be the target.  If no Target-Selector
       header is specified, the default workspace of the versioned
       resource is used to determine target selection.
  
  Clemm, Kaler                                        [Page 8]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
     Default Target
  
       The "default target" of a versioned resource is the target selected
       by the default workspace.
  
     Activity <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 |
                              |     +----+
  
     Merge Predecessor, Merge Successor <Activity>
  
       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.
  
     Conflict Report <Activity>
  
       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
  
  Clemm, Kaler                                        [Page 9]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       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.
  
     Configuration <Activity>
  
       A configuration is a type of collection that contains a set of
       revisions, with a most one revision from any versioned resource.
       Unlike a workspace, which can select both working resources and
       revisions, a configuration can only select revisions.  Also, while
       the revision selected by a workspace for a versioned resource can
       change as a result of a change to the versioned resource (such as
       adding a label), the revision selected by a configuration can
       change only by explicitly modifying the configuration. Unlike an
       activity, a configuration can contain at most one revision 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 <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 MUST be versioned resources.  The
       working resource that results from checking out a versioned
       collection is called a working collection.
  
     Baseline <Versioned-Collection>
  
       A baseline is a "deep revision" of a versioned collection, where a
       deep revision captures not only the revision of the versioned
       collection, but also the revision of every members of that
       versioned collection selected by that workspace at that moment.
       More formally, a baseline contains a revision of the versioned
  
  Clemm, Kaler                                       [Page 10]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       collection and a revision or baseline of every member of every
       versioned collection revision in that baseline.
  
       Like a configuration, a baseline selects a particular revision for
       each of a set of versioned resources.  Unlike a configuration, a
       baseline cannot be modified once it has been created, and may only
       contain exactly those revisions needed to form a deep revision of a
       particular versioned collection.
  
     Repository <Versioned-Collection>
  
       A repository is a type of resource that contains related versioned
       resources, activities, and configurations.  A repository provides a
       stable namespace for versioning metadata resources, and provides
       versioning unaware clients access to the versioning metadata.
  
  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  WEBDAV VERSIONING SEMANTICS
  
  2.1 Creating Versioned Resources
  
       A resource may or may not be versioned. When a resource is created
       in an unversioned collection by a PUT or MKRESOURCE request, it is
       created as an unversioned resource. When a resource is created in a
       versioned collection by a PUT or MKRESOURCE request, it is created
       as a versioned resource.  Some unversioned resources can be put
       under version control; these are called versionable resources.  A
       versionable resource can be put under version control with a
       CHECKOUT operation, and an initial revision is created that is a
       copy of the versionable resource.
  
  2.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 always identified by the
       workspace that contains it.  A working resource is a modifiable
       copy of the revision, and is identical to an unversioned resource
       in all respects other than that it is associated with a particular
       revision of a particular versioned resource. It may be edited by
       setting its properties or contents any number of times. When the
       author is satisfied that the working resource is in a state that
  
  Clemm, Kaler                                       [Page 11]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       should be retained in the versioned resource history, the author
       checks in the working resource to create a new revision of the
       versioned resource.  The revision that was checked out is the
       predecessor of the new revision.
  
       The use of checkout/checkin and working resources to update a
       versioned resource addresses the lost update problem by ensuring
       that each author is updating his or her own working resource rather
       than a shared resource, and by ensuring that the predecessor of the
       updated resource is reliably tracked. Authors can use
       checkout/checkin to register intent to modify a versioned resource
       similar to the way lock /unlock are used in WebDAV class 2, but the
       underlying semantics are very different. With lock/unlock, work is
       serialized and avoiding lost updates depends on clients using the
       lock/unlock protocol.  With checkout/checkin, work can be performed
       in parallel, and the server prevents lost updates by retaining all
       saved states (revisions) of the resource.  Another distinction is
       that an update to a locked resource is visible to all clients,
       while an update to a checked out resource is only visible to other
       clients after that update is checked in.
  
       A server MAY support mutable revisions. Normally, a revision cannot
       be changed and provides a stable environment for history
       management, change recovery, merging, and configuration management.
       A mutable revision is more suitable for situations where versioning
       is treated more informally, and it is not necessary or desirable to
       maintain strict version histories, or to guarantee the possibility
       of backtracking to a previous saved state. If mutable revisions are
       supported, the author may request that a 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 not to support mutable
       revisions.
  
  2.3 Naming Revisions: Revision Ids and Revision Labels
  
       Revision names are used to distinguish a revision of a versioned
       resource from other revisions of that versioned resource.  A
       revision name is either a revision id or any number of revision
       labels. A revision of a versioned resource is given a server
       assigned revision id when it is created. This revision id acts as a
       persistent, immutable identifier distinguishing this revision from
       all others of the same versioned resource. The revision id cannot
       be changed, assigned to another revision, or reused.
  
       A user may assign revision labels to a revision in order to provide
       a more meaningful name for the revision.   A given revision label
       can be assigned to at most one revision of a given versioned
       resource, but may be reassigned to any revision of the versioned
       resource at any time.
  
       A revision name does not distinguish revisions from different
       resources, since the same revision name can be assigned to a
       revision of any versioned resource.
  
  Clemm, Kaler                                       [Page 12]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  2.4 Revision Selection and Workspaces
  
       Resources, working resources, and revisions of versioned resources
       are all accessed using a URL. When a client accesses a versioned
       resource, it is necessary to provide additional information to
       specify which working resource or which revision of the versioned
       resource should be accessed. Specifying the resource URL and a
       revision name can access a specific revision of the versioned
       resource.  However, this requires the user to add and remember
       labels for each revision; it does not provide a way of accessing a
       consistent set of revisions captured by an activity or contained in
       a configuration; it does not enable non-versioning aware clients to
       access revisions; and it does not provide a client with access to a
       working resource of a versioned resource.
  
       To address the restrictions inherent in revision-name based
       revision selection, the revision selected when a specific revision
       name is not specified is resolved through a workspace. A workspace
       is a resource whose primary purpose is to identify working
       resources.  If the workspace contains no working resource for a
       given versioned resource, it can also be used to select an
       appropriate revision of the versioned resource. This allows
       versioned resources and unversioned resources to be accessed
       consistently by both versioning-aware and versioning-unaware
       clients.
  
       In order to specify revision selection, a workspace contains a
       revision selection rule. A revision selection rule can specify
       revision names, activities, configurations, or use operators that
       combine several of these revision selectors. A revision name
       selects a revision with that name. An activity selects the latest
       revision that was created in that activity. Configurations select
       the revision contained in the configuration. The "or" operator
       contains a sequence of rule elements, and applies them in order
       until the first match is found. If there is no matching revision,
       then a resource-not-found status is returned.
  
       If a request is made and no workspace is specified, a server
       determined default workspace is used. This is the workspace used by
       all versioning-unaware clients. A server MAY allow modifications to
       the revision selection rule of the default workspace.
  
  2.5 Parallel Development and Activities <Activity>
  
       In a locking model, when a resource is locked for modifications by
       one author, all other authors are supposed to respect that lock and
       not work on a copy of that resource until the lock has been
       released. To avoid the work serialization inherent in the locking
       model, a versioning model allows multiple authors in different
       workspaces to check out the same revision at the same time, work on
       their respective working resources in parallel, check in their
       respective working resources as soon as their changes are complete,
       and then merge the resulting revisions at some later time.
  
  Clemm, Kaler                                       [Page 13]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       Although a simple versioning model works well for isolated changes
       to independent resources, the required merge process becomes
       unmanageable when sequences of inter-related changes are performed
       on sets of related resources.  To address this merge problem,
       resources can be checked out in the context of an activity. An
       activity captures the set of revisions that form a set of related
       changes an author is making to one or more versioned resources.
       Each activity represents a thread of development, where any thread
       can be isolated from other threads to provide a stable environment
       for parallel work. In case parallel work on isolated activities
       results in branches in the underlying versioned resource histories,
       the activities can be unified through a merge operation.
  
  2.6 Configurations <Activity>
  
       A workspace selects a volatile set of revisions.  Changes to
       selected activities or changes to labels may result in the
       selection of different revisions. A configuration is a resource
       that selects a specific set of  revisions. A workspace whose
       version selection rule contains a configuration will always select
       the same revisions as long as the configuration is not modified and
       no checkouts are performed in that workspace.
  
       Configurations are convenient for defining a persistent set of
       revisions that relate to each other in some specific way at some
       point in time. This can be useful for a variety of purposes such as
       publishing consistent versions of resources to deploy an
       application, or for recovering a specific state for legal or
       maintenance reasons.
  
  2.7 Versioned Collections <Versioned-Collection>
  
       A collection contains a set of named bindings to other resources
       that are the members of that collection. For a versioned
       collection, the bindings are to versioned resources, not to
       particular revisions. To modify the state of a versioned collection
       (i.e. add or remove a binding), the versioned collection must be
       checked out, just like any other versioned resource. Requests that
       modify the state of a collection member, such as checking it out or
       checking in a new revision, have no effect on the state of the
       collection. Conversely, requests that modify the state of a
       versioned collection, such as deleting or adding a binding to a
       resource, have no effect on the state of that resource.  In
       particular, the resource will remain bound in any other revisions
       of the collection of which it was a member.
  
       It is often important to capture the entire tree of revisions
       selected by a workspace rooted at a given versioned collection.
       This "deep revision" of a versioned collection is called a
       baseline.
  
       If a URL identifies a sequence of nested versioned collections,
       revision selection is performed for each versioned collection in
       the sequence, to select the versioned collection revision that will
  
  Clemm, Kaler                                       [Page 14]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       be used to map the next segment of the URL to the appropriate
       versioned resource.
  
  2.8 Repositories <Versioned-Collection>
  
       When the URL namespace is being versioned by means of versioned
       collections, it is important to define a mechanism that provides
       stable names for the versioning metadata resources such as
       versioned resources, revisions, workspaces, activities,
       configurations, and baselines.  In order to support stable names, a
       repository resource MUST be allocated in an unversioned partition
       of the URL namespace.  It is possible to version the root
       collection of a URL authority, but then the repository for the
       versioning metadata must be located at an unversioned partition of
       a different URL authority.
  
  3  VERSIONING PROPERTIES BY RESOURCE TYPE
  
       This section defines the new resource types and properties
       introduced by WebDAV versioning.
  
  3.1 Property Characteristics
  
       There are several important characteristics of properties that will
       be defined for every property introduced by this document.
  
  3.1.1         riteable/Readonly Properties
  
       A writable property can be modified by a client, while a read-only
       property can only be modified by the server.
  
       All properties defined in this document are writable unless
       explicitly marked as "read-only".
  
  3.1.2        Mutable Properties
  
       A mutable property is a property of a revision that can be changed
       without checking out that revision.  A property is mutable only if
       it is explicitly defined in this document as being mutable.
  
  3.1.3        Property Resources
  
       There are various properties whose contents are represented as an
       HTTP resource.  Doing so allows a client to use the full set of
       HTTP methods to manipulate the contents of that property, rather
       than being limited to the functionality provided by PROPFIND and
       PROPPATCH.  This is particularly valuable for a property value that
       is naturally represented as a collection resource.  An alternative
       approach would be to define new methods and headers for browsing
       and updating this information, but the property resource approach
  
  Clemm, Kaler                                       [Page 15]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       has the advantage of providing access to users with versioning
       unaware clients.
  
       All properties that are property resources are explicitly marked as
       "resource".  If the property resource is a collection, the property
       is marked as "collection".
  
  3.2 Common Property Values
  
  3.2.1        boolean Syntax
  
       Some properties take a Boolean value.
  
       boolean = "F" | "T"
  
  3.2.2        segment Syntax
  
       Some properties take a value suitable for use as a segment of a
       URI.  The syntax of a segment is defined in section 3.3 of
       [RFC2396].
  
  3.2.3        date-time Syntax
  
       Some properties take a date or time value.  The syntax of date-time
       is defined in section 23.2 of [RFC2518].
  
  3.2.4        href XML Element
  
       The href XML element is defined in section 12.3 of [RFC2518].
  
  3.3 Resource Properties
  
       WebDAV versioning introduces the following additional properties
       for a resource:
  
  3.3.1         AV:author
  
       This property is used to track the author of a resource.
  
       <!ELEMENT author (#PCDATA)>
  
  3.3.2         AV:comment
  
       This property is used to track a brief comment about a resource.
  
       <!ELEMENT author (#PCDATA)>
  
  3.4 Versioned Resource Properties
  
       WebDAV versioning introduces the following additional properties
       for a versioned resource:
  
  Clemm, Kaler                                       [Page 16]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.4.1        DAV:versioned-resource-id (readonly)
  
       The DAV:versioned-resource-id is an identifier assigned to a
       versioned resource by the server. A versioned resource in a
       repository cannot be given a versioned resource id that has been
       given to any other versioned resource in that repository, even a
       versioned resource that has been deleted.
  
       <!ELEMENT versioned-resource-id (#PCDATA)>
       Value: segment
  
  3.4.2        DAV:default-workspace (readonly, resource)
  
       The DAV:default-workspace of a versioned resource specifies the
       default workspace used to determine the target of that versioned
       resource when no Target-Selector header is specified.
  
       <!ELEMENT default-workspace (href)>
  
  3.4.3        DAV:revisions (readonly, collection)
  
       The DAV:revisions collection of a versioned resource contains all
       revisions of that versioned resource, where the name of a revision
       in the DAV:revisions collection is its DAV:revision-id.
  
       <!ELEMENT revisions (href)>
  
  3.4.4        DAV:labeled-revisions (collection)
  
       The DAV:labeled-revisions collection is used to add, change, and
       remove labels on revisions of a versioned resource.  The
       DAV:labeled-revisions collection contains a binding for each label
       assigned to any revision of that versioned resource, where the
       binding name is that label and the binding is to the revision
       selected by that label.
  
       A BIND request is used to add or move a revision label.  When the
       Destination collection of a BIND request is the DAV:labeled-
       revisions of a versioned resource, the request-URL of the BIND MUST
       identify a revision of that versioned resource.  A DELETE request
       is used to delete a revision label.
  
       <!ELEMENT labeled-revisions (href)>
  
  3.4.5        DAV:single-checkout
  
       When the DAV:single-checkout property of a versioned-resource is
       set, only one working resource can be checked out from that
       versioned-resource at any time.
  
       <!ELEMENT single-checkout (#PCDATA)>
       Value: boolean
  
  3.4.6        DAV:auto-version
  
       When the DAV:auto-version property of a versioned resource is set,
       a request that attempts to modify the state of  a revision of that
  
  Clemm, Kaler                                       [Page 17]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       versioned resource (such as PUT/PROPPATCH for a basic resource or a
       DELETE /MOVE for a collection) is automatically preceded by a
       CHECKOUT into the default workspace and automatically followed by a
       CHECKIN.  This allows a versioning-unaware client to modify a
       version-controlled resource. The DAV:auto-version value can take
       the same values as the DAV:checkin-policy of a working resource,
       and the DAV:checkin-policy of the automatically created working
       resource is set to be the DAV:auto-version policy of the revision.
  
       <!ELEMENT auto-version (checkin-policy)>
  
  3.4.7         AV:baselines (readonly, collection) <Versioned-Collection>
  
       The DAV:baselines collection of a versioned collection contains all
       baselines of the versioned collection.
  
       <!ELEMENT baselines (href)>
  
  3.4.8         AV:repository (readonly, resource) <Versioned-Collection>
  
       The DAV:repository specifies the repository that contains this
       versioned resource.
  
       <!ELEMENT repository (href)>
  
  3.5 Revision Properties
  
       WebDAV versioning introduces the following additional properties
       for a revision:
  
  3.5.1         AV:revision-id (readonly)
  
       The DAV:revision-id is an identifier assigned to a revision by the
       server. A revision cannot be given a DAV:revision-id that has been
       given to any other revision of that versioned resource, even a
       revision that has been deleted.
  
       <!ELEMENT revision-id (#PCDATA)>
       Value: segment
       Since implementations are likely to use revision identifiers in
       resource naming schemes, a revision identifier is constrained to be
       a legal URL segment.  Standard URL encoding techniques should
       provide a server with sufficient flexibility in defining revision
       identifier formats.
  
       Since a revision identifier can be specified in a Target-Selector
       header, the length of a revision-id should be compatible with
       common header length constraints.
  
  3.5.2        DAV:predecessor (readonly, resource)
  
       The DAV:predecessor of a revision is the revision that was checked
       out to produce a working resource that was checked in to produce
       this revision.
  
       <!ELEMENT predecessor (href)>
  
  Clemm, Kaler                                       [Page 18]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.5.3        DAV:successors (readonly, mutable, collection)
  
       The DAV:successors collection of a revision contains the revisions
       whose DAV:predecessor is that revision.
  
       <!ELEMENT successors (href*)>
  
  3.5.4         AV:labels (readonly, mutable)
  
       This property is used to identify labels that are associated with a
       specific revision.
  
       <!ELEMENT labels (label*)>
       <!ELEMENT label (#PCDATA)>
       Value: segment
  
       Since revision labels are only exposed to a user as a simple
       mnemonic tag for selecting a specific revision, embedding advanced
       XML facilities for character set tagging, character set encoding,
       and language tagging would not be appropriate.  For label
       applications that are not exposed to a user, the standard URL
       encoding techniques will provide a client with sufficient
       flexibility in defining label formats.
  
       Since a revision label can be specified in a Target-Selector
       header, clients should limit the length of a revision label to be
       compatible with common header length constraints.
  
  3.5.5         AV:checkin-date (readonly)
  
       This property contains the date when the revision was checked in.
       This property is automatically assigned and is formatted using
       ISO8061.
  
       <!ELEMENT checkin-date (#PCDATA)>
       Value: date-time
  
  3.5.6        DAV:workspaces (readonly, collection)
  
       This property is a collection of the workspaces that contain
       working resources whose DAV:predecessor is this revision.
  
       <!ELEMENT workspaces (href)>
  
  3.5.7        DAV:versioned-resource (readonly, resource)
  
       The DAV:versioned-resource of a revision is the versioned resource
       whose DAV:revisions collection contains this revision.
  
       <!ELEMENT versioned-resource (href)>
  
  3.5.8        DAV:activity (readonly, resource) <Activity>
  
       The DAV:activity property of a revision is the DAV:activity of the
       working resource from which the revision was created.
  
       <!ELEMENT activity href)>
  
  Clemm, Kaler                                       [Page 19]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.5.9         AV:merge-predecessors (mutable, collection) <Activity>
  
       The DAV:merge-predecessors collection of a revision contains the
       revisions whose contents were explicitly merged by the client into
       that revision. The client is free to add or delete members to this
       collection to more accurately reflect the contents of that
       revision.
  
       A BIND request is used to add a merge predecessor.  When the
       Destination collection of a BIND request is the DAV:merge-
       predecessors of a revision of a versioned resource, the request-URL
       of the BIND MUST identify a revision of that versioned resource. A
       DELETE request is used to delete a merge predecessor.
  
       <!ELEMENT merge-predecessors (href)>
  
  3.5.10    DAV:merge-successors (mutable, collection) <Activity>
  
       The DAV:merge-successors collection of a revision contains the
       revisions whose DAV:merge-predecessors collection contains that
       revision.
  
       A BIND request is used to add a merge successor.  When the
       Destination collection of a BIND request is the DAV:merge-
       successors of a revision of a versioned resource, the request-URL
       of the BIND MUST identify a revision of that versioned resource. A
       DELETE request is used to delete a merge successor.
  
       <!ELEMENT merge-successors (href)>
  
  3.6 Working Resource Properties
  
       WebDAV versioning introduces the following additional properties
       for a working resource:
  
  3.6.1        DAV:predecessor (read-only, resource)
  
       This property contains the revision that was checked out to create
       this working resource.
  
       <!ELEMENT predecessor (href)>
  
  3.6.2        DAV:checkin-policy
  
       The DAV:checkin-policy property of a working resource describes any
       special processing that should be performed when  this working
       resource is checked in. The following are defined values for
       DAV:checkin-policy.
  
       DAV:identical-abort - the CHECKIN should fail if the working
       resource is identical to its DAV:predecessor.
  
       DAV:identical-uncheckout - if the working resource is identical to
       its DAV:predecessor, remove the working resource without creating a
       new revision.
  
  Clemm, Kaler                                       [Page 20]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       DAV:uncheckout - remove the working resource without creating a new
       revision
  
       DAV:overwrite - the working resource should be copied into its
       DAV:predecessor instead of creating a new revision. This CHECKIN
       will succeed only if the server supports mutable revisions.
  
       DAV:keep-checked-out - create a new revision but does not delete
       the working resource.  The DAV:predecessor of the working resource
       is changed to be the new revision.
  
       <!ELEMENT checkin-policy (identical-abort | identical-uncheckout |
       uncheckout
                                | overwrite | keep-checked-out | ANY)* >
  
       <!ELEMENT identical-abort EMPTY>
       <!ELEMENT identical-uncheckout EMPTY>
       <!ELEMENT uncheckout EMPTY>
       <!ELEMENT overwrite EMPTY>
       <!ELEMENT keep-checked-out EMPTY>
  
  3.6.3        DAV:merge-predecessors (collection) <Activity>
  
       The DAV:merge-predecessors collection of a working resource
       contains the revisions whose contents were explicitly merged by the
       client into that working resource. It is identical in behavior to
       the corresponding property for revisions.
  
  3.6.4        DAV:activity (readonly, resource) <Activity>
  
       The DAV:activity property of a working resource is the DAV:current-
       activity of the workspace when the working resource was checked
       out.
  
       <!ELEMENT activity (href)>
  
  3.7 Workspace Properties
  
       WebDAV versioning introduces the following additional properties
       for a workspace:
  
  3.7.1        DAV:working-resources (readonly, collection)
  
       The DAV:working-resources collection contains the working resources
       that are checked out into this workspace.
  
       <!ELEMENT working-resources (href)>
  
  3.7.2         AV:revision-selection-rule
  
       If there is no working resource in a workspace for a given
       versioned resource, the DAV:revision-selection-rule of the
       workspace specifies the revision of that versioned resource is
       selected by that workspace. Since the working resources checked out
       into a workspace take priority over revisions selected by the
  
  Clemm, Kaler                                       [Page 21]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       revision selection rule, the target of a versioned resource in a
       workspace is the working resource in that workspace for that
       versioned resource, else the revision selected by the workspace
       revision selection rule. To ensure that working resources continue
       to be visible in a workspace after they are checked in, the
       DAV:current-label or DAV:current-activity of a workspace is usually
       the first element of the DAV:revision-selection-rule. If the
       DAV:revision-selection-rule is not set or is empty, the workspace
       will select no revision for any versioned resource.
  
       The DAV:revision-selection-rule property contains an XML element.
       Semantically, a revision selection rule (or RSR) element can be
       applied to an arbitrary versioned resource, and will either select
       a particular revision of that versioned resource or select no
       revision of that versioned resource.  If it selects a particular
       revision, it may also detect a conflict (e.g. when there were
       multiple candidates for selection).  A document describing the
       conflicts can be obtained through a conflict REPORT request.
  
       <!ELEMENT revision-selection-rule
         (href | label | rsr-latest | rsr-or | rsr-merge)>
  
       <!ELEMENT rsr-latest EMPTY>
  
       <!ELEMENT rsr-or (href | label | rsr-or | rsr-merge)*>
  
       <!ELEMENT rsr-merge (href | label | rsr-or | rsr-merge)*>
  
       An href element contains the URL of a baseline, an activity, a
       configuration, or a workspace.
  
       If the href identifies a baseline, and the baseline contains a
       revision of the versioned resource, that revision is selected;
       otherwise, no revision is selected.  A baseline never generates a
       conflict.
  
       If the href identifies an activity, and the DAV:revisions
       collection of the activity contains one or more revisions of the
       versioned resource, then the latest revision in that activity is
       selected.  The semantics of activities ensures that there always is
       a unique latest revision for an activity.  If the activity contains
       no revisions of the versioned resource, the activity selects no
       revisions of that versioned resource.  If the DAV:needed-activities
       collection of an activity is non-empty, then the activity acts like
       a DAV:rsr-merge element that contains that activity and each of the
       DAV:needed-activities.  An activity element can generate conflicts
       only if the DAV:needed-activities collection is non-empty.
  
       If the href identifies a configuration, and the configuration
       contains a revision of the versioned resource, that revision is
       selected by the configuration; otherwise, no revision is selected.
       To avoid revision selection circularities, a versioned
       configuration MUST not be specified in a revision selection rule,
       but a configuration revision may.  A configuration never generates
       a conflict.
  
  Clemm, Kaler                                       [Page 22]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       If the href identifies a workspace, then the behavior of that
       element is identical to the behavior of the DAV:revision-selection-
       rule of that workspace.
  
       If the revision selection rule element is a label, and a revision
       of the versioned resource has that label, that revision is
       selected; otherwise, no revision is selected.  A label element
       never generates a conflict.
  
       A DAV:rsr-latest element selects the revision of that versioned
       resource with the latest DAV:creationdate.  A DAV:rsr-latest
       element never generates a conflict.
  
       A DAV:rsr-or element contains a sequence of RSR elements. The
       behavior of a DAV:rsr-or element is identical to the behavior of
       the first element in this sequence that selects a revision of the
       versioned resource.  If no element selects a revision, then the
       DAV:rsr-or element selects no revision of that versioned resource.
  
       A DAV:rsr-merge element contains a sequence of RSR elements.  If
       one of the elements in this sequence selects a revision that is the
       descendent of all of the other revisions selected by elements in
       this sequence, then that revision is selected by the DAV:rsr-merge
       element.  If no selected revision is a descendent of all the other
       selected revisions, then the result of the DAV:rsr-merge is a
       "conflict".  A conflicts REPORT request can be used to identify the
       conflicts.
  
  3.7.3        DAV:no-checkout
  
       The DAV:no-checkout property of a workspace indicates that no new
       working resources can be created in that workspace.
  
       <!ELEMENT no-checkout (#PCDATA)>
       Value: boolean
  
  3.7.4        DAV:current-label
  
       The DAV:current-label property of a workspace can contain a
       revision label.  When a working resource in a workspace is checked
       in, it will be given this label.
  
       <!ELEMENT current-label (#PCDATA)>
       Value: segment
  
  3.7.5        DAV:current-activity (resource) <Activity>
  
       The DAV:current-activity property of a workspace is the activity
       that is currently being performed in that workspace.   A new
       working resource in a workspace will have its DAV:current-activity
       property set to this activity.
  
       <!ELEMENT current-activity (href)>
  
  Clemm, Kaler                                       [Page 23]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.8 Activity Properties <Activity>
  
       WebDAV versioning introduces the following additional properties
       for an activity:
  
  3.8.1        DAV:revisions (readonly, collection)
  
       The DAV:revisions collection of an activity contains all revisions
       whose DAV:activity property contains this activity.
  
       <!ELEMENT revisions (href)>
  
  3.8.2        DAV:required-activities (collection)
  
       The DAV:required-activities collection of an activity contains the
       other activities that form a part of the logical change being
       captured by the activity.  The DAV:needed-activities of an activity
       contribute to the revision selection behavior of that activity when
       it is used in a revision selection rule.  The purpose of this
       property is to identify other activities that are a prerequisite to
       this activity.
  
       <!ELEMENT required-activities (href)>
  
  3.8.3        DAV:workspaces (readonly, collection)
  
       The DAV:workspaces collection of an activity contains the
       workspaces that currently have that activity as its DAV:current-
       activity.
  
       <!ELEMENT workspaces (href)>
  
  3.9 Baseline Properties <Versioned-Collection>
  
       WebDAV versioning introduces the following additional properties
       for a baseline:
  
  3.9.1 DAV:baseline-id (readonly)
  
       The DAV:baseline-id is an identifier assigned to a baseline by the
       server. A baseline cannot be given a DAV:baseline-id that has been
       given to any other baseline of that versioned collection, even a
       baseline that has been deleted.
  
       <!ELEMENT baseline-id (#PCDATA)>
       Value: segment
  
  3.9.2        DAV:predecessor (readonly, resource)
  
       The DAV:predecessor of a baseline is the baseline that selected by
       the workspace when the baseline was created.
  
       <!ELEMENT predecessor (href)>
  
  Clemm, Kaler                                       [Page 24]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.9.3        DAV:successors (readonly, mutable, collection)
  
       This property identifies the baselines whose DAV:predecessor is
       this baseline. It is identical in behavior to the corresponding
       property for revisions.
  
  3.9.4        DAV:versioned-resource (readonly, resource)
  
       This property identifies the versioned collection that contains
       this revision.  It is identical in behavior to the corresponding
       property for revisions.
  
  3.9.5        DAV:merge-predecessors (mutable, collection)
  
       This property identifies the baselines whose contents were
       explicitly merged by the client into that baseline. It is identical
       in behavior to the corresponding property for revisions.
  
  3.9.6        DAV:merge-successors (mutable, collection)
  
       This property identifies the baselines whose DAV:merge-predecessors
       collection contains a binding to this baseline. It is identical in
       behavior to the corresponding property for revisions.
  
  3.9.7 DAV:activity (readonly, resource)
  
       This property identifies the DAV:current-activity of the workspace
       when the baseline was created.
  
       <!ELEMENT activity (href)>
  
  3.10 Repository Properties <Versioned-Collection>
  
       WebDAV versioning introduces the following additional properties
       for a repository:
  
  3.10.1    DAV:versioned-resources (readonly, collection)
  
       The DAV:versioned-resources collection of a repository contains the
       set of versioned resources maintained by that repository.  The name
       of a versioned resource in the DAV:versioned-resources collection
       is its DAV:versioned-resource-id.  When a member of the
       DAV:versioned-resources collection is the request-URL of a request
       with no Target-Selector header, the request MUST be applied to the
       versioned resource itself, and not to the default target of the
       versioned resource.  This provides a mechanism for versioning
       unaware clients to access the properties of versioned resources.
  
       <!ELEMENT versioned-resources (href)>
  
  Clemm, Kaler                                       [Page 25]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  3.10.2    DAV:root-versioned-collection (readonly, resource)
  
       The DAV:root-versioned-collection of a repository  is the member of
       DAV:versioned-resources that can be exposed with a BIND operation
       in another part of the URL namespace.
  
       <!ELEMENT root-versioned-collection (href)>
  
  3.10.3    DAV:activities (collection)
  
       The DAV:activities collection of a repository contains the set of
       activities maintained by that repository.  New activities can be
       added to the DAV:activities collection of a repository with a
       MKRESOURCE request.  A server MAY restrict the creation of new
       activities to only occur in a DAV:activities collection of a
       repository.
  
       <!ELEMENT activities (href)>
  
  3.10.4    DAV:configurations (collection)
  
       The DAV:configurations collection of a repository contains the set
       of configurations maintained by that repository.  New
       configurations can be added to the DAV:configurations collection of
       a repository with a MKRESOURCE request.  A server MAY restrict the
       creation of new activities to only occur in a DAV:configurations
       collection of a repository.
  
       <!ELEMENT configurations (href)>
  
  3.10.5    DAV:workspaces (collection)
  
       The DAV:workspaces of a repository contains the set of workspaces
       maintained by that repository.  A workspace of a repository MAY be
       able to perform target selection for versioned resources in another
       repository.  New workspaces can be added to the DAV:workspaces
       collection of a repository with a MKRESOURCE request.  A server MAY
       restrict the creation of new workspaces to only occur in a
       DAV:workspaces collection of a repository.
  
       <!ELEMENT workspaces (href)>
  
  3.10.6    DAV:default-workspace (resource)
  
       The DAV:default-workspace of a repository specifies the default
       workspace for all versioned resources in that repository.
  
       <!ELEMENT default-workspace (href)>
  
  4  EXISTING METHODS
  
       This section describes the extensions to the existing WebDAV
       methods.  Under versioning, these methods have all of the WebDAV
       functionality with the following extensions.
  
  Clemm, Kaler                                       [Page 26]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  4.1 GET
  
       When the request-URL of a GET identifies a versioned resource, the
       GET is applied to the target of that versioned resource.
  
  4.2 PUT
  
       When the request-URL of a PUT identifies a versioned resource, the
       PUT is applied to the target of that versioned resource.
  
       When PUT is applied to a revision of a versioned resource, the PUT
       MUST fail unless the versioned resource has a DAV:auto-version
       property and no Target-Selector header has been specified.  In this
       case, the revision is checked out into the default workspace, the
       PUT is applied to the resulting working resource, and the working
       resource is checked in.
  
       When PUT is applied to a null resource that is an internal member
       of a working collection, a new versioned resource is created whose
       initial revision is the resource resulting from the PUT.
  
       When PUT is applied to a null resource in a revision of a versioned
       collection, the PUT MUST fail unless the versioned collection has a
       DAV:auto-version property and no Workspace or Revision-Selection
       header has been specified.  In this case, the versioned collection
       is checked out into the default workspace, a new versioned resource
       is created in that working collection, the new versioned resource
       is checked out into the default workspace, the PUT is applied to
       the resulting working resource, the working resource is checked in,
       and the working collection is checked in.
  
       When a PUT is applied to a workspace, activity, configuration,
       baseline, or versioned resource , it fails.
  
  4.3 PROPFIND
  
       When the request-URL of a PROPFIND identifies a versioned resource,
       the PROPFIND is applied to the target of that versioned resource.
       If a property is a resource property and the DAV:expand-property-
       resource is specified under a DAV:prop element in a PROPFIND
       request body, selected properties of the property resource URL of
       that property will be returned in the PROPFIND response instead of
       the href value returned by default for that property resource.
  
  4.4 PROPPATCH
  
       When the request-URL of a PROPPATCH identifies a versioned
       resource, the behavior of the PROPATCH is similar to that of PUT.
       In particular, when PROPPATCH is applied to a property of a
       revision, it MUST fail unless the property is mutable or the
       versioned resource has a DAV:auto-version property.
  
  Clemm, Kaler                                       [Page 27]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  4.5 COPY
  
       When the request-URL or Destination collection of a COPY identifies
       a versioned resource, the COPY is applied to the target of that
       versioned resource.
  
       When a COPY request is applied to a workspace, activity,
       configuration, baseline, or versioned resource, it fails.  An
       explicit MKRESOURCE request must be used to create resources of
       those types.
  
  4.6 DELETE
  
       When a DELETE request is applied to a member of a working
       collection, the specified binding is deleted from that working
       collection.
  
       When a DELETE request with an All-Bindings header is applied to a
       workspace, the workspace and all working resources of that
       workspace are also deleted.  When a DELETE request with an All-
       Bindings header is applied to a repository, all bindings to the
       versioned resources, activities, and configurations in that
       repository are also deleted.  When a DELETE request with an All-
       Bindings header is applied to a versioned resource, all bindings to
       all revisions of that versioned resource are also deleted.  If any
       of the specified bindings cannot be deleted, the DELETE request
       MUST fail.
  
  4.7 BIND
  
       When the request-URL of a BIND identifies a versioned resource, the
       BIND is applied to that versioned resource, not to the target of
       that versioned resource.  When the Destination collection of the
       BIND is a versioned collection, the request-URL MUST identify a
       versioned resource, and the new binding is made in the target of
       that versioned collection.
  
       When the Destination collection of the BIND is a configuration, the
       request-URL MUST identify a revision, and the Destination binding
       name MUST be the versioned-resource-id of that revision.
  
  4.8 MOVE
  
       When the request-URL of a MOVE identifies  a versioned resource,
       the MOVE is applied to that versioned resource, not to the target
       of that versioned resource.  When the Destination collection of the
       BIND is a versioned collection, the new binding is made in the
       target of that versioned collection.
  
  4.9 LOCK
  
       A write lock on a versioned resource checks out the target of that
       versioned resource into the default workspace.
  
  Clemm, Kaler                                       [Page 28]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  4.10       UNLOCK
  
       An UNLOCK of a write lock checks in the working resource that was
       created by the LOCK request.
  
  4.11 OPTIONS
  
       The OPTIONS method allows the client to discover the level of
       versioning support provided by a server.
  
       The following defines the BNF for the Versioning header:
  
            Versioning    := "Versioning" ":" Ver-level
            Ver-level     := "Core"
                          | "Activity"
                          | "Versioned-Collection"
  
  5  NEW METHODS
  
       WebDAV versioning introduces two new methods, MKRESOURCE and
       REPORT, that are not specific to versioning but are needed to
       support the versioning extensions.
  
  5.1 MKRESOURCE
  
       The MKRESOURCE method requests the creation of a resource and
       initialization of its properties.  It allows resources other than
       standard data containers and collections to be created and their
       properties initialized in one atomic operation.
  
       Preconditions:
  
       If the Overwrite header is not present or is set to 'F', a resource
       MUST NOT exist at the Request-URL.
  
       If the Overwrite header is set to 'T' and a resource exists at the
       Request-URL, a DELETE request on that Request-URL MUST succeed.
  
       It MUST be possible to atomically create the resource at the
       Request-URL and initialize its properties as specified in the
       request body of the MKRESOURCE request.
  
       Request Marshalling:
  
       The location of the new resource to be created is specified by the
       Request-URL.
  
       An Overwrite header MAY be specified.
  
       The request body of the MKRESOURCE method MUST consist of the
       DAV:propertyupdate XML element defined in Section 12.13 of
       [WebDAV].
  
       Semantics:
  
       A new resource with an empty body is created at the request-URL.
       Property initialization is carried out using PROPPATCH semantics.
       The type of resource to create is specified by the DAV:resourcetype
  
  Clemm, Kaler                                       [Page 29]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       property.  If the DAV:resourcetype property is not specified, the
       resource created will be a standard data container.
  
       If the Overwrite header is set to 'T' and MKRESOURCE is applied to
       an existing resource, a DELETE request is applied to the request-
       URL prior to MKRESOURCE processing.
  
       Postconditions:
  
       After the successful execution of MKRESOURCE, a new resource
       exists.  The body of the new resource is empty, and the initial
       values of the properties of the new resource are those specified in
       the property update directives in the request body.
  
       Response Marshalling:
  
       Responses from a MKRESOURCE request SHOULD NOT be cached, as
       MKRESOURCE has non-idempotent semantics.
  
       The following status codes can be expected in responses to
       MKRESOURCE:
  
       201 (Created): The new resource was successfully created.
  
       207 (Multi-Status): This response is generated if (1) the deletion
       of a resource other than the one identified by the Request-URL
       could not be completed, in which case the response is as defined in
       Section 8.6.2 of [WebDAV], or (2) an error was encountered while
       initializing the properties of the resource, in which case the
       response is as defined in Section 8.2.1 of [WebDAV].
  
       403 (Forbidden): The server does not allow the creation of the
       requested resource type at the requested location, or the parent
       collection of the request-URL exists but cannot accept members.
  
       409 (Conflict): A resource cannot be created at the request-URL
       until one or more intermediate collections have been created.
  
       412 (Precondition Failed): The Overwrite header is not present or
       is set to 'F', and a resource exists at the request-URL.
  
       423 (Locked): A locked resource exists at the request-URL and the
       lock token was not passed in with the request.
  
       507 (Insufficient Storage): The server does not have sufficient
       space to record the state of the resource.
  
  5.1.1 New DAV:resourcetype Values
  
       The DAV:resourcetype property for a versioned resource, workspace,
       activity, baseline, and configuration resource must be
       DAV:versioned-resource-resourcetype, DAV:workspace-resourcetype,
       DAV:activity-resourcetype, DAV:baseline-resourcetype,
       DAV:configuration-resourcetype, respectively.
  
  5.1.2        Example - MKRESOURCE
  
          MKRESOURCE /project1 HTTP/1.1
          Host: www.foo.com
  
  Clemm, Kaler                                       [Page 30]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:propertyupdate xmlns:D="DAV:">
            <D:set>
              <D:prop>
                <D:resourcetype>workspace</D:resourcetype>
              </D:prop>
            </D:set>
          </D:propertyupdate>
  
       >>Response
  
          HTTP/1.1 207 Multi-Status
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:multistatus xmlns:D="DAV:">
            <D:response>
              <D:href>http://www.foo.com/bar.html</D:href>
              <D:propstat>
                <D:prop><D:resourcetype/></D:prop>
                <D:status>HTTP/1.1 409 Conflict</D:status>
              </D:propstat>
              <D:responsedescription>Existing resource could not be
       deleted</D:responsedescription>
            </D:response>
          </D:multistatus>
  
  5.2 REPORT
  
       The REPORT request is an extensible mechanism for obtaining
       information about a resource.  This differs from OPTIONS in that
       the information provided is dynamic.  This document defines three
       report types: DAV:available-report, DAV:compare-report and
       DAV:conflict-report.  The REPORT method MUST not change the state
       of any resource managed by the server.
  
       Request Marshalling:
  
       The resource that is the target of the report is specified by the
       request-URL.
  
       A Depth header MAY be specified.
  
       The request body of the REPORT method MUST consist of a DAV:report-
       request XML element.
  
       Response Marshalling:
  
       The response body of the REPORT method MUST consist of a
       DAV:report-response XML element.
  
       The following status codes are used to transmit MKRESOURCE results
       back to the client.
  
  Clemm, Kaler                                       [Page 31]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       200 (OK) û Generated on successful completion of the requested
       report.  The body of the response is marshaled as a DAV:report-
       response.
  
  5.2.1        DAV:report-request
  
       Describes a report request.
  
       <!ELEMENT report-request
          (DAV:available-report-request
          | DAV:conflict-report-request
          | DAV:compare-report-request
          | ANY)>
  
  5.2.2        DAV:report-response
  
       A DAV:report-response contains an entire report.  A response can be
       for one of the standard reports (reports, conflicts, or compare) or
       for a server-defined report.  The form of server-defined requests
       is not specified.
  
       <!ELEMENT report-response status
          (available-report-response
          | conflicts-report-response
          | compare-report-response
          | ANY)>
  
  5.3 Available REPORT
  
       The list of reports supported by the resource identified by the
       request-URL.
  
  5.3.1 DAV:available-report-request
  
       No additional information is required for available-report
       requests.
  
       <!ELEMENT available-report-request EMPTY>
  
  5.3.2 DAV:available-report-response
  
       A DAV:available-report-response is a comma separated list of the
       supported reports.
  
       <!ELEMENT available-reports-response
          (DAV:available-report-request
          | DAV:conflict-report-request
          | DAV:compare-report-request
          | ANY)>
  
  5.3.3 Example - Available REPORT
  
       >>Request
  
  Clemm, Kaler                                       [Page 32]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
          REPORT http://www.webdav.org/myCollection HTTP/1.1
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Target-Selector: workspace
       http://www.webdav.org/repo/workspaces/public
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:report-request xmlns:D="DAV:">
            <D:available-report-request/>
          </D:report-request>
  
       >>Response
  
          HTTP/1.1 200 OK
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Target-Selector: workspace
       http://www.webdav.org/repo/workspaces/public
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:report-response xmlns:D="DAV:">
             <D:available-report-response>
                <DAV:available-report-request/>
                <DAV:conflict-report-request/>
             </D:reports-response>
          </D:report-response>
  
  5.4 Conflict REPORT
  
       A conflict report describes the conflicts in a specified workspace
       for a specified resource or for all the members of a specified
       versioned collection. Conflicts occur when the workspace revision
       selection rule selects more than one revision of a particular
       versioned resource, resulting in ambiguous revision selection.  The
       resource to test is specified by the request-URL.  Conflicts are
       checked in the workspace specified in the Target-Selector header.
       The Target-Selector, if given, MUST be a workspace URL.  If the
       Target-Selector header is not given, the default workspace is used.
  
       Conflicts for all resources transitively reachable from the
       request-URL are reported according to the value of the Depth
       header.  If the Depth header is not specified, the value infinity
       is assumed.  Conflicts in resources reachable only via a versioned
       collection which is itself ambiguous are not reported.
  
  5.4.1 DAV:conflict-report-request
  
       <!ELEMENT conflict-report-request EMPTY>
  
  5.4.2 DAV:conflict-report-response
  
       A DAV:conflict-report-response contains a DAV:conflict element for
       each versioned resource for which the workspace  produced a
       conflict.
  
  Clemm, Kaler                                       [Page 33]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       <!ELEMENT conflicts-report-response (conflict*)>
  
  5.4.3 DAV:conflict
  
       The DAV:conflict element contains the URL of a versioned resource
       for which the revision selection rule generated a conflict, a
       DAV:common-ancestor for the conflict, and two or more
       DAV:contributor elements for the conflict.
  
       <!ELEMENT conflict (href, common-ancestor, contributor,
       contributor+)>
  
  5.4.4        DAV:common-ancestor
  
       The DAV:common-ancestor element identifies the revision id of a
       revision that is a common ancestor of all the DAV:contributor
       elements for a particular conflict.
  
       <!ELEMENT common-ancestor (#PCDATA)>
       Value: segment
  
  5.4.5        DAV:contributor
  
       The DAV:contributor element identifies the revision id of a
       revision that is selected by an element of the revision selection
       rule but that is not an ancestor of any of the other revisions
       selected by the revision selection rule.
  
       <!ELEMENT contributor(#PCDATA)>
       Value: segment
  
  5.4.6 Example - Conflict REPORT
  
       >>Request
  
          REPORT http://www.webdav.org/myCollection HTTP/1.1
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Target-Selector: workspace
       http://www.webdav.org/repo/workspaces/public
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:report-request xmlns:D="DAV:">
             <D:conflicts-report-request/>
          </D:report-request>
  
       >>Response
  
          HTTP/1.1 200 OK
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Target-Selector: workspace
       http://www.webdav.org/repo/workspaces/public
  
          <?xml version="1.0" encoding="utf-8" ?>
  
  Clemm, Kaler                                       [Page 34]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
          <D:report-response xmlns:D="DAV:">
             <D:conflicts-report-response>
                <D:conflict>
                   <D:href>http://www.webdav.org/repo/vr/vr732</D:href>
                   <D:common-ancestor>revisionid:3</D:common-ancestor>
                   <D:contributor>revisionid:5</D:contributor>
                   <D:contributor>revisionid:4</D:contributor>
                </D:conflict>
             </D:conflicts-report-response>
          </D:report-response>
  
  5.5 Compare REPORT
  
       A compare REPORT identifies the differences between the resource
       identified by the request-URL (base) and the resources specified in
       the body of the request (targets). The comparison is carried out
       transitively on any children of the resources according to the
       value of the Depth header.  If the Depth header is not specified,
       the value infinity is assumed.  Resources appearing in a target but
       not in the base are described by DAV:added elements, resources
       appearing in the base but not a target are described by DAV:deleted
       elements, and resources appearing in both base and target but
       having different states are described by DAV:changed elements.
       Resource content comparison is not specified, though servers MAY
       provide it.
  
  5.5.1        DAV:compare-request
  
       A DAV:compare- request contains the URL's of the resources to be
       compared with the resource identified by the request URL..
  
       <!ELEMENT compare-request (href*)>
  
  5.5.2        DAV:compare-response
  
       A DAV:compare-response identifies the differences between two
       resources.  These differences are indicated by appropriate
       DAV:added, DAV:deleted, and DAV:changed elements.  For example, if
       a DAV:compare-request is applied to two baselines, the DAV:compare-
       response contains the revisions that are selected by one baseline
       but not the other.
  
       <!ELEMENT compare-response (added*, deleted*, changed*)>
  
  5.5.3 DAV:added
  
       A DAV:added element identifies something that appears in a
       particular target resource but not in the base.
  
       <!ELEMENT added (href, ANY>
  
  Clemm, Kaler                                       [Page 35]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  5.5.4 DAV:deleted
  
       A DAV:deleted element identifies something that appears in the base
       resource but not in a particular target.
  
       <!ELEMENT deleted (href, ANY)>
  
  5.5.5 DAV:changed
  
       A DAV:changed element identifies information that is in both the
       base and the target but that has changed in some way.  For example,
       when two baselines are being compared, a DAV:changed element can
       identify a versioned resource if the baseline select different
       revisions of that versioned resource.
  
       <!ELEMENT changed (href, ANY)>
  
  5.5.6 Example - Compare REPORT
  
       >>Request
  
          REPORT /myCollection HTTP/1.1
          Host: www.foo.com
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Depth: 1
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:report-request xmlns:D="DAV:">
            <D:compare-request>
              <href>http://www.foo.com/myOtherCollection</href>
            </D:compare-request>
          </D:report-request>
  
       >>Response
  
          HTTP/1.1 200 OK
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:report-response xmlns:D="DAV:">
             <D:compare-response>
                <D:added>
                   <href>http://www.foo.com/myOtherCollection</href>
  
       <href>http://www.foo.com/myOtherCollection/foo.html</href>
                </D:added>
                <D:deleted>
                   <href>http://www.foo.com/myOtherCollection</href>
                   <href>http://www.foo.com/myCollection/bar.html</href>
                </D:deleted>
             </D:compare-response>
          </D:report-response>
  
  Clemm, Kaler                                       [Page 36]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
  6  NEW VERSIONING METHODS
  
       WebDAV versioning introduces a CHECKOUT and a CHECKIN method.
  
  6.1 CHECKOUT
  
       The CHECKOUT method can be applied to a revision of a versioned
       resource to produce a working resource that is a modifiable copy of
       that revision.  If the workspace for the working resource is not
       specified in the Target-Selector header, the server will select a
       workspace for it.  After a CHECKOUT on a request-URL succeeds, a
       subsequent request on that request-URL that specifies that
       workspace in a Target-Selector header will be applied to that
       working resource.  A CHECKIN request applied to that working
       resource can be used to create a new revision of that working
       resource.
  
       Preconditions:
  
       The request-URL MUST identify either a revision or a versioned
       resource whose target is a revision.  This is the "selected
       revision".  The versioned resource for the revision is the
       "selected versioned resource".
  
       If the DAV:single-checkout property of the selected versioned
       resource is set, the DAV:workspaces collection of the selected
       revision MUST have no members.
  
       If the Target-Selector header specifies a workspace, the DAV:no-
       checkout property of  that workspace MUST not be set.
  
       If the Target-Selector header specifies a workspace, at least one
       of the DAV:current-activity or the DAV:current-label property of
       that workspace MUST be set.
  
       If the Target-Selector header specifies a workspace with a
       DAV:current-activity property, the DAV:workspaces collection of
       that activity must be empty.
  
       If the Target-Selector header specifies a workspace, the
       DAV:workspaces collection of the revision MUST not contain that
       workspace.
  
       Request Marshalling:
  
       The request-URL specifies the revision to check out.
  
       The workspace for the working resource MAY be specified in the
       Target-Selector header.
  
       Semantics:
  
       The CHECKOUT method creates a working resource that is a copy of
       the revision.  If a workspace for the working resource is not
       specified in the Target-Selector header, the server allocates a
       workspace for the new working resource.  The workspace containing
       the working resource is the "selected workspace".
  
  Clemm, Kaler                                       [Page 37]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       Postconditions:
  
       The DAV:predecessor of the new working resource is set to the
       selected revision.
  
       The DAV:workspace of the new working resource is set to the
       selected workspace.
  
       The selected workspace is added to the DAV:workspaces collection of
       the selected revision.
  
       The selected versioned resource is added to the DAV:checked-out
       collection of the selected workspace.
  
       If the DAV:current-activity property of the selected workspace is
       set, the DAV:activity property of the working resource is set to
       that activity.
  
       Response Marshalling:
  
       Results from a CHECKOUT request MUST NOT be cached as CHECKOUT has
       non-idempotent semantics.
  
       The CHECKOUT request response MUST contain a DAV:response XML
       element, as defined in section 12.9.1 of [RFC2518].  The
       DAV:response MUST contain a DAV:href containing the DAV:versioned-
       resource property of the selected revision, followed by either a
       DAV:status containing an error status or a DAV:propstat element
       describing properties of the new working resource.  The
       DAV:workspace property of the working resource must be included in
       the DAV:prop element.
  
       The following status codes can appear in the DAV:status element.
  
       201 (Created) - The working resource was successfully created.
  
       404 (Not Found) û The request-URL did not identify a resource.
  
       405 (Method Not Allowed) û The selected resource is not a revision
       or the specified Target-Selector is invalid.
  
       409 (Conflict) û Any other violated pre-condition of the CHECKOUT
       request.
  
  6.1.1        Example - CHECKOUT
  
       >> REQUEST
  
          CHECKOUT http://www.webdav.org/file HTTP/1.1
          Target-Selector: http://www.webdav.org/workspaces/mywksp
          Content-type: text/xml; charset="utf-8"
  
          <? xml version="1.0" encoding="utf-8" ?>
          <D:propertyupdate xmlns:D="DAV:">
             <D:set>
                <D:prop>
                   <D:checkin-policy>
                      <D:keep-checked-out/> </D:checkin-policy>
                   <D:comment>
                      Add animated logo. </D:comment> </D:prop> </D:set>
  
  Clemm, Kaler                                       [Page 38]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
          </D:propertyupdate>
  
       >> RESPONSE
  
          HTTP/1.1 201 Created
          Target-Selector: http://www.webdav.org/workspaces/mywksp
          Content-type: text/xml; charset="utf-8"
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:response xmlns:D="DAV:">
             <D:href>http://www.webdav.org/file</D:href>
             <D:propstat>
                <D:prop>
                   <D:workspace>
  
       <D:href>http://www.webdav.org/workspaces/mywksp</D:href>
                   </D:workspace>
                <D:status>HTTP/1.1 201 Created</D:status>
             </D:propstat>
          </D:response>
  
  6.2 CHECKIN
  
       The CHECKIN method can be applied to a working resource of a
       versioned resource to produce a new revision that is a copy of that
       working resource. This working resource is the "selected working
       resource".  The DAV:predecessor of the selected working resource is
       the "predecessor revision".  The versioned resource that contains
       the predecessor revision is the "selected versioned resource".  The
       DAV:activity of the selected working resource is the "selected
       activity". CHECKIN can also be used to cancel the CHECKOUT, and if
       the server supports mutable revisions, it can also be used to
       overwrite the value of the revision that is the predecessor of the
       working resource.
  
       Preconditions:
  
       A CHECKIN request MUST specify a workspace in a Target-Selector
       header.  This is the "selected workspace".
  
       The request-URL MUST identify a versioned resource whose target in
       the selected workspace is a working resource.  This is the
       "selected working resource".
  
       If DAV:identical-abort is a DAV:checkin-policy, then the selected
       working resource MUST not be a copy of the predecessor revision
       (ignoring live properties).
  
       Request Marshalling:
  
       The request-URL specifies the working resource.
  
       The Target-Selector header specifies the workspace that contains
       the selected working resource.  This workspace is the "selected
       workspace".
  
  Clemm, Kaler                                       [Page 39]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       If a CHECKIN request body is specified, it MUST contain a
       DAV:propertyupdate XML element.
  
       Semantics:
  
       The property updates specified in the CHECKIN request body are
       applied to the selected working resource.
  
       If DAV:uncheckout is specified, a new revision is not created.
  
       If DAV:identical-uncheckout is specified, a new revision is created
       only if the selected working resource is a copy of the predecessor
       revision (ignoring live properties).
  
       A copy of the selected working resource (without the DAV:checkin-
       policy property) is made a new revision of the selected versioned
       resource.
  
       If DAV:keep-checked-out is specified, the working-resource is not
       deleted, but the DAV:predecessor property of the working resource
       is modified to contain the new revision.  Otherwise, the selected
       working resource is removed from the selected workspace.
  
       Postconditions:
  
       The selected workspace is deleted from the DAV:workspaces
       collection of the predecessor revision.
  
       If the CHECKIN created a new revision, the new revision is added to
       the DAV:successors collection of the predecessor revision.
  
       If the CHECKIN created a new revision and there is a selected
       activity, the new revision is added to the DAV:revisions collection
       of the selected activity.
  
       Response Marshalling:
  
       The following status codes can appear in the DAV:status element.
  
       201 (Created) - The revision was successfully created.
  
       404 (Not Found) û The request-URL did not identify a resource.
  
       405 (Method Not Allowed) û The selected resource is not a working
       resource, the specified Target-Selector is invalid, or the
       specified properties in the DAV:propertyupdate element are invalid.
  
       409 (Conflict) û Any other violated pre-condition of the CHECKIN
       request.
  
  6.2.1        Example - CHECKIN
  
       >> REQUEST
  
          CHECKIN http://www.webdav.org/file HTTP/1.1
          Target-Selector: http://www.webdav.org/workspaces/mywksp
          Content-type: text/xml; charset="utf-8"
  
          <? xml version="1.0" encoding="utf-8" ?>
          <D:propertyupdate xmlns:D="DAV:">
             <D:set>
  
  Clemm, Kaler                                       [Page 40]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
                <D:prop>
                   <D:checkin-policy>
                      <D:identical-abort/> </D:checkin-policy>
                </D:prop> </D:set>
          </D:propertyupdate>
  
       >> RESPONSE
  
          HTTP/1.1 201 Created
          Target-Selector: http://www.webdav.org/workspaces/mywksp
          Content-type: text/xml; charset="utf-8"
  
          <?xml version="1.0" encoding="utf-8" ?>
          <D:response xmlns:D="DAV:">
             <D:href>http://www.webdav.org/file</D:href>
             <D:status>HTTP/1.1 201 Created</D:status>
          </D:response>
  
  7  NEW VERSIONING HEADERS
  
  7.1 Target-Selector
  
        Whenever a server encounters a versioned resource while it is
       processing an HTTP request, it is required to act on the target of
       the versioned resource, rather than the versioned resource itself.
       The Target-Selector header is used to specify how the target is
       determined.  In particular, the Target-Selector header can specify
       a workspace,  a revision-id, or a label.
  
            Target-Selector: workspace
       "http://www.webdav.org/workspaces/public"
            Target-Selector: id "Rev178AE8"
             Target-Selector: label "released"
             Target-Selector: metadata
       When the Target-Selector specifies a workspace, then the working
       resource in that workspace for a versioned resource is selected, if
       there is one.  Otherwise, the revision selected by the
       DAV:revision-selection-rule property of that workspace is selected.
  
       When the Target-Selector header specifies a revision-id or a label,
       then the specified revision is selected for the versioned resource
       identified by the request-URL, but for any other versioned resource
       encountered by the server while processing the request, the default
       workspace of that versioned resource is used.
  
       When the Target-Selector header specifies metadata, the versioned
       resource itself is selected.  This allows a client to access the
       properties of the versioned resource.
  
       If no Target-Selector header is specified, the DAV:default-
       workspace of a versioned-resource is used to perform target
       selection for that versioned-resource.  An exception to this is the
  
  Clemm, Kaler                                       [Page 41]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       DAV:versioned-resources collection of a repository, in which the
       versioned resource itself is the target of the versioned resource.
  
  8  INTERNATIONALIZATION CONSIDERATIONS
  
       To be supplied.
  
  9  SECURITY CONSIDERATIONS
  
       To be supplied.
  
  10 SCALABILITY
  
       To be supplied.
  
  11 AUTHENTICATION
  
       Authentication mechanisms defined in WebDAV will also apply to
       WebDAV Versioning.
  
  12 IANA CONSIDERATIONS
  
       This document uses the namespace defined by [RFC2518] for XML
       elements.  All other IANA considerations mentioned in [RFC2518]
       also applicable to WebDAV Versioning.
  
  13 INTELLECTUAL PROPERTY
  
       The following notice is copied from RFC 2026, section 10.4, and
       describes the position of the IETF concerning intellectual property
       claims made against this document.
  
       The IETF takes no position regarding the validity or scope of any
       intellectual property or other rights that might be claimed to
       pertain to the implementation or use other technology described in
       this document or the extent to which any license under such rights
       might or might not be available; neither does it represent that it
       has made any effort to identify any such rights.  Information on
       the IETF's procedures with respect to rights in standards-track and
       standards-related documentation can be found in BCP-11.  Copies of
       claims of rights made available for publication and any assurances
       of licenses to be made available, or the result of an attempt made
       to obtain a general license or permission for the use of such
       proprietary rights by implementers or users of this specification
       can be obtained from the IETF Secretariat.
  
       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
  
  Clemm, Kaler                                       [Page 42]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       rights which may cover technology that may be required to practice
       this standard.  Please address the information to the IETF
       Executive Director.
  
  14 ACKNOWLEDGEMENTS
  
       This protocol is the collaborative product of the Delta-V design
       team: Jim Amsden (IBM, DeltaV Chair), Geoffrey Clemm (Rational),
       Bruce Cragun (Novell), David Durand (INSO), Chris Kaler
       (Microsoft), Jeff McAffer (OTI), Bradley Sergeant (Merant), and Jim
       Whitehead (UC Irvine).  We would like to acknowledge the foundation
       laid for us by the authors of the WebDAV and HTTP protocols upon
       which this protocol is layered, and the invaluable feedback from
       the WebDAV and DeltaV working groups.
  
  15 INDEX
  
       To be supplied.
  
  16 REFERENCES
  
       [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
       1996, <http://www.ietf.org/rfc/rfc2026.txt>.
  
       [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, 1997,
       <http://www.ietf.org/rfc/rfc2068.txt >.
  
       [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", Harvard, 1997,
       <http://www.ietf.org/rfc/rfc2119.txt >.
  
       [RFC2396] T.Berners-Lee, R.Fielding, L.Masinter, ôUniform Resource
       Identifiers (URI): Generic Syntaxö, MIT/LCS, U.C. Irvine, Xerox,
       1998, <http://www.ietf.org/rfc/rfc2396.txt>.
  
        [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
       "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
       U.C.Irvine, Netscape, Novell, 1999
       <http://www.ietf.org/rfc/rfc2518.txt>.
  
       [Binding] J.Slein, E.Whitehead, J.Davis, G.Clemm, C.Fay,
       J.Crawford, T.Chihaya, "WebDAV Bindings", Xerox, U.C.Irvine,
       CourseNet, Rational, FileNet, DataChannel, 1999,
       <http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-
       protocol-01.txt>
  
       [Goals] J.Amsden, C.Kaler, J.Stracke, "Goals for Web Versioning",
       IBM, Microsoft, Netscape, 1999, <http://www.ietf.org/internet-
       drafts/draft-ietf-webdav-version-goals-01.txt>
  
  17 AUTHORS' ADDRESSES
  
  Clemm, Kaler                                       [Page 43]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       Geoffrey Clemm
       Rational Software
       20 Maguire Road
       Lexington, MA
       Email: geoffrey.clemm@rational.com
  
       Christopher Kaler
       Microsoft
       One Microsoft Way
       Redmond WA, 9085-6933
       Email: ckaler@microsoft.com
  
  18 OPEN ISSUES
  
       The following list identifies key open issues against this
       document:
  
       @ TODO: Allow activity and workspace as CHECKIN request-URL.
  
       @ TODO: Allow CHECKOUT to apply to a versionable resource (like
          LOCK).
  
       @ TODO: Describe how MKRESOURCE can be used to create a baseline.
  
       @ TODO: Describe how BIND can mount the root versioned collection
          of a repository  at an arbitrary URL, even at another authority.
  
       @ Does Versioning have to be a header, or can it be the body of the
          OPTIONS response?
  
       @ Couldn't MKRESOURCE be handled just by allowing PROPPATCH to be
          applied to a null resource?
  
       @ Do members of  a versioned collection revision have to be
          versioned resources?
  
       @ Should the server be allowed to restrict where activities,
          workspaces, and configurations are located in the URL namespace?
  
       @ Are revision-id's and revision labels in the same namespace (so
          that the do not need to be disambiguated in the DAV:revision-
          selection-rule and the Target-Selector header)?
  
       @ Do we require locking support for workspace, activity,
          configuration, baseline, versioned resource?
  
       @ Should we use the collection protocol to access the "property
          collections", or define a separate special add/delete/query for
          each?
  
       @ Should we support the "document" variant for properties that
          contain a resource URL (i.e. a "property resource")
  
       @ Should we separate the Target-Selector into a Workspace and a
          Revision-Selector?
  
       @ Should we allow Depth CHECKOUT?
  
       @ Is there a problem with encoding labels and revision-id's as
          segments?
  
  Clemm, Kaler                                       [Page 44]


  INTERNET-DRAFT       WebDAV Versioning     October 22, 1999
  
       @ Can there be any working resources under a collection when a
          baseline for that collection is created?
  
       METHOD Template
  
       Preconditions:
  
       {What are the expected preconditions of the method, and what
       happens if these preconditions are violated. For example, a common
       precondition is the resource identified by the Request-URI must
       exist.}
  
       Request Marshalling:
  
       {How are the arguments for the method marshalled.  For WebDAV, this
       includes stating which headers must be present, and which XML
       elements are present in the request body.}
  
       Semantics:
  
       {It clearly states the semantics of the method's operation.}
  
       Postconditions:
  
       {It states the postconditions of the method, giving easily
       validated postconditions.  Some examples of postconditions are
       effects on the state of the resource, including body and
       properties, and effects on the resource's parent collection.
       Postconditions will often vary depending on the type of the
       resource executing the method.}
  
       Response Marshalling:
  
       {It states how the results of the method are marshalled, including
       the response for success, and the responses which are generated
       when the postconditions cannot be achieved.}
  
       Effect on Existing Resource Types:
  
       {How does this method work on all the different types of resources
       defined so far (collections, redirect references, ordinary
       resources, etc.)}
  
  Clemm, Kaler                                       [Page 45]