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

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

                       Versioning Extensions to WebDAV

  Status of this Memo Memo.

  This document is an Internet draft. Internet drafts Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas areas, and its working groups. Note that other groups
  may also distribute working information documents as Internet drafts.

       Internet Drafts Internet-Drafts.

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

       To learn the current status progress."

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

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

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

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

  Abstract

  This document specifies a set of methods, headers, and content-
       types composing DAV resource-types
  that define the WebDAV Versioning extensions, an application of extensions to the HTTP/1.1 protocol protocol.
  WebDAV Versioning will minimize the complexity of clients so as to version DAV resources.
  facilitate widespread deployment of applications capable of utilizing
  the WebDAV Versioning services. WebDAV Versioning includes:

       - Automatic versioning support for versioning-unaware clients,

       - Linear versioning , and

       - Support for parallel development and configuration management.

  Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  9.  WORKSPACE CONFIGURATIONS .............................37
  9.1.Managing Configuration Content .......................37
  9.2.Default TYPES AND PROPERTIES..............14
  4.1  Property Attributes................................14
   4.1.1 Writeable/Readonly Properties....................14
   4.1.2 Immutable/Mutable Properties.....................14
   4.1.3 Property Resources...............................14
  4.2  Resource Properties................................15
   4.2.1 DAV:author  (immutable) [Core]...................15
   4.2.2 DAV:comment  (immutable) [Core]..................15
  4.3  Revision Properties................................15
   4.3.1 DAV:revision-id (readonly) [Core]................15
   4.3.2 DAV:predecessor (readonly, resource) [Core]......15
   4.3.3 DAV:successors (readonly, mutable, collection)...15
   4.3.4 DAV:single-checkout (mutable) [Core].............15
   4.3.5 DAV:auto-version (mutable) [Core]................16
   4.3.6 DAV:revision-labels (mutable) [Core].............16
   4.3.7 DAV:checkin-date (readonly) [Core]...............16
   4.3.8 DAV:working-resources (readonly, collection) ....16
   4.3.9 DAV:history-uuid (readonly) [Core]...............16
   4.3.10DAV:history (readonly, resource) [Core]..........16
   4.3.11DAV:merge-predecessors (mutable, collection).....16
   4.3.12DAV:merge-successors ............................17
  4.4  Working Resource Properties........................17
   4.4.1 DAV:workspace (readonly, resource) [Core]........17
   4.4.2 DAV:predecessor (read-only, resource) [Core].....17
   4.4.3 DAV:checkin-policy [Core]........................17
   4.4.4 DAV:merge-predecessors (collection) [Merging]....18
   4.4.5 DAV:activity (readonly, resource) [Activity].....18
  4.5  Workspace Configurations .....................38

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

  11. VERSION MAPPING ......................................39
  11.1. Discovery ..........................................40
  11.2. Mapping Configurations .............................41
  11.3. Mapping Properties...............................18
   4.5.1 DAV:working-resources (readonly, collection) ....18
   4.5.2 DAV:revision-selection-rule  [Core]..............18
   4.5.3 DAV:label [Core].................................19
   4.5.4 DAV:activity [Activity]..........................19
  4.6  Activity Properties................................19
   4.6.1 DAV:revisions (readonly, collection) [Activity]..19
   4.6.2 DAV:required-activities (collection) [Activity]..19
   4.6.3 DAV:workspace (resource) [Activty]...............19
  4.7  Configuration Properties...........................19
   4.7.1 DAV:roots (immutable, collection) [Configuration]20
  4.8  Versioned Collection Properties....................20
   4.8.1 DAV:baselines (resource) [Baseline]..............20
  4.9  History Resource Versions ..........................41

  12. Properties........................20
   4.9.1 DAV:uuid (readonly) [Core].......................20
   4.9.2 DAV:revisions (readonly, collection) [Core]......20
   4.9.3 DAV:revision-labels (collection) [Core]..........20

  5 VERSIONING METHODS....................................21
  5.1  Existing Methods...................................21
   5.1.1 GET..............................................21
   5.1.2 BIND.............................................21
   5.1.3 PUT..............................................21
   5.1.4 PROPFIND.........................................22
   5.1.5 PROPPATCH........................................22
   5.1.6 DELETE...........................................22
   5.1.7 COPY.............................................22
   5.1.8 MOVE.............................................22
   5.1.9 LOCK.............................................23
   5.1.10 OPTIONS..........................................23
  5.2  New Methods........................................23
   5.2.1 MKRESOURCE.......................................23
   5.2.2 REPORT...........................................24
  5.3  New Versioning Methods.............................24
   5.3.1 CHECKOUT.........................................24
   5.3.2 CHECKIN..........................................25
   5.3.3 UNCHECKOUT.......................................25
  5.4  New Versioning Headers.............................26
   5.4.1 Target-Selector..................................26

  6 THE DAV VERSIONING GRAMMAR ...........................42

  13. XML ELEMENTS.......................26
  6.1  Revision Selection Rule Elements...................26
   6.1.1 DAV:rsr-configuration............................26
   6.1.2 DAV:rsr-activity-latest..........................26
   6.1.3 DAV:rsr-label....................................27
   6.1.4 DAV:rsr-revision-id..............................27
   6.1.5 DAV:rsr-latest...................................27
   6.1.6 DAV:rsr-or.......................................27
   6.1.7 DAV:rsr-merge....................................27
  6.2  Report Elements....................................28
   6.2.1 Conflicts Report.................................28
   6.2.2 Compare Report...................................28
  7 INTERNATIONALIZATION CONSIDERATIONS ..................42

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1  INTRODUCTION

  1.1. DAV Versioning

       This document defines DAV Versioning extensions, an application of
       HTTP/1.1 for handling resource versioning in a DAV environment.
       [DAVVERREQ]
       [VerGoal] describes the motivation and requirements for DAV
       Versioning.

       DAV Versioning will minimize the complexity of clients so as to
       facilitate widespread deployment of applications capable of
       utilizing the DAV services.  As well, DAV Versioning supports a
       rich level of versioning options for versioning-aware clients.

       DAV Versioning consists of:

       - Automatic versioning support for HTTP/1.1-based versioning-unaware clients,

       -  Basic Linear versioning for DAV Versioning-aware clients,

       -  File branching for basic parallel development, , and

       -  Configuration support Support for sophisticated parallel development.

  1.2. development and configuration management.

  1.1 Relationship to DAV

       To maximize interoperability and use of existing protocol
       functionality, versioning support is designed as extensions to the
       WebDAV [RFC2518] and advanced-collection protocols [AdvCol].  In
       particular, DAV Versioning relies on the resource and property
       model defined by
       [WebDAV].  DAV Versioning does not alter this model.  Instead, DAV
       Versioning allows clients to version and access DAV-modeled
       resources [RFC2518] and histories.

  1.3. Terms

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

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

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

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

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

       Revision History - This refers  orthogonal extensions to the set
       Core: Activity, Merging, Configuration, Versioned Collection, and
       Baseline versioning support.  Core support provides versioning of changes to a versioned
       resource
       Working Resource - This refers
       largely independent resources.  It allows authors to a resource that is an
       intermediate revision concurrently
       create and access distinct revisions of a versioned resource.  That is,  Activity
       support extends Core support with logical change tracking and
       management through activities.  Merging support extends Core
       support with conflict detection and resolution through merging.
       Configuration support extends Core support with the
       versioned resource has been "checked out" creation of
       sets of consistent revisions.  Versioned Collection support extends
       Core support with the ability to version the URL namespace.
       Baseline support extends Configuration and Versioned Collection
       support with the ability to create and compare configurations of
       all revisions in a URL subtree.

       Throughout this specification the [xyz] notation is where changes
       are made until it is ready used to be "checked in".  Note
       indicate that working
       resources are not versioned.

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

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

  1.2 Terms

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

  1.5. terms defined in [RFC2068] and [RFC2518].

  1.3 Notational Conventions

       The augmented BNF used by this document to describe protocol
       elements is exactly the same as the one described in Section 2.1 of
       [RFC2068]. Because this augmented BNF uses the basic production
       rules provided in Section 2.2 of [RFC2068], those rules apply to
       this document as well.

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
       this document are to be interpreted as described in [RFC2119].

  2. BASIC VERSIONING

  2  CONCEPTS AND DEFINITIONS

       The base level of versioning support defined by this specification
       includes both automatic versioning and section presents the basic versioning
       properties defined for all concepts and terms/definitions
       used in this protocol.

     Versionable Resource

       A versionable resource is a resource that can be placed under
       version control.  A null resource is a versionable resource.

     Versioned Resource

       A versioned resource is a resource that is under version control.
       To update a resource under version control, it must be checked out
       and then subsequently checked in.  The checked in states of a
       versioned resource are saved by the server to capture the history
       of that resource.

     Revision
       A revision contains a particular state of a versioned resource. An
       immutable revision is a revision whose body and immutable
       properties cannot be modified.  A mutable revision is a revision
       whose state can be overwritten by a subsequent check in request.

     Revision Name

       A revision name is a name that can be used to identify a single
       revision of a versioned resource. There are two types of revision
       names: revision identifiers and revision labels.

     Revision Identifier

       A revision identifier (or revision ID) is a revision name that is
       assigned by the server when the revision is created and cannot be
       changed to refer to a different revision.

     Revision Label

       A revision label is a revision name that is assigned by a client
       and may later be changed to refer to a different revision. The same
       label may be assigned to many different versioned resources.

     Initial Revision

       An initial revision is the first revision of a versioned resource.

     Predecessor, Successor

       A predecessor of a revision is the previous revision that was
       checked out to create the revision. A successor of a revision is a
       revision whose predecessor is that revision.  Each revision has a
       single predecessor (except for the initial revision which has no
       predecessor) and zero or more successors.

     Merge Predecessor, Merge Successor

       A merge predecessor of a revision is a revision that has been
       merged into this revision.  A merge successor of a revision is a
       revision into which that revision has been merged.  A revision can
       have zero or more merge predecessors and zero or more merge
       successors.

     Line Of Descent

       A line of descent to a specified revision is a sequence of
       revisions connected by successor relationships from the initial
       revision to that revision.

     The following diagram illustrates several of the previous
     definitions.

              Versioned -->    Foo.htm
               Resource
                                +----+                  \
          Label  -->  "initial" | V1 |       |           |
                 \              +----+       |           |
                  \                |         |           |
                   \               v         |           |
                    \           +----+       | Line      |
                     -> "beta1" | V2 |       | of        |
                                +----+       | Descent   |
                               /   |         |           |
                              v    v         |           |
                         +----+ +----+       |           |
         Revision Id --> | V3 | | V4 |       |           | History
                         +----+ +----+       |           |
                      ^     |      |         |           |
                      |     v      v         |           |
         Predecessor  |  +----+ +----+       v           |
                         | V5 | | V6 |                   |
                         +----+ +----+                   |
                               \   |    | Successor      |
                          |     v  v    |                |
         Merge Successor  |     +----+  v                |
                          v     | V7 |                   |
                                +----+                  /

     Immutable/Mutable Property

       An immutable property is a property of an immutable revision that
       cannot be changed.  A mutable property is a property of an
       immutable revision that can be changed.  Only properties of
       revisions can be immutable or mutable.

     Working Resource

       A working resource is an editable resource created by checking out
       a revision of a versioned resource.

     Checkout/Checkin Model

       The checkout/checkin model is the process by which updates are made
       to a versioned resource.  A versioned resource is checked out to
       create an editable working resource.  The working resource is
       updated or augmented as desired, and then checked in to make it
       part of the revision history of the versioned resource.

     The following diagram illustrates the checkout/checkin process.

              ===CHECKOUT==>     ===CHECKIN==>

          Foo.htm     |   Foo.htm     |   Foo.htm
                      |               |
           +----+     |    +----+     |    +----+
           | V1 |     |    | V1 |     |    | V1 |
           +----+     |    +----+     |    +----+
              |       |       |       |       |
              v       |       v       |       v
           +----+     |    +----+     |    +----+
           | V2 |     |    | V2 |     |    | V2 |
           +----+     |    +----+     |    +----+
                      |       |       |       |
                      |       v       |       v
                      |    +----+     |    +----+
                      |    | WR |     |    | V3 |
                      |    +----+     |    +----+
     Activity

       An activity is a resource that selects a set of revisions that
       correspond to some unit of work or conceptual change. An activity
       can contain revisions of multiple versioned resources, and multiple
       revisions of the same versioned resource.  If an activity contains
       multiple revisions of the same versioned resource, all of those
       revisions must be on a single line of descent to one of those
       revisions, and this revision is called the latest revision selected
       by that activity for that versioned resource.

       The following diagram illustrates activities.  Revision V3 is the
       latest revision of Foo.htm selected by activity 2, and revision V7
       is the latest revision of Bar.htm selected by activity 2.

          Foo.htm             |    Bar.htm
                              |
           +----+             |     +----+
           | V1 |             |     | V5 |
           +----+             |     +----+
              |    Activity   |        |     Activity
              v        1      |        v         2
           +----+             |     +----+
           | V2 |             |     | V6 |
           +----+             |     +----+
              |    Activity   |        |     Activity
              v        2      |        v         2
           +----+             |     +----+
           | V3 |             |     | V7 |
           +----+             |     +----+
                              |        |     Activity
                              |        v         3
                              |     +----+
                              |     | V8 |
                              |     +----+

     Workspace

       A workspace is a resource that is used to identify working
       resources.  A workspace can also contain a revision selection rule
       that specifies what revision of an arbitrary versioned resource
       should be accessed when the resource is referenced in the context
       of that workspace. A revision selection rule provides revision
       selection based on criteria such as revision name, latest in an
       activity, and membership in a configuration.

       A workspace that does not contain a revision selection rule (and
       therefore can only be used to identify working resources) is called
       a basic workspace.  A workspace that contains a revision selection
       rule (and therefore can be used to specify revision selection) is
       called an extended workspace.

       The following diagram illustrates an extended workspace.

             Foo.htm    Bar.htm     Bing.htm
                         +----+       +----+
                         | V1 |       | V1 |
                         +----+       +----+
                            |            |
                            |            |
          +-----------------|------------|------------------+
          |                 v            v                  |
          |    +----+    +----+       +----+                |
          |    | V1 |    | V2 |       | WR |   Workspace X  |
          |    +----+    +----+       +----+                |
          |                 |                               |
          +-----------------|-------------------------------+
                            |
                            v
                         +----+
                         | V3 |
                         +----+

     Target

       The target of a versioned resource is the working resource or
       revision of that versioned resource that is selected by the current
       workspace.

     Conflict Report

       A conflict report lists all versioned resources for which the
       revision selection rule of a workspace selects multiple revisions
       on different lines of descent. A conflict is resolved by checking
       out one of the selected revisions, modifying the resulting working
       resource so that it represents the logical merge of all selected
       revisions, and then indicating these merges by adding these
       revisions as merge predecessors of the working resource. Checking
       in this working resource creates a new revision that resolves the
       conflict.

     Default Workspace

       A server MUST provide a default workspace that is used to perform
       version selection for versioning-unaware clients. The revision
       selection rule of the default workspace MAY be a modifiable by a
       client.

     Default Target

       The default target of a versioned resource is the target selected
       by the default workspace.

     Configuration

       A configuration selects a particular revision from each of a set of
       versioned resources.  To support basic versioning,  Unlike a workspace, which can select both
       working resources MUST allow and revisions, a configuration can only select
       revisions.  Also, while the revision selected by a workspace for a
       versioned resource can change as a result of a change to the
       versioned resource (such as adding a label), the revision selected
       by a configuration can change only by explicitly modifying the
       configuration itself. Unlike an activity, a configuration can
       select at most one revisions of a given versioned resource.  Unlike
       both a workspace and an activity, a configuration can be versioned.

       The following diagram illustrates a configuration.

              Foo.htm    Bar.htm     Bing.htm

                         +----+
                         | V1 |
                         +----+
                            |
                            |
          +-----------------|-------------------------------+
          |                 |                               |
          |    +----+    +----+       +----+  Configuration |
          |    | V1 |    | V2 |       | V1 |        V1.1    |
          |    +----+    +----+       +----+                |
          |                 |            |                  |
          +-----------------|------------|------------------|
                            |            |
                            v            v
                         +----+       +----+
                         | V3 |       | V2 |
                         +----+       +----+

     Versioned Collection

       A versioned collection is a type of versioned resource that results
       from placing a collection under version control. The members of a
       versioned collection revision are all versioned resources.

     Baselined Collection

       A baselined collection is a special type of versioned collection
       that is associated with a versioned configuration.  A revision of
       the associated versioned configuration is called a baseline of the
       baselined collection. A baseline contains a revision of the
       versioned collection and a revision of every member of every
       versioned collection revision in that baseline.

     History Resource

       A history resource for versioning to occur automatically on
       selected a versioned resource contains all revisions
       of that versioned resource.

  3  WEBDAV VERSIONING SEMANTICS

  3.1 Creating Versioned Resources

       A resource may or may not be versioned. When a resource is created
       by a PUT or MKRESOURCE request, it is commonly created as an
       unversioned resource. Some unversioned resources whenever immutable aspects can be put under
       version control; these are changed, called versionable resources.  After a
       resource is put under version control, it becomes a versioned
       resource, and
       support an initial revision is created that is a copy of the
       versionable resource.  This initial revision becomes the target of
       the versioned resource.

  3.2 Modifying a Versioned Resource

       A versioned resource must be checked out before it can be modified.
       Checking out a versioned resource produces a new resource, called a
       working resource.  A working resource is a modifiable copy of the
       revision, and is identical to an unversioned resource in all
       respects other than that it is associated with a particular
       revision of a particular versioned resource. It may be edited by
       setting its properties defined or contents any number of times. When the
       author is satisfied that the working resource is in this section.

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

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

       Although working resources to update a
       versioned resource addresses the semantics can vary, most versioning systems support lost update problem by ensuring
       that each author is updating his or her own working resource rather
       than a shared resource, and by ensuring that the notion predecessor of indicating the
       updated resource is reliably tracked. Authors can use
       checkout/checkin to register intent to modify a document (check-out) versioned resource
       similar to the way lock /unlock are used in WebDAV level 2, but the
       underlying semantics are very different. With lock/unlock, work is
       serialized and avoiding lost updates depends on clients using the
       lock/unlock protocol.  With checkout/checkin, work can be performed
       in parallel, and then submission the server prevents lost updates by retaining all
       saved states (revisions) of the modified resource.

       A revision may be created as either immutable or mutable. An
       immutable revision cannot be changed and provides a stable
       environment for history management, change recovery, merging, and
       configuration management. A mutable revision is more suitable for
       situations where versioning is treated more informally, and it is
       not necessary or desirable to maintain strict version (check-in).  Typically
       this involves some form of locking (either shared histories, or exclusive).
       As well, many systems support
       to guarantee the ability possibility of backtracking to cancel a check-out or
       undo previous saved
       state. If the revision is mutable, the author may request that a recent check-in.  These options
       subsequent checkin should overwrite the revision that was checked
       out, instead of creating a new revision.  In this case, the
       previous state captured by that revision is lost.  Servers may
       choose to support only immutable revisions, only mutable revisions,
       or both.

  3.3 Naming Revisions: Revision Ids and Labels

       Revision names are available used to distinguish a revision of a versioned
       resource from other revisions of that versioned resource.  A
       revision name is either a revision id or any number of revision
       labels. A revision of a versioned resource is given a server
       assigned revision id when it is created. This revision id acts as a
       persistent, immutable identifier distinguishing this revision from
       all others of the same versioned resource. The revision id cannot
       be changed, assigned to the owner another revision, or reused.

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

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

  3.4 Parallel Development and present Activities

       In a comparison of the versions.

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

  2.1. Discovery

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

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

            Versioning   := "Versioning" ":" URI

       The valid values of same revision at the URI are:

       -  DAV:basicversioning

       -  TBD

       This example shows that same time, work on
       their respective working resources in parallel, check in their
       respective working resources as soon as their changes are complete,
       and then merge the /somefolder resource supports
       versioning.

       >> Request

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

       >> Response

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

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

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

       >> Request

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

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

       >> Response

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

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

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

  2.2. Immutable and Mutable Properties merge problem,
       resources can be checked out in the context of an activity. An immutable property is defined as
       activity captures the set of revisions that form a property that, when changed,
       causes set of related
       changes an author is making to one or more versioned resources.
       Each activity represents a new revision thread of development, where any thread
       can be isolated from other threads to provide a stable environment
       for parallel work. In case parallel work on isolated activities
       results in branches in the underlying versioned resource to be created.
       Likewise, a mutable property is a property that histories,
       the activities can be changed
       without having unified through a new revision created.

       Resources can support both mutable merge operation.

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

       This specification doesn't cover the discovery or management Workspaces

       Resources, working resources, and revisions of
       property mutability.

  2.3. Versioning versioned resources
       are all accessed using a Resource

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

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

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

       >> Request

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

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

       >> Response

       HTTP/1.1 200 OK
       Content-Length: 0

  2.4. Immutable and Mutable Revisions

       By default, the contents of a versioned resource.

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

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

       The DAV:canthaw property indicates if accessed
       consistently by both versioning-aware and versioning-unaware
       clients.

       In order to specify revision selection, a workspace contains a
       revision selection rule. A revision selection rule can be thawed.
       Similarly, the DAV:hasthawed property indicates if specify
       revision names, activities, configurations, or use operators that
       combine several of these rule elements. A revision name selects a
       revision has
       ever been thawed.  Finally, with that name. An activity selects the DAV:isthawed property specifies if latest revision
       that was created in that activity. Configurations select the
       revision is currently thawed (frozen if not).

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

       >>Request

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

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

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

  2.5. Versioning rule elements, and COPY/MOVE

       When applies them in order until the
       first match is found. If there is no matching revision, then a
       resource-not-found status is returned.

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

  3.6 Configurations

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

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

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

  2.6. Sharing

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

  3.7 Versioned Collections

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

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

  2.7. Default Revision

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

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

       Setting the default revision to DAV:none cancels

  4  VERSIONING RESOURCE TYPES AND PROPERTIES

       This section defines the default
       revision.

       >>Request

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

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

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0

       >>Request

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

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

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0

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

  4.1 Property Attributes

       There are several important attributes of the share.

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

  4.1.1 Writeable/Readonly Properties

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

       >>Request

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

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

  2.8. Collection Versioning

       Collections server.

       All properties defined in this document are writeable unless
       explicitly marked as "readonly".

  4.1.2 Immutable/Mutable Properties

       An immutable resource is a resource whose value cannot change. An
       immutable property is a property whose value cannot change when it
       appears on an immutable resource.  A mutable property is a property
       whose value can change, even when it appears on an immutable
       resource.

       All properties defined in this document are immutable unless
       explicitly marked as "mutable".

  4.1.3 Property Resources

       There are various properties whose contents can be versioned just like non-collection resources,
       however, they are only versioned when represented as
       an HTTP resource.  Doing so allows a direct change is made client to use the collection.

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

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

  2.9. Basic Revision Properties

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

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

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

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

  4.2 Resource Properties

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

       DAV:revisionid - resource:

  4.2.1 DAV:author  (immutable) [Core]

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

  4.2.2 DAV:comment  (immutable) [Core]

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

  4.3 Revision Properties

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

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

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

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

       The DAV:predecessor of the resource.

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

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

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

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

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

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

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

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

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

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

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

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

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

       DAV:revisionlabel -

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

       This property allows contains the specification date when the revision was checked in.
       This property is automatically assigned and is formatted using
       ISO8061.

  4.3.8 DAV:working-resources (readonly, collection) [Core]

       This property is a collection of
       textual names the workspaces that refer to contain
       working resources whose DAV:predecessor is this version revision.  The XML
       document for DAV:working-resources contains a description of these
       working resources.

  4.3.9 DAV:history-uuid (readonly) [Core]

       The DAV:history-uuid of the resource. If there
       are multiple labels, they are returned as a comma separated list.
       Labels MUST be unique for revision is the versioned resource.  That is, no two
       revisions DAV:uuid of the same versioned history
       resource can have the same
       DAV:revisionlabel.  As well, DAV:revisionlabel and DAV:revisionid
       properties share the same namespace and there can be no duplicates.
       Servers MAY reserve specific portions of whose DAV:revisions collection contains this namespace and return
       an error if a client uses a reserved name as revision.

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

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

       DAV:mergedfrom - This property specifies is the history resource whose
       DAV:revisions collection contains this revision.  The XML document
       for DAV:history contains a comma separated list description of
       revision ids from which revisions that form the
       line-of-descent to this revision.

  4.3.11 DAV:merge-predecessors (mutable, collection) [Merging]

       The DAV:merge-predecessors collection of a revision is purported to be derived.
       This information is provided and managed contains the
       revisions whose contents were explicitly merged by the client. This client into
       that revision. The client is a
       mutable property.

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

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

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

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

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

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

       DAV:author - binding to that revision.  The creator XML document for
       DAV:merge-successors contains the revision id's of the revision.  This DAV:merge-
       successors.

  4.4 Working Resource Properties

       WebDAV versioning introduces the following additional properties
       for a working resource:

  4.4.1 DAV:workspace (readonly, resource) [Core]

       The DAV:workspace of a working resource is an arbitrary
       string.

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

       DAV:hasthawed - workspace.

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

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

       DAV:isthawed - This read-only that was checked out to create
       this working resource.  The XML document for DAV:predecessor
       contains the revision id of DAV:predecessor.

  4.4.3 DAV:checkin-policy [Core]

       The DAV:checkin-policy property of a working resource indicates how
       this working resource should be checked in. The following are
       defined values for DAV:checkin-policy.  The default value is
       DAV:immutable.

       DAV:identical-abort - the CHECKIN should fail if the revision working
       resource is
       currently thawed (or frozen if not).

       DAV:lastcheckin identical to its DAV:predecessor.

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

  2.10.     Basic Versioning Headers

       The following sub-sections describe working resource is identical to its
       DAV:predecessor.

       DAV:overwrite - the working resource should be copied into its
       DAV:predecessor instead of creating a new version headers revision.

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

  2.10.1.   Revision-Id

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

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

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

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

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

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

       This property allows the specification of criteria that selects applied to a
       specific revision versioned collection with a DAV:baselines
       property).

  4.4.4 DAV:merge-predecessors (collection) [Merging]

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

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

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

  4.5 Workspace Properties

       WebDAV versioning introduces the following additional properties across all
       for a workspace:

  4.5.1 DAV:working-resources (readonly, collection) [Core]

       The DAV:working-resources collection contains the versioned
       resources that are checked out into this workspace. The XML
       document for DAV:working-resources contains a description of these
       working resources.

  4.5.2 DAV:revision-selection-rule  [Core]

       The DAV:revision-selection-rule of a workspace can contain an XML
       document that describes how revision selection will be performed in
       that workspace. The working resources checked out into a workspace
       take priority over revisions selected by the revision selection
       rule, thus target of a versioned resource.

  2.10.2.   Branch-Id

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

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

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

  2.10.3.   Override-Checkin

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

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

  2.10.4.   Revision-Path

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

       The BNF for this header is as follows.

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

       >>Request

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

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

  3. CHECKING OUT/IN RESOURCES

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

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

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

  3.1. Checkout

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

  4.5.3 DAV:label [Core]

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

           Revisions label.

  4.5.4 DAV:activity [Activity]

       The DAV:activity property of foo.htm:  V1

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

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

  4.6 Activity Properties

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

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

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

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

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

       Clients can optionally request locks revision selection behavior of that activity when
       it is used in a revision selection rule.  The purpose of this
       property is to be taken as part identify other activities that are a prerequisite to
       this activity.  The XML document for DAV:required-activities
       contains the URL's of these activities.

  4.6.3 DAV:workspace (resource) [Activty]

       The DAV:workspace property of an activity contains the
       CHECKOUT operation. workspace
       that currently has that activity as its DAV:current activity.  This
       implies that at most one workspace can be working in a given
       activity at a time.  If any working resource of a workspace is
       checked out into a given activity, the locks cannot DAV:workspace of that
       activity can only be obtained, the CHECKOUT
       operation MUST fail. that workspace.  The following table identifies XML document for
       DAV:workspace contains the different
       lock options:

            Lock      Tags Used       Description
            Target    (DAV: assumed)

            working   wrlocktype,     Limits access to URL of the workspace.

  4.7 Configuration Properties

       WebDAV versioning introduces the following properties for a
       configuration:

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

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

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

            versioned vrlocktype,     Blocks CHECKOUT/INs against any
            resource  vrlockscope     revision
       that configuration.  The XML document for DAV:roots contains the
       URL's of these versioned resources.

  4.8 Versioned Collection Properties

       WebDAV versioning introduces the following additional properties
       for a versioned
                                      resource. collection:

  4.8.1 DAV:baselines (resource) [Baseline]

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

       >>Request

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

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

       >>Response

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

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

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

  4.9 History Resource Properties

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

  4.9.1 DAV:uuid (readonly) [Core]

       The DAV:uuid is required.

  3.2. Checkin

       When an identifier assigned to a history resource by the client
       server. A history resource cannot be given a DAV:uuid that has completed changes been
       given to any other history resource, even a history resource and wishes it
       to become part that
       has been deleted.

  4.9.2 DAV:revisions (readonly, collection) [Core]

       The DAV:revisions collection of a history resource contains all
       revisions of that history resource, where the name of a revision history, the client must check in
       the resource.  This DAV:revisions collection is performed using its DAV:revision-id. If a revision
       id contains a URL reserved character, that character is escaped in
       the CHECKIN method against DAV:revisions name.  The XML document for DAV:revisions
       contains the working copy. URL's of  the revisions.

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

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

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

       >>Request

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

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

       >>Response

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

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

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

  3.3. Cancelling Checkout

       If a client chooses DAV:revision-labels collection.

  5  VERSIONING METHODS

  5.1 Existing Methods

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

       >>Request

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

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0

  3.4. Enumeration

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

  4. BRANCHING RESOURCES

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

  5.1.1 GET

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

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

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

  5.1.2 BIND

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

  5.1.3 PUT

       When PUT is no way applied to change this.

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

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

       >>Request

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

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

       >>Response

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

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

  5. RESOURCE REPORTS

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

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

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

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

       Clients have specified the following merge annotations:

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

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

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

       -  V1 (the initial revision was created)

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

       -  V1 (a client changed the default revision)

       -  V3 (an updated revision was created)

       Also, the following labels have been specified:

       -  V2: Test1

       -  V1.1: Test2, Good

       -  V1.2: Tested

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

  5.1. Available Reports

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

       >>Request

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

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

       >>Response

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

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

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

  5.2. Default History

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

       Clients can specify the limit parameter fail.

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

       >>Request

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

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

       >>Response

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

  5.3. Active Checkouts

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

       >>Request

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

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

       >>Response

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

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

  5.4. Direct Lineage

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

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

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

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

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

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

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

       >>Response

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

  5.5. Full Lineage

       Resources SHOULD support

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

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

  5.1.5 PROPPATCH

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

       Clients can specify a versioned resource, its behavior is
       similar to that of PUT. In particular, when PROPPATCH is applied to
       an immutable property of a revision, it MUST fail unless the limit parameter
       revision has a DAV:auto-version property.

  5.1.6 DELETE

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

       >>Request

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

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

       >>Response

       ...

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

  6. CONFIGURATION BASICS

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

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

       -  Dynamic: A dynamic configuration
       that workspace are deleted.

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

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

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

  5.1.7 COPY

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

       A configuration can be derived from another configuration.  That is, only the new configuration selected
       revision is based on the versions in copied, not the "parent"
       configuration.  Optionally, derived configurations can
       automatically inherit new versions in full version history.

       When a COPY request is applied to a workspace, activity, or history
       resource, it fails.

  5.1.8 MOVE

       When MOVE is applied to a versioned resource, the parent configuration
       (assuming there are no conflicts).  However, MOVE request MUST
       fail unless a configuration binding to that versioned resource can be
       derived from created at most one other configuration.

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

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

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

  5.1.9 LOCK

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

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

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

  6.1. Discovery

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

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

       A write lock on a history resource supports configurations.

       >> Request

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

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

       >> Response

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

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

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

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

  5.1.10 OPTIONS

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

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

       Clients create BNF for the Versioning header:

            Versioning    := "Versioning" ":" Ver-type-list
            Ver-type-list := Ver-type | (Ver-type-list "," Ver-type)
            Ver-type      := "Core"
                         | "Activity"
                            | "Merging"
                         | "Configuration"
                            | "Versioned-Collection"
                            | "Baseline"

  5.2 New Methods

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

  5.2.1 MKRESOURCE

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

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

                 Tag                  Description

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

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

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

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

                                      later section).

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

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

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

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

       MKRESOURCE can be /cfgs.

       >>Request

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

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

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

       >>Response

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

  6.3. Access Using Configurations

       Configurations are maintained as used to create a special new activity in a repository
       DAV:activities collection.
       Configurations maintain referential members When MKRESOURCE is used to all revisions that
       are part create a
       repository from an existing versionable collection, every member of
       that versionable collection is also placed under version control as
       a history resource in that repository.

       Status Codes:

       201 (Created) - The new resource has successfully been created.

       207 (Multi-Status) - If any error was encountered in the configuration.  Consequently, one approach to
       enumerating the contents creation
       of a configuration the resource, this response is to generated. Status codes defined
       for use PROPFIND with PROPPATCH (defined in section 8.2.1 of [RFC2518])
       SHOULD be used to
       discover represent error cases in setting the contents value of the collection.

       Alternatively, clients can request a specific
       properties.

       TBD - Explain effect on existing resource from types

       TBD - Give request/response example

  5.2.2 REPORT

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

       >>Request

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

  6.4. Deleting Configurations

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

       >>Request

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

  6.5. Resolution Queues

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

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

       Configurations track and maintain method returns a
       list of issues that need available reports.

       TBD - More details on error codes

       TBD - Give request/response example

  5.3 New Versioning Methods

       WebDAV versioning introduces three new methods to support the
       checkout/checkin versioning model.

  5.3.1 CHECKOUT

       A CHECKOUT request can only be
       resolved as a result of actions.  These lists are referred applied to as
       resolution queues.  Clients can a versioned resource.
       When a CHECKOUT request the resolution issues and
       react accordingly.  The configuration will continue is applied to report the
       condition until it a versioned resource whose
       target is resolved.

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

       >>Request

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

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

       >>Response

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

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

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

  6.6. Configuration Properties

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

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

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

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

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

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

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

  6.7. Headers

       To support configurations, two new headers are introduced no Target-Selector header, the DAV:workspace for
       that working resource is allocated by the server. The body of the
       CHECKOUT request can be used with a variety to initialize the DAV:checkin-policy
       of the DAV and HTTP methods.  The following
       list identifies these headers:

       Configuration-Id - This header working resource.

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

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

       For workspace configurations, this can be specified to set default
       revisions per-configuration, enumeration the DAV:activity of checkouts/checkins
       against the current workspace.  If DAV:activity is
       not set, a specific configuration, or server with activity support automatically assigns an
       activity to establish locks specific the new working resource.  The CHECKOUT request fails
       if neither DAV:activity nor DAV:label is set.

       TBD - Failures must include "policy not supported"

       TBD - More details on error codes

       TBD - Give request/response example

  5.3.2 CHECKIN

       When a CHECKIN request is applied to a configuration.

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

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

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

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

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

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

  7. CONFIGURATION REPORTS

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

       >>Request

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

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

       >>Response

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

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

  7.1. Configuration Derivation

       Configurations MUST support the DAV:configurationderivation report.
       This enumerates put under version
       control as well.

       TBD - More details on error codes

       TBD - Explain effect on existing resource types

       TBD - Give request/response example

  5.3.3 UNCHECKOUT

       When an UNCHECKOUT request is applied to a versioned resource whose
       target is a working resource, the full derivation DAV:workspace of a configuraiton.  Note that working
       resource is deleted from the limit parameter can be specified to limit the number DAV:working-resources collection of items
       returned.  By definition
       the order DAV:revision of the configurations is
       immediate predecessor.

       >>Request

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

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

       >>Response

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

  7.2. Configuration Merge Graph

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

       >>Request

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

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

       >>Response

       ...

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

  8. DYNAMIC CONFIGURATIONS

       Dynamic configurations provide a mechanism to identify all
       revisions that match specific criteria.  For example, "all
       revisions CHECKOUT request that have
       produced the label Beta1". working resource.

       TBD - More details on error codes

       TBD - Explain effect on existing resource types

       TBD - Give request/response example

  5.4 New Versioning Headers

  5.4.1 Target-Selector

       The dynamic configuration is Target-Selector header contains a view onto the resources and workspace URL or a revision
       name. The Target-Selector header is updated automatically as resources
       and revisions are created, deleted, and modified.

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

       >>Request

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

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

       >>Response

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

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

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

       >>Request

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

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

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

  6  THE DAV VERSIONING XML ELEMENTS

  6.1 Revision Selection Rule Elements

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

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

       -  DAV:or - Any
       a particular revision of that versioned resource or select no
       revision of that versioned resource.  If it selects a particular
       revision, it may also detect a conflict (e.g. when there were
       multiple candidates for selection).  A document describing the included tags MUST be true to select

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

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

  6.1.1 DAV:rsr-configuration

       A DAV:rsr-configuration element contains the included URL

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

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

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

       -  DAV:configurationid - The configuration MUST be selected.  A
       DAV:rsr-configuration element never generates a conflict.

  6.1.2 DAV:rsr-activity-latest

       A DAV:rsr-activity-latest element contains the specified
          value

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

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

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

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

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

  9. WORKSPACE CONFIGURATIONS

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

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

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

  6.1.3 DAV:rsr-label

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

  6.1.4 DAV:rsr-revision-id

       A DAV:rsr-revision-id element contains a revision id.  If a
       revision of the V1 and versioned resource has that revision id, that
       revision is selected by the V2 revisions refer to DAV:rsr-revision-id element; otherwise,
       no revision is selected.  A DAV:rsr-revision-id element never
       generates a conflict.

  6.1.5 DAV:rsr-latest

       A DAV:rsr-latest element selects the same revision of that versioned resource.
       This allows history and reports to be generated across workspaces.

  9.1. Managing Configuration Content

       Clients need to be able to access and manage
       resource with the contents latest DAV:creationdate.  A DAV:rsr-latest
       element never generates a conflict.

  6.1.6 DAV:rsr-or

       A DAV:rsr-or element contains a sequence of RSR elements. The
       behavior of a
       configuration.  This DAV:rsr-or element is done using several different DAV methods.

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

  6.1.7 DAV:rsr-merge

       A DAV:rsr-merge element contains a sequence of RSR elements.  If
       one of the elements in this sequence selects a new versioned resource being
       created.

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

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

  9.2. Default Workspace Configurations

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

       >>Request

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

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

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0

  10.  CHECKIN SETS

       Clients may desire
       conflicts.

  6.2 Report Elements

  6.2.1 Conflicts Report

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

  6.2.1.1 DAV:conflicts-report-request

       A DAV:conflicts-report-request contains the checkin set on all checkin (or change)
       requests.  The server automatically creates URL of a "share" to workspace and
       the URL of a versioned resource.

  6.2.1.2 DAV:conflicts-report-response

       A DAV:conflicts-report-response contains a DAV:conflict element for
       each versioned resource for which the newly
       created revision selection rule
       specified in the identified collection.

       Checkin sets are specific to DAV:conflicts-report-request produced a configuration and are created using
       the MKCHECKINSET method. conflict.
       The DAV:checkinsetroot property on DAV:conflict element identifies the versioned resource which
       generated a
       configuration specifies conflict, as well as information about how to resolve
       the conflict (such as the revisions that would need to be merged).

  6.2.1.3 DAV:conflict

       The DAV:conflict element contains the URL of a collection where checkin sets versioned resource
       for which the configuration exist.  This can be used for discovery or
       creation.  If revision selection rule generated a configuration doesn't support checkin sets, then
       this property will be empty.

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

       >>Request

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

       >>Response

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

  6.2.1.4 DAV:common-ancestor

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

       >>Request

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

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

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

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

  6.2.1.5 DAV:contributor

       The DAV:contributor element identifies a
       checkin set is created, this property revision that is defaulted to 0.  Note selected
       by an element of the revision selection rule but that is not an
       ancestor of any of the other revisions selected by the revision
       selection rule.

  6.2.2 Compare Report

  6.2.2.1 DAV:compare-report-request

       A DAV:compare-report-request contains the URL's of two resources MAY choose to disallow clients from setting this property
       to 0 once a client has set it of
       the same type.

  6.2.2.2 DAV:compare-report-response

       A DAV:compare-report-response identifies the differences between
       two resources of the same type.  These differences are indicated by
       appropriate DAV:added, DAV:deleted, and DAV:changed elements.

       In particular, if a DAV:compare-report-request is applied to 1. two
       configuration revisions.  The following properties MUST be supported on all resources:

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

  6.2.2.3 DAV:added

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

  11.  VERSION MAPPING

       This specification defines headers to specify configurations and first.

  6.2.2.4 DAV:deleted

       A DAV:deleted element identifies something that appears in the
       first resource versions.  However, there are times but not in the second.

  6.2.2.5 DAV:changed

       A DAV:changed element identifies something that is in both
       resources but that is in some way different in the two resources.
       For example, when clients require two configurations are being compared, a
       single URI for when working against
       DAV:changed element can identify a versioned resource, a versioned
       collection, or an activity.  A versioned resource has changed if
       the configurations select different revisions of that versioned
       resource.  A versioned collection has changed if the configurations
       select different revisions or versions.
       Version mapping support allows servers to create namespaces different baselines of that
       map to versioned
       collection.  An activity has changed if  both configurations and versions.

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

  7  INTERNATIONALIZATION CONSIDERATIONS

       To delete be supplied.

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

  11.1.     Discovery

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

  8  SECURITY CONSIDERATIONS

       To be supplied.

  9  SCALABILITY

       To be supplied.

  10 AUTHENTICATION

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

  11 IANA CONSIDERATIONS

       This document uses the request body namespace defined by [RFC2518] for XML
       elements.  All other IANA considerations mentioned in [RFC2518]
       also applicable to DAV Versioning.

  12 INTELLECTUAL PROPERTY

       The following notice is copied from RFC 2026 [RFC2026], section
       10.4, and describes the DAV:verinfo tag, clients can obtain position of the supported map
       styles.

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

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

       >> Request

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

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

       >> Response

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

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

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

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

       >> Request

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

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

       >> Response

       HTTP/1.1 201 CREATED
       Context-Length: 0

  11.3.     Mapping Resource Versions

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

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

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

       The following diagrams illustrate possible mappings:

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

        V1                          Primary  Test           Primary
        |                              |       |               |
        +----+--------+                V1     V1.1             +------ Test
        |    |        |                |       |               |         |
        V2   bar.htm  V1.1             V2     V1.2             V1       V1.1
        |             |                |                       |         |
        +----+        +-----+          V3                      V2       V1.2
        |    |        |     |                                  |
        V3   bar.htm  V1.2  bar.htm                            V3
        |             |
        bar.htm       bar.htm

       In IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights which may cover technology that may be required to practice
       this standard.  Please address the example below, a new namespace information to the IETF
       Executive Director.

  13 ACKNOWLEDGEMENTS

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

       >> Request

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

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

       >> Response

       HTTP/1.1 201 CREATED
       Context-Length: 0

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

  12.  THE DAV VERSIONING GRAMMAR

       To be supplied - Describe Delta-V design
       team: Jim Amsden (IBM, DeltaV Chair), Geoffrey Clemm (Rational),
       Bruce Cragun (Novell), David Durand (INSO), Chris Kaler
       (Microsoft), Jeff McAffer (OTI), Bradley Sergeant (Merant), and detail the DTDs

  13.  INTERNATIONALIZATION CONSIDERATIONS

       To be supplied.

  14.  SECURITY CONSIDERATIONS

       To be supplied.

  15.  SCALABILITY

       To be supplied.

  16.  AUTHENTICATION

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

  17.  IANA CONSIDERATIONS

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

  18.  COPYRIGHT

       To be supplied.

  19.  INTELLECTUAL PROPERTY us by the authors of the WebDAV and HTTP protocols upon which
       this protocol is layered, and the invaluable feedback from the
       WebDAV and DeltaV working groups.

  14 INDEX

       To be supplied.

  20.

  15 REFERENCES

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

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

       [RFC2068] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T.
       Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
       U.C. Irvine, DEC, MIT/LCS, January 1997.

       [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels." RFC 2119, BCP 14. Harvard University. March,
       1997.

       [WebDAV]

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

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

  21.  AUTHOR'S - WEBDAV", RFC
       2518, Microsoft, UCIrvine, Netscape, Novell, February. 1999.

       [AdvCol] http://www.ietf.org/internet-drafts/draft-ietf-webdav-
       collection-protocol-03.txt

       [VerGoal] http://www.ietf.org/internet-drafts/draft-ietf-webdav-
       version-goals-02.txt

  16 AUTHORSĘ ADDRESSES

       Geoffrey Clemm
       Rational Software
       20 Maguire Road
       Lexington MA 02421-3104
       Email: geoffrey.clemm@rational.com

       Christopher Kaler, Editor Kaler
       Microsoft
       One Microsoft Way
       Redmond WA, WA 9085-6933
       Email:ckaler@microsoft.com

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

       Geoff Clemm
       Rational
       Email: gclemm@atria.com

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

       David Durand
       Email: dgd@cs.bu.edu

       Bradley Sergeant
       MicroFocus
       Email: bradley_sergeant@intersolv.com

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

  22. ckaler@microsoft.com

  17 OPEN ISSUES

       The following list identifies key open issues against this
       document:

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

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

       .  What additional resource branching support is needed?

       .  Schema discovery is an issue.  For example, how

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

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

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

       @ TODO: DTDs and semantics of properties

       @ TODO: Lots of details

       @ ISSUE: How are policies discovered?

       @ ISSUE: Does Versioning have to be
          specified.

  23.  CHANGE HISTORY

       Sep 28, 1998

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

       Oct 24, 1998

       Incorporate feedback from October 01-02 working group meeting.

       Jan 20, 1999

       Incorporate feedback from December 1998 working group meeting. a header, or can it be the body
          of the OPTIONS response?

       @ ISSUE: Couldn't MKRESOURCE be handled just by allowing PROPPATCH
          to be applied to a null resource?