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

   Expires April 26, June 20, 1999                 January 20, 1999
                                               October 26, 1998

                       Versioning Extensions to WebDAV
  Status of this Memo

       This document is an Internet draft. Internet drafts are working
       documents of the Internet Engineering Task Force (IETF), its areas
       and its working groups. Note that other groups may also distribute
       working information as Internet drafts.

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

       To learn the current status 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
       can be found at URL: http://www.ietf.org/

       Distribution of this document is unlimited.  Please send comments
       to the mailing 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 at
       <URL:http://www.w3.org/Archives/Public/ietf-dav-versioning/>.

  Abstract

       This document specifies a set of methods, headers, and content-
       types composing DAV Versioning extensions, an application of the
       HTTP/1.1 protocol to version DAV resources.

                              Table of Contents

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

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

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

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

  2.BASIC VERSIONING.......................................5
  2.1. Discovery...........................................5
  2.2. Immutable DAV ...................................4
  1.3.Terms .................................................4
  1.4.Definitions ...........................................4
  1.5.Notational Conventions ................................5

  2.  BASIC VERSIONING ......................................5
  2.1.Discovery .............................................6
  2.2.Immutable and Mutable Properties....................6
  2.3. Automatic Versioning................................7
  2.4. Properties ......................7
  2.3.Versioning a Resource Properties.................................7
  2.5. .................................8
  2.4.Immutable and Mutable Revisions .......................8
  2.5.Versioning and COPY/MOVE ..............................9
  2.6.Sharing ...............................................9
  2.7.Default Revision .....................................10
  2.8.Collection Versioning ................................11
  2.9.Basic Revision Properties ............................11
  2.10. Basic Versioning Headers............................8
   2.5.1.Versioning-Support................................8
   2.5.2.Revision-Id.......................................8
   2.5.3.Merged-From.......................................9
  2.6. Checking Out/In Resources...........................9
   2.6.1.Checkout..........................................9
   2.6.2.Branching Resources..............................11
   2.6.3.Checkin..........................................12
   2.6.4.Undo Checkout....................................13
   2.6.5.Enumeration......................................13
  2.7. Default Revision...................................13
  2.8. Sharing............................................14
  2.9. Collection Versioning..............................15
   2.9.1.Default Revisions................................16
   2.9.2.Headers..........................................16
   2.9.3.Properties.......................................16
  2.10.Resource Reports...................................17
   2.10.1.Example.........................................17
   2.10.2.Default History.................................18
   2.10.3.Direct Lineage..................................19
   2.10.4.Full Lineage....................................20

  3.CONFIGURATIONS........................................21
  3.1. Discovery..........................................22
  3.2. Creating Configurations............................22
  3.3. Configuration Properties...........................24
  3.4. Headers............................................25
  3.5. Deleting Configurations............................25
  3.6. Managing Configuration Content.....................25
   3.6.1.Access 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.  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......................26
   3.6.2.Adding Resources to a Configuration..............26
   3.6.3.Removing Resources from a Configuration..........26
  3.7. Workspace Configurations...........................27
   3.7.1.Default Workspace Configurations.................27
   3.7.2.Synchronizing Worksapce Configurations...........27
   3.7.3.Condensing Workspace Configurations..............29
  3.8. Configuration Reports..............................29
   3.8.1.Configuration Derivation.........................30
   3.8.2.Configuration 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........................31
  3.9. Resolution Queues..................................31
   3.9.1.Discovery........................................32
   3.9.2.Obtaining Resolutions............................32
   3.9.3.Processing Resolution Items......................32
  3.10.Checkin Sets.......................................33
   3.10.1.Discovery.......................................33
   3.10.2.Usage...........................................34

  4.VERSION MAPPING.......................................34
  4.1. Discovery..........................................35
  4.2. Graph ............................34

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

  9.  WORKSPACE CONFIGURATIONS .............................37
  9.1.Managing Configuration Content .......................37
  9.2.Default Workspace Configurations .....................38

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

  11. VERSION MAPPING ......................................39
  11.1. Discovery ..........................................40
  11.2. Mapping Configurations.............................35
  4.3. Configurations .............................41
  11.3. Mapping Resource Versions..........................36

  5.MISCELLANEOUS FUNCTIONS...............................37
  5.1. Destroy............................................37
   5.1.1.Discovery........................................37
   5.1.2.Usage............................................37
   5.1.3.Headers..........................................38
   5.1.4.Properties.......................................38

  6.THE Versions ..........................41

  12. THE DAV VERSIONING GRAMMAR............................38

  7.INTERNATIONALIZATION CONSIDERATIONS...................38

  8.SECURITY CONSIDERATIONS...............................38

  9.SCALABILITY...........................................38

  10. AUTHENTICATION......................................38

  11. IANA CONSIDERATIONS.................................38

  12. COPYRIGHT...........................................39 GRAMMAR ...........................42

  13. INTELLECTUAL PROPERTY...............................39 INTERNATIONALIZATION CONSIDERATIONS ..................42

  14. REFERENCES..........................................39 SECURITY CONSIDERATIONS ..............................43

  15. AUTHOR'S ADDRESSES..................................39 SCALABILITY ..........................................43

  16. OPEN ISSUES.........................................39 AUTHENTICATION .......................................43

  17. IANA CONSIDERATIONS ..................................43

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

  19. INTELLECTUAL PROPERTY ................................43

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

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

  22. OPEN ISSUES ..........................................44

  23. CHANGE HISTORY......................................40 HISTORY .......................................45
  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] 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 clients,

       -  Basic versioning for DAV Versioning-aware clients,

       -  File branching for basic parallel development, and

       -  Configuration support for sophisticated  parallel development.

  1.2. Relationship to DAV

       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 and histories.

  1.3. Terms

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

  1.4. Definitions

       The section defines several terms that are used throughout the
       document specific to DAV versioning.

       Versioned Resource - This refers to a resource that is subject to
       versioning (independent of any specific version)

       Revision - This refers to a specific version of a versioned
       resource

       Revision History - This refers to the set of changes to a versioned
       resource
       Working Resource - This refers to a resource that is an
       intermediate revision of a versioned resource.  That is, the
       versioned resource has been "checked out" and this is where changes
       are made until it is ready to be "checked in".  Note that working
       resources are not versioned.

       Revision Thread - This refers to a sequence of revisions that have
       been branched for a specific purpose.

       Line of Descent - This refers to the sequence of revisions that
       have occurred from the initial revision to a specified revision.

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

       The base level of versioning support defined by this specification
       includes both automatic versioning and the basic versioning
       properties defined for all resources.  To support basic versioning,
       resources MUST allow for versioning to occur automatically on
       selected resources whenever immutable aspects are changed, and
       support the properties defined in this section.

       Resources that support DAV:versioning MUST also provide additional
       versioning semantics for versioning-aware clients.  This section
       describes these new semantics which include enhancements to
       existing DAV methods, new headers, and a new versioning-specific
       method.
       methods.

       Although the semantics can vary, most versioning systems support
       the notion of indicating intent to modify a document (check-out)
       and then submission of the modified version (check-in).  Typically
       this involves some form of locking (either shared or exclusive).
       As well, many systems support the ability to cancel a check-out or
       undo a recent check-in.  These options are available to the owner
       or to the Administrator.

       Users can generally enumerate the current check-outs although they
       may not be able to determine the user in all cases.  Likewise,
       users can review check-ins to see the change history.  Most systems
       allow users to select different versions from the change history
       and present a comparison of the versions.

       Note that locks are not covered in this specification as they are
       addressed by [WebDAV].

  2.1. Discovery

       The OPTIONS method allows the client to discover if a resource
       supports versioning.  The client issues the OPTIONS method against a resource named by
       the Request-URI. This is a normal invocation presence of OPTIONS defined Versioning in
       [RFC2068] with an extension.  If the client includes the Verify-
       Extension header, then the reply includes additional information
       beyond that which is defined in [RFC2068].

       Using this response
       header with the extension DAV:versioning, clients can
       determine what versioning indicates support is available. for DAV versioning.  This header indicates
       the level of support.

       The following defines the BNF for the Verify-Extension Versioning header:

            Verify-Extension

            Versioning   := "Verify-Extension" "Versioning" ":" URI-list
            URI-list            := URI | (URI-list "," URI)

       The valid values of the URI are:

       -  DAV:basicversioning

       -  TBD

       This example shows that the /somefolder resource supports
       versioning.

       >> Request

       OPTIONS /somefolder/ HTTP/1.1
       Verify-Extension: DAV:versioning
       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, PIN, MKREF MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
       MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, PIN, MKREF
       Verify-Extension: DAV:versioning
       Versioning-Support: MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Versioning: DAV:basicversioning
       Content-Length: 0

       The Verify-Extension header in the reply indicates that the server
       understood the

       Since some aspects of DAV versioning require clients to know
       additional information, clients can include a request with Verify-Extension and body that
       DAV:versioning is supported.  As well, the Versioning-Support
       header indicates the level of
       specifies that DAV versioning support provided. information is desired.  The BNF
       for this header
       information is provided later 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 the tags returned are described throughout this document.
       specification.

  2.2. Immutable and Mutable Properties

       An immutable property is defined as a property that, when changed,
       causes a new revision of a versioned resource to be created.
       Likewise, a mutable property is a property that can be changed
       without having a new revision created.

       Resources can support both mutable and immutable properties
       although there MAY be restrictions that the mutability is
       consistent across all resources.

       This specification doesnÆt doesn't cover the discovery or management of
       property mutability.

  2.3. Automatic Versioning a Resource

       By default, a resource may not be subject to versioning.  This can
       be discovered by examining the DAV:isversioned property.  To place
       a non-versioned resource under version control, clients use the
       VERSION method and specify the URI of the resource to version.
       Note that if the specified resource is a collection, then the Depth
       header is used to identify the scope of the operation.  A depth of
       infinity is assumed by default.

       The DAV:autoversion DAV:isautoversioned property indicates if a resource is
       automatically versioned when any immutable aspect of it is changed.
       Resources with automatic versioning allow HTTP/1.1 clients to have
       changes versioned without explicit versioning commands.

       Automatic versioning includes the following methods:

       - Updates via  This
       applies to any method that modifies a resource (e.g., PUT, MKCOL,
       COPY, MOVE, or DELETE

       - Immutable properties updates via PROPPATCH

  2.4. Resource Properties

       For resources that support versioning, they MUST support DELETE, PROPPATCH, ...)

       Using the
       following properties using DAV:versioningenabled and DAV:autoversioning tags,
       clients can establish the "DAV:" namespace.  Note that 0/1 is
       used as a FALSE (0) / TRUE (1) indicator.

       DAV:isversioned - 0/1 to indicate if 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 resource is versionable.
       Note that this can be implemented as contents of a read-only property.

       DAV:autoversion - 0/1 to indicate if the resource revision are immutable.  That is,
       once a revision is automatically
       versioned when modified.  Note that this can created, it cannot be  implemented altered.  However, in many
       document management systems this
       as a read-only property.

       DAV:revisionid - This is a read-only property not the case.  To address these
       scenarios, the THAW/FREEZE methods are introduced.  Note that returns a server
       determined id
       support for this specific 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 can alter the immutable
       aspects of the resource.  Every
       revision of a resource will  The FREEZE method indicates that all
       changes have a unique DAV:revisionid.  A been made and the revision id may should be marked immutable
       again.

       The DAV:canthaw property indicates if a URI or it may revision can be an arbitrary server-defined
       string.  However, it cannot contain thawed.
       Similarly, the "," character.  Because it
       is not required to be DAV:hasthawed property indicates if a URI, revision has
       ever been thawed.  Finally, the DAV:revisionuri DAV:isthawed property is
       required to obtain a URI for specifies if
       the specific revision of the resource.

       DAV:vresourceid - This is a read-only property that returns a
       server determined id for currently thawed (frozen if not).

       The following example shows the versioned resource.  That is, all
       revisions use of the resource have the same DAV:vresourceid.  This MUST
       be preserved over MOVE requests.

       DAV:previousversionids - This 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 and COPY/MOVE

       When a COPY method is issued against a read-only property that returns
       the server defined id for versioned resource or
       revision, only the previous "current" revision 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 a comma-separated list.
       Note that this property returns previous revisions that versioned resource or
       the server
       determines. specified revision is copied to the specified destination.
       That is, this does not include user identified merged
       revisions.

       DAV:nextversionids - This the entire history is NOT copied.

       When a read-only property that returns the
       server defined id for the next revision of the resource.  An empty
       value indicates that there MOVE method is no subsequent revision.  Note that
       there could be multiple next revisions.  If there are multiple
       revisions, they are returned as issued against a comma-separated list.  Note that
       this property returns successor revisions that versioned resource the server
       determines.
       "move" SHOULD be represented in the revision history.  That is, this does not include user identified merged
       revisions.

       DAV:revisionuri - This is a read-only property that returns
       MOVE operation CANNOT be represented as a delete and an add.  A
       MOVE operation cannot be issued against a URI
       for this specific revision.

       DAV:revisiondisplayname - This is

  2.6. Sharing

       Many versioning systems today provide the ability to have a read-only property that returns given
       resource visible in multiple parts of the namespace.  In these
       situations, a string that clients may use to display this revision.  This resource is
       often a more user friendly string than DAV:revisionid.

       DAV:revisionlabel - This property allows the specification of
       textual names that refer to this version of the resource. If there
       are multiple labels, they are returned as a comma separated list.
       Labels MUST be unique for the versioned resource. shared.  That is, no two
       revisions of changes to the same versioned resource can have the same
       DAV:revisionlabel.  As well, DAV:revisionlabel, DAV:revisionid, and
       DAV:vresourceid
       are visible to all share the same namespace and there can be no
       duplicates.  Servers MAY reserve specific portions of versions.

       The WebDAV Advanced Collections working group addresses this
       namespace and return an error if a client uses need
       with direct referential members.  Support for direct referential
       members is required for DAV versioning.

  2.7. Default Revision

       If a reserved name as Revision-Id (or Branch-Id) header is not specified when
       referring to a resource, then the tip (latest) revision label.  This property MUST be mutable.

       DAV:mergedfrom - This property specifies (from the
       primary branch) is used, unless a comma separated list of
       revision ids from which this default revision is purported to be derived.
       This information is provided and managed by the client.

       DAV:revisioncomment - This property contains has been
       identified.  To mark a client-defined
       property associated with the revision.  This specified revision as a mutable property.

  2.5. Basic Versioning Headers

       The following sub-sections describe the new version headers default revision,
       clients use the SETDEFAULT method.  Note that
       MUST be supported for resources PUT or CHECKIN will
       remove any default version.  Also note that support DAV:versioning.

  2.5.1.    Versioning-Support

       The Versioning-Support header specifies branching a resource
       has no effect on the type default revision of versioning that the resource, even if the
       default revision is available.  The following BNF defines this header.

            Versioning-Support := "Versioning-Support" ":" URI-list

       To support versioning, branched.  If the URI list default is removed, the
       default revision is the tip revision of the initial (primary)
       branch of the versioned resource.

       Setting the default revision to DAV:none cancels 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 resource is shared, servers MUST include
       DAV:basicversioning.  Later sections support the ability to set
       different default revisions at each point of this document specify other
       optional support.

  2.5.2.    Revision-Id the share.

       Clients can determine the default revision 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 can be versioned just like non-collection resources,
       however, they are only versioned when a direct change is made to
       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-Id Revision-Path header is used to identify a specific revision revisions
       that are part of a
       versioned the "path" to the resource.  This header servers
       as an alternative to "URL munging".  This header can be specified
       on all methods and qualifies the resource named in the method.  As well, this
       header

  2.9. Basic Revision Properties

       For resources that support versioning, they MUST support the
       following properties using the "DAV:" namespace.  Note that 0/1 is included in all replies
       used as a FALSE (0) / TRUE (1) indicator.

       DAV:isversioned - 0/1 to indicate if the revision of the
       versioned resource used or created.

       The BNF for this header is versionable.
       Note that this can be implemented as follows.

            Revision-Id := "Revision-Id" ":" RID
            RID         := "*" | ANY
       Clients a read-only property.

       DAV:autoversion - 0/1 to indicate if the resource is automatically
       versioned when modified.  Note that this can specify be implemented this as
       a read-only property.

       DAV:revisionid or any of the
       DAV:revisionlabel values to refer to - This is a read-only property that returns a server
       determined id for this specific revision of the resource.

       The use of Revision-Id: * is only permitted with PROPFIND to obtain
       properties across all revisions  Every
       revision of a versioned resource.

  2.5.3.    Merged-From

       When clients use resource branching, they will likely need to
       perform merge operations. have a unique DAV:revisionid.  A merge is the process by which changes
       from different versions are combined to produce
       revision id may be a new version.  It URL or it may be an arbitrary server-defined
       string.  However, it cannot contain the "," character.  Because it
       is likely that clients will want not required to track this semantic
       information.  When be a URL, the Merged-From header DAV:revisionurl property is specified on
       required to obtain a PUT,
       UNLOCK, or PROPPATCH method, it indicates URI for the specific revision (or
       revisions) from which of the change resource.

       DAV:vresourceid - This is derived.  The a read-only property that returns a
       server tracks
       this information and makes it available in determined id for the DAV:mergedfrom
       property.

            Merged-Item := ANY
            Merged-List := Merged-Item | (Merged-List "," Merged-Item)
            Merged-From := "Merged-From" ":" Merged-List

       >>Request

       PUT /foo/bar HTTP/1.1
       Host: www.foobar.com
       Merged-From: VER:FDHJ43058
       Content-Type: text/html
       Content-Length: xxxx

       ...

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0

  2.6. Checking Out/In Resources

       For versioning-aware clients, more advanced requests allow them to
       perform specific versioning operations.  These methods are directed
       at a specific URI and versioned resource.  That is, all
       revisions of the body contains XML indicating resource have the action
       to take.

       If a resource supports DAV:versioning then it same DAV:vresourceid.  This MUST support the
       LOCK/UNLOCK extensions defined in this section.

  2.6.1.    Checkout

       Using the LOCK method, clients can request resources to
       be "checked
       out". preserved over MOVE requests and should be globally unique.

       DAV:previousrevisionids - This involves creating is a working resource read-only property that is not
       automatically versioned.  Checked out resources must be checked in
       or aborted, using returns
       the UNLOCK method. The diagram below illustrates
       this process:

           Revisions of foo.htm:  V1

           Checkout is performed: V1
                                   |
                                   +-> Working Resource

           Checkin is performed:  V1 -> V2

       The body XML indicates an optional checkout comment, an optional
       user token, and locking actions.  Clients specify server defined id for the checkout lock
       in all update operations (e.g., PUT or PROPPATCH) to alter previous revision of the
       working resource.

       The working resource will always
       An empty value indicates that there are no previous revisions.
       Note that there could be DAV:checkout locked.  Clients
       can choose to make the appropriate scope (DAV:shared,
       DAV:exclusive, ...).  Optionally, using the DAV:vresoucelockscope
       tag, clients can have the versioned resource DAV:checkout locked
       for a specified scope (DAV:shared, DAV:exclusive, ...). multiple previous versions.  If there are
       multiple revisions, they are returned as a client
       requests the versioned resource to be locked, and it cannot be,
       then comma-separated list.
       Note that this property returns previous revisions that the lock operation MUST fail.

       The DAV:checkout lock state is equivalent to server
       determines.  That is, this does not include user identified merged
       revisions.

       DAV:distinguishedpredecessorid - This read-only property indicates
       the DAV:write lock
       state in terms of interoperability with other locks.

       Resources SHOULD allow clients to propose primary predecessor for a DAV:locktoken revision in the
       LOCK request.  If a resource does not accept event they are
       multiple predecessors.

       DAV:nextrevisionids - This is a clientÆs proposed
       lock token, it MUST fail read-only property that returns the LOCK request.

       >>Request

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

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

       >>Response

       HTTP/1.1 201 CREATED
       Content-Type: text/xml
       Content-Length: xxxx

       <?xml version="1.0" encoding="utf-8"?>
       <D:prop xmlns:D="DAV:">
          <D:lockdiscovery>
            <D:activelock>
               <D:locktype><D:checkoutlock/></D:locktype>
               <D:lockscope><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>

  2.6.2.    Branching Resources

       For more sophisticated clients, basic resource branching is
       required. Resource branching means that
       server defined id for a given resource, the
       history next revision of the resource.  An empty
       value indicates that there is not linear.  That is, no subsequent revision.  Note that
       there could be multiple next revisions.  If there are different lines of
       descent.  The diagram below illustrates this.

           Revision 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) multiple
       revisions, they are described in returned as a later
       section. comma-separated list.  Note that when a collection
       this property returns successor revisions that the server
       determines.  That is, this does not include user identified merged
       revisions.

       DAV:revisionurl - This is branched, a read-only property that returns a URL
       for this specific revision.

       DAV:revisionlabel - This property allows the depth specification of the
       branch is infinity.  There is no way
       textual names that refer to change this. this version of the resource. If there
       are multiple labels, they are returned as a resource supports branching, it comma separated list.
       Labels MUST return
       DAV:resourcebranching in be unique for the Versioning-Support header reply from
       OPTIONS.

       A versioned resource.  That is, no two
       revisions of the same versioned resource is branched using can have the LOCK method same
       DAV:revisionlabel.  As well, DAV:revisionlabel and DAV:revisionid
       properties share the DAV:checkout
       lock type.  The resource to same namespace and there can be branched is specified no duplicates.
       Servers MAY reserve specific portions of this namespace and return
       an error if a client uses a reserved name as the target
       URI for the method.

       Clients have a choice revision label.
       This property MUST be mutable.

       DAV:mergedfrom - This property specifies a comma separated list of three approaches to branching
       revision ids from which are
       specified with specific tags in this revision is purported to be derived.
       This information is provided and managed by the request:

       - perform client. This is a branch  <DAV:branchresource>

       - do not branch, error if necessary  <DAV:dontbranchresource>
       mutable property.

       DAV:mergedto - branch if necessary <DAV:branchallowed>

       As well, clients can specify This property specifies a branch label comma separated list of
       revision ids from which this revision is purported to identify a created
       branch using be merged
       into.  This information is provided and managed by the DAV:branchlabel tag.  The reply MUST include client. This
       is a
       Branch-Id header specifying mutable property.

       DAV:mergedfromunion - This read-only property specified a resource defined branch id or comma
       separated list of revision ids from which this revision is derived.

       This is a union of the
       specified branch label if DAV:mergedfrom and DAV:previousrevisionids
       properties.

       DAV:revisioncomment - This property contains a branch client-defined
       property associated with the revision.  This as a mutable property.
       This is created. a mutable property.

       DAV:author - The label or id creator of the revision.  This is an arbitrary
       string.

       DAV:canthaw - This property indicates if the revision can be specified in a Branch-Id or Revision-Id header to determine THAWed
       for modification.  Servers MAY implement this as read-only.

       DAV:hasthawed - This read-only property indicates if the revision
       has ever been thawed.

       DAV:isthawed - This read-only property indicates if the revision to access.

       >>Request

       LOCK /foo/bar.htm HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:lockinfo xmlns:D="DAV:">
          <D:branchresource/>
          <D:branchlabel>MyBranch</D:branchlabel>
          <D:locktype><D:checkout/></D:locktype>
          <D:comment>checkout comment</D:comment>
          <D:owner>client-defined token</D:owner>
          <D:lockscope><D:exclusive/></D:lockscope>
          <D:vrsourcelockscope><D:shared/></D:vresourcelockscope>
       </D:lockinfo>

       >>Response

       HTTP/1.1 201 CREATED
       Branch-Id: MyBranch
       Content-Type: text/xml
       Content-Length: xxxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:prop xmlns:D="DAV:">
          <D:lockdiscovery>
            <D:activelock>
               <D:locktype><D:checkoutlock/></D:locktype>
               <D:lockscope><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>

       When a branch is created,
       currently thawed (or frozen if not).

       DAV:lastcheckin - This read-only property specifies the reply date this
       revision was "checked in" in ISO8601 format.

  2.10.     Basic Versioning Headers

       The following sub-sections describe the new version headers that
       MUST include be supported for resources that support DAV:versioning.

  2.10.1.   Revision-Id

       The Revision-Id header is used to identify a specific revision of a
       versioned resource.  This header can be specified on all methods
       and qualifies the resource named in the method.  As well, this
       header is included in all replies to indicate the revision of the
       versioned resource used or created.

       The BNF for this header 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 a
       specific revision of a resource.  This includes a DAV:revisionid or
       any of the DAV:revisionlabel values to refer to a specific revision
       of the resource.  As well, a configuration (described later) can be
       referenced here to select the default revision associated with the
       configuration.

       The use of the Time operator is to select the "current" revision as
       of the specified time.

       The use of Revision-Id: * is only permitted with PROPFIND to obtain
       properties across all revisions of a versioned resource.

  2.10.2.   Branch-Id
       header.

       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 a revision-id is used.  When
       specified, it indicates that the latest version of the indicated
       branch is to be selected as the revision to use for the operation.

  2.6.3.    Checkin

       When

  2.10.3.   Override-Checkin

       It is possible that the client has completed changes to check-in operation will detect a resource conflict.
       For example, version 5 was checked out shared, and wishes before it
       to become part of the revision history, the client must check in
       the resource.  This is performed using
       checked back in, version 6 was created.  In these situations, the UNLOCK method against
       check-in MUST fail indicating a conflict.  Clients can choose to
       branch the versioned resource with special body tags and identification of resource, merge on the checkout lock in client, or overwrite.  To
       circumvent this check, clients can use the Override-Checkin header.

       >>Request

       UNLOCK /foo/bar.htm 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:unlockinfo xmlns:D="DAV:">
          <D:comment>checkin comment</D:comment>
       </D:unlockinfo>

       >>Response

       HTTP/1.1 204 CREATED
       Revision-Id: VER:FREFRI49349
       Content-Length: 0

       The reply MUST include
       This specifies that the Revision-Id of check-in operation SHOULD NOT fail (either
       the newly created
       revision.

  2.6.4.    Undo Checkout

       If a client chooses has merged to cancel a checkout request, resolve the UNLOCK method conflict, or desires an
       overwrite).  The BNF is used with optional body tags and identification 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 the checkout
       lock. 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

       UNLOCK

       GET /foo/bar.htm 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:unlockinfo xmlns:D="DAV:">
          <D:cancelcheckout/>
          <D:comment>cancel checkout comment</D:comment>
       </D:unlockinfo>

       >>Response

       HTTP/1.1 200 OK
       Revision-Path: /foo;VER:HT58GHDW49/bar.htm
       Content-Length: 0

  2.6.5.    Enumeration

       Clients can enumerate the current checkouts to

       The use of * for a resource using the revision is only permitted with PROPFIND method and standard lock discovery.  All attributes
       specified in the lock request (e.g. DAV:comment) MUST be returned
       in lock discovery.

  2.7. Default Revision

       If to
       obtain properties across all revisions of a Revision-Id (or Branch-Id) header is not specified when
       referring versioned resource.

  3. CHECKING OUT/IN RESOURCES

       For versioning-aware clients, more advanced requests allow them to
       perform specific versioning operations.  These methods are directed
       at a specific URI to alter.

       If a resource, resource supports DAV:versioning then it MUST support the tip (latest) revision (from the
       primary branch) is used, unless a default revision has been
       identified.  To mark a specified revision as
       methods defined in this section.

  3.1. Checkout

       Using the default revision, CHECKOUT method, clients use the PIN method.  Note that PUT or checkin will create
       new revisions which will can request resources to be returned unless a PIN is defined.  When
       "checked out".  This involves creating a revision working resource that is PINned, new revisions can be created with PUT or
       checkin, but they will
       not automatically versioned.  Checked out resources must be returned unless they are referenced
       explicitly.

       Note that branching a checked
       in or cancelled. The diagram below illustrates this process:

           Revisions of foo.htm:  V1

           Checkout is performed: V1
                                   |
                                   +-> Working Resource

           Checkin is performed:  V1 -> V2

       The body XML indicates an optional checkout comment, an optional
       user token, and locking actions.  The response indicates the
       working resource has no effect on as well as any requested locks.

       The CHECKOUT method causes the default
       revision creation of the resource, even if the default revision working copy which
       is branched.
       If unpinned, specified by the default revision is Location header in the tip revision response.

       Clients can optionally request locks to be taken as part of the
       initial (primary) branch of
       CHECKOUT operation.  If the versioned resource.

       >>Request

       PIN /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:pin xmlns:D="DAV:">VER:HT58GHDW49</D:pin>

       >>Response

       HTTP/1.1 200 OK
       Content-Length: 0 locks cannot be obtained, the CHECKOUT
       operation MUST fail.  The following table identifies the different
       lock options:

            Lock      Tags Used       Description
            Target    (DAV: assumed)

            working   wrlocktype,     Limits access to the newly created
            resource  wrlockscope     working resource

            revision  revisionlockty  Blocks CHECKOUT/INs against this
                      pe,             revision
                      revisionlocksc
                      ope
            branch    branchlocktype  Blocks CHECKOUT/INs against
                      ,               revisions in this branch
                      branchlockscop
                      e

            versioned vrlocktype,     Blocks CHECKOUT/INs against any
            resource  vrlockscope     revision of the versioned
                                      resource.

       The semantics of the tags match those of DAV:locktype and
       DAV:lockscope as specified for the LOCK method.

       >>Request

       PIN /foo/bar.htm

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

       <?xml version="1.0" encoding="utf-8" ?>
       <D:unpin xmlns:D="DAV:"/>
       <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 200 OK 201 CREATED
       Location: http://www.foobar.com/tmp/VRJHJWE3493409
       Content-Type: text/xml
       Content-Length: 0

       It should be noted that setting a default revision may impact
       automatic versioning.  If a client performs a PUT operation that is
       automatically versioned, it 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 a GET will not return the
       new version (possibly because of a PIN).

  2.8. Sharing

       Many versioning systems today provide branch is required.

  3.2. Checkin

       When the ability client has completed changes to have a given resource visible in multiple parts and wishes it
       to become part of the namespace.  In these
       situations, a resource is shared.  That is, changes to revision history, the resource
       are visible to all versions.

       The WebDAV advanced collections adds support for referential
       members, however, this is not sufficient for sharing client must check in a
       versioning environment because of the requirement to establish
       default revisions.  Indirect references cannot map to specific
       versions for down-level (e.g. HTTP/1.1) clients and direct
       references map directly to
       the shared resource.  This specification introduces a new type of referential member,
       semi-direct.  A semi-direct reference is like a direct reference
       except that it can have attributes of its own or it performed using the CHECKIN method against
       the working copy.

       The DAV:keepcheckedout tag can map
       directly be specified to indicate that the shared resource.  By default, when a semi-direct
       reference is used in a request, it behaves like a direct reference.
       However, if the Pass-Through header is specified on the request
       with
       resource should remain checked out.  That is, create a value of "*", then the operation is performed against the
       semi-direct reference not the object it points to.  This is an
       extension of new
       revision, but leave the WebDAV advanced collection specification working copy checked out.

       Using XML tags in value
       and because the header can be specified with any request against a
       semi-direct reference.

       In the example below, a semi-direct reference is created. body, clients can specify optional
       checkin information.

       >>Request

       MKREF /bing/bar.htm

       CHECKIN /tmp/VRJHJWE3493409 HTTP/1.1
       Host: www.foobar.com
       Ref-Target: /foo/bar.htm
       Ref-Integrity: DAV:semidirect
       Lock-Token: <opaquelocktoken:rejrei-43343-rereffre>
       Content-Type: text/xml
       Content-Length: 0 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
       ...

       In
       Revision-Id: VER:FREFRI49349
       Content-Length: 0

       The reply MUST include the example below, Revision-Id of the newly created
       revision.

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

  3.3. Cancelling Checkout

       If a semi-direct reference.
       The object that the reference refers client chooses to is returned.

       >>Request

       GET /bing/bar.htm HTTP/1.1
       Host: www.foobar.com
       Content-Length: 0

       In cancel a checkout request, the example below, UNCHECKOUT
       method against the semi-direct reference is PINned working copy.  As well, optional XML body tags
       can be used to a
       specific revision. supply additional information.

       >>Request

       PIN /foo/bar.htm

       UNCHECKOUT /tmp/VRJHJWE3493409 HTTP/1.1
       Host: www.foobar.com
       Pass-Through: *
       Lock-Token: <opaquelocktoken:rejrei-43343-rereffre>
       Content-Type: text/xml
       Content-Length: xxx xxxxx
       <?xml version="1.0" encoding="utf-8" ?>
       <D:pin xmlns:D="DAV:">VER:HT58GHDW49</D:pin>

  2.9. Collection Versioning

       Collections can be versioned just like non-collection resources,
       however, there are special situations that must be taken into
       account.  Collections are versioned in the following ways:

       - DonÆt version the collection regardless of the changes.

       - Version the collection only if there is a direct change
       <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 the
          resource.

       - Version the collection if there is a change anywhere under the
          collection (i.e., bubble of the changes).

       Each collection Resource Reports section for details on check-out
       enumeration.

  4. BRANCHING RESOURCES

       For more sophisticated clients, basic resource MAY choose the behavior it supports.  The
       behavior branching is specified through properties, which resources MAY
       choose to make read-only.

       The DAV:autoversion property indicates if
       required. Resource branching means that for a collection resource
       supports versioning when changes given resource, the
       history is not linear.  That is, there are made to it. different lines of
       descent.  The
       DAV:autocollectionversion property indicates if the collection diagram below illustrates this.

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

       Individual resource supports branching is common in many versioning when changes systems
       today.  Project branching (configurations) are made anywhere described in the
       namespace below it.

  2.9.1.    Default Revisions

       It is up to each collection resource to determine if it supports
       default versions.  If it doesnÆt, then PIN requests MUST fail.  If a collection resource doesnÆt support versioning, then is MUST also
       fail PIN requests.

  2.9.2.    Headers

       If collections are versioned, then clients may choose to access
       resources later
       section. Note that are part of specific revisions. The Revision-Path
       header when a collection is used to identify specific revisions that are part branched, the depth of the
       "path"
       branch is infinity.  There is no way to change this.

       A revision is branched using the resource.  This header servers as an alternative BRANCH method.  The resource to
       "URL munging".  This header can be
       branched is specified on all methods and
       qualifies as the resource named in target URI for the method.

       As well, clients can specify a branch label to identify a created
       branch using the DAV:branchlabel tag.  The BNF for this reply MUST include a
       Branch-Id 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;VER:HT58GHDW49
       Content-Length: 0

       The use of * for a revision is only permitted with PROPFIND to
       obtain properties across all revisions of specifying a versioned resource.

  2.9.3.    Properties

       DAV:autocollectionversion - This propertyÆs value (0/1) specifies resource defined branch id or the
       specified branch label if a collection is automatically versioned when its contents
       (anywhere under it) change.  That is, if /foo/bar.htm is versioned, branch is /foo/ versioned as well.  Resources MAY implement this as created.  The label or id can
       be specified in a
       read-only property.

       DAV:canautocollectionversion - This propertyÆs value (0/1)
       specifies if the resource supports Branch-Id or Revision-Id header to determine the ability
       revision to automatically
       version collections when 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 contained resource changes.  This branch is created, the reply MUST include a
       read-only property.

  2.10.     Resource Reports Branch-Id
       header.

  5. RESOURCE REPORTS

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

       Note that resources MAY support multiple styles of history and
       reports.  To enumerate the supported history graphs and reports,
       clients use PROPFIND and the <DAV:enumreport> <DAV:availablereports> property.  The
       results indicate a list of the different reports which can,
       themselves, be requested via PROPFIND.

       Note that clients can request properties to be included in reports
       by specifying the desired properties inside the DAV:enumreport tag.

       For the examples in this section, assume that the resource /foo.htm
       has 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 of V1.1 and V1.1.1

       -  V3 is a merge of V2 and V1.2

       As well, the default revision history (those revisions marked as
       the default) is as follows:

       -  V1 (the initial revision was created)

       -  V2 (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".

  2.10.1.   Example

  5.1. Available Reports

       Clients can obtain the available reports for a resource 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:enumreport/>
          <D:prop>
            <D:availablereports/>
          </D:prop>
       </D:propfind>

       >>Response

       ...
       <D:propfind>
       <D:multistatus>
          <D:response>
            <D:href>http:/www.foobar.com/foo/bar.htm</D:href>
            <D:propstat>
               <D:prop>
            <D:enumreport>
               <D:report><D:href>DAV:defaulthistory</D:href></D:report>
               <D:report><D:href>DAV:directlineage</D:href></D:report>
               <D:report><D:href>DAV:fulllineage</D:href></D:report>
            </D:enumreport>
                 <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:propfind>
            </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.

  2.10.2.

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

  5.2. Default History

       Resources MUST support the DAV:defaulthistory report.  This
       enumerates the historical record of revisions that have been
       visible as the default revision of the versioned resource. revision.

       Clients can specify the limit parameter 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:enumreport type="DAV:defaulthistory"
          <D:defaulthistory limit=20/>
       </D:propfind>

       >>Response

       ...
       <D:propfind>
       <D:multistatus>
          <D:response>
            <D:href>http://www.foobar.com/foo/bar.htm</D:href>
            <D:propstat>
               <D:prop>
            <D:enumreport type="DAV:defaulthistory">
               <D:revision id="V1" vresourceid="VER:FFHJE">
                 <D:revisionid>V3</D:revision>
                 <D:revisioncomment>Update it</D:revisioncomment>
               </D:revision>
               <D:revision id="V2" vresourceid="VER:FFHJE">
                 <D:revisioncomment>Update it</D:revisioncomment>
                 <D:revisionlabel>Test1</D:revisionlabel>
               </D:revision>
               <D:revision id="V1" vresourceid="VER:FFHJE">
                 <D:revisioncomment>Update it</D:revisioncomment>
               </D:revision>
               <D:revision id="V3" vresourceid="VER:FFHJE">
                 <D:revisioncomment>Update it</D:revisioncomment>
               </D:revision>
            </D:enumreport> 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 a
       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>

  2.10.3.

       >>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 MUST SHOULD support the DAV:directlineage report.  This
       enumerates the direct parent revisions of the versioned resource.
       This report is from the default revision or the specified revision.

       Clients can request that a report be based on the namespace entry
       specified, or the associated DAV:vresourceid.  Clients use the
       scope parameter to specify (name or id).

       Clients can specify the limit parameter to limit the number
       revisions returned.

       >>Request

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

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

       >>Response

       ...
       <D:propfind>
       <D:multistatus>
          <D:response>
            <D:href>http://www.foobar.com/foo/bar.htm</D:href>
            <D:propstat>
               <D:prop>
            <D:enumreport type="DAV:directlineage" scope="name">
               <D:revision id="V1" vresourceid="VER:FFHJE">
                 <D:revisionid>V1</D:revision>
                 <D:vresourceid>VER:FFHJE</D:vresource>
                 <D:revisioncomment>Update it</D:revisioncomment>
                 <D:revision id="V2" vresourceid="VER:FFHJE"> 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:revisioncomment>
                    <D:revisionlabel>Test1</D:revisionlabel>
                    <D:revision id="V3" vresourceid="VER:FFHJE"> 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:revisioncomment>
                      <D:merge id="V2" vresourceid="VER:FFHJE"/>
                      <D:merge id="V1.2" vresourceid="VER:FFHJE"/>
                    </D:revision>
                 </D:revision>
               </D:revision>
            </D:enumreport> 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:propfind>

  2.10.4.
            </D:propstat>
            <D:status>HTTP/1.1 200 OK</D:status>
          </D:response>
       </D:multistatus>

  5.5. Full Lineage

       Resources MUST SHOULD support the DAV:fulllineage report.  This
       enumerates the full graph of revisions for this resource.

       Clients can request that a report be based on the namespace entry
       specified, or the associated DAV:vresourceid.  Clients use the
       scope parameter to specify (name or id).

       Clients can specify the limit parameter to limit the number
       revisions returned.

       >>Request

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

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

       >>Response

       ...
       <D:propfind>

       <D:multistatus>
          <D:response>
            <D:href>http://www.foobar.com/foo/bar.htm</D:href>
            <D:propstat>
               <D:prop>
            <D:enumreport type="DAV:fulllineage" scope="name">
               <D:revision id="V1" vresourceid="VER:FFHJE">
                 <D:revisionid>V1</D:revision>
                 <D:vresourceid>VER:FFHJE</D:vresource>
                 <D:revisioncomment>Update it</D:revisioncomment>
                 <D:revision id="V2" vresourceid="VER:FFHJE"> 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:revisioncomment>
                    <D:revisionlabel>Test1</D:revisionlabel>
                    <D:revision id="V3" vresourceid="VER:FFHJE"> 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:revisioncomment>
                      <D:merge id="V2" vresourceid="VER:FFHJE"/>
                      <D:merge id="V1.2" vresourceid="VER:FFHJE"/>
                    </D:revision>
                    <D:revision id="V1.1" vresourceid="VER:FFHJE"
                                                 branchid="MyBranch">
                      <D:revisionlabel>Test2, Good</D:revisionlabel> 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:revisioncomment>
                         <D:revision id="V1.2" vresourceid="VER:FFHJE"
                                branchid="MyBranch">
                         <D:revisionlabel>Tested</D:revisionlabel> 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:revisioncomment>
                         <D:merge id="V1.1" vresourceid="VER:FFHJE"/>
                         <D:merge id="V1.1.1" vresourceid="VER:FFHJE"/>
                      </D:revision>
                      <D:revision id="V1.1.1" vresourceid="VER:FFHJE"> 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:revisioncomment>
                      </D:revision>
                    </D:revision>
                 </D:revision>
               </D:revision>
            </D:enumreport> it</D:comment>
                 <D:derivedfrom>V1.1</D:derivedfrom>
               </D:prop>
       </D:propfind>

  3.      CONFIGURATIONS
            </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 is
       defined as part of this specification.

       Configuration management is a large space. This specification
       addresses several types of configurations:

       - Label:  Dynamic: A label dynamic configuration is a collection of specific
          revisions of selected versioned resources.  Changes to the
          versioned resources do not effect the contents of the label
          configuration. based on selection
          rules.  This can be used for labels, floating labels, etc.

       - Floating Label:  Workspace: A floating label workspace configuration is a collection of
          the default mechanism for tracking
          and managing parallel changes to multiple resources.

       Configurations provide a mechanism for organizing resources and
       quick access to specific revisions of selected versioned resources.  When  Clients can
       access resources in the
          default revision context of a selected resource changes, configuration.  By referencing
       a configuration, requests are automatically mapped to the contents correct
       revision of the floating label configuration is updated automatically.  Note
          that when a versioned resource is added resource.  This allows configurations to a floating level
          configuration, the Branch-Id header can
       be specified.  In this
          case, the floating label will contain the tip revision the
          specified branch.

       - Workspace: A workspace configuration is a collection of multiple
          revisions of selected versioned resources.  As the selected
          versioned resources are changed, in the context of the workspace
          configuration, the workspace tracks the version history.

       Configurations provide used as a reference mechanism for organizing resources and
       quick access to specific revisions of resources.  Clients can
       access resources in the context of a configuration.  By referencing
       a configuration, requests are automatically mapped to the correct
       revision of the versioned resource.

       Note that servers provide a default workspace configuration.  This
       is were all resources exist.  Clients can request other workspace
       configurations to be created and have operations performed within
       their context if workspace configurations are supported. without breaking URL hyperlinks.

       A configuration can be derived from another configuration.  That
       is, the new configuration is based on the versions in the "parent"
       configuration.  Optionally, derived configurations can
       automatically inherit new versions in the parent configuration
       (assuming there are no conflicts).  However, a configuration can be
       derived from at most one other configuration.

       Clients can specify configuration ids wherever a revision id can be
       specified.  This requests that the default revision for the
       specified configuration be used.  Requests that include both a
       revision id and a configuration id MUST fail if the specified
       revision is not part of the specified configuration.

  3.1.  Typically
       both a revision id and a configuration id are not needed since the
       revision URI is unique across all configurations.

  6.1. Discovery

       Configuration support is optional.  This example shows that the
       /somefolder resource supports configurations.

       >> Request

       OPTIONS /somefolder/ HTTP/1.1
       Verify-Extension: DAV:versioning
       Host: foobar.com www.foobar.com
       Content-Length: 0 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, PIN, MKREF MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
       MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, PIN, MKREF
       Verify-Extension: DAV:versioning
       Versioning-Support: DAV:basicversioning, DAV:configurations
       Configuration-Types: DAV:Label, DAV:Floating, DAV:Workspace
       Configuration-Root: /cfgs/ MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Versioning: DAV:basicversioning
       Content-Type: text/xml
       Content-Length: 0

       The Configuration-Types header in the OPTIONS reply indicates the
       types of configurations supported. Presence of this header
       indicates support for configurations.  The BNF for this header is:

            Configuration-Types := "Configuration-Types" ":" Ctypes
            CTypes              := CType | (CTypes "," CType)
            CType               := "Label" | "Floating" | "Workspace" |
                                   URI

       The Configuration-Root header in the OPTIONS reply indicates the
       root of the configuration namespace.  Note that there could be
       multiple configuration roots.  The BNF for this headers is:

            Configuration-Root := "Configuration-Root" ":" URI-List

  3.2. 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 a private portion of the
       namespace.  The root of this namespace is determined by examining
       the OPTIONS extended reply.  All configurations names MUST be
       unique on a server.  Using the configuration namespace, clients can
       create and manage configurations.

       Clients create new configurations by issuing the MKCOL MKCONFIG method
       against the configuration namespace.  This requests the server to
       create a new configuration.

       When a configuration is created, special tags can be used to define
       the characteristics and relationships (e.g. derivations) for the
       configuration.  The following table enumerates these tags.

                 Tag                  Description

            <DAV:configurationtype>   This tag defines the type
                xxx
                                      of configuration:
            </DAV:configurationtype>    DAV:Label, DAV:Floating,
                xxx                   DAV:Dynamic or
            </DAV:configurationtype>  DAV:Workspace.

            <DAV:derivedfrom>         This tag allows the client
                xxx
            "xxx"                     to specify a URI to
            </DAV:derivedfrom>        identify another
                                      configuration from which
                                      this new configuration is
                                      to be derived.

            <DAV:inheritancetype>     The configuration
                DAV:Auto
                                      automatically inherits
            </DAV:inheritancetype>
                DAV:Auto              changes from its derived-
            </DAV:inheritancetype>    from configuration.
                                      Conflicts are recorded in
                                      resolution queues (see
                                      later section).

            <DAV:inheritancetype>     The configuration inherits
                DAV:Manual
                                      changes from its derived-
            </DAV:inheritancetype>
                DAV:Manual            from configuration, but
            </DAV:inheritancetype>    they are not automatically
                                      inserted into the
                                      configuration. Instead
                                      they are recorded in
                                      resolution queues (see
                 Tag                  Description

                                      later section).

            <DAV:inheritancetype>       The configuration is a
                DAV:None
                                      snapshot of the current
            </DAV:inheritancetype>
                DAV:None              versions in the derived-
              DAV:inheritancetype>    from configuration.  There
                                      The configuration is a
                                      is no inheritance of
                                      changes.  This is the
                                      default type if no type is
                                      specified.

            <DAV:basetime>"xxx"       The configuration is based
            </DAV:basetime>           on the current versions in
                                      the derived-from
                                      configuration at the
                                      indicated time.  Note that
                                      use of this tag 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 in the derived from
       configuration.
       configuration at the specified time or using the default revisions.

       The example below illustrates creating a new configuration that is
       derived from, and auto-inherits another configuration.  For this
       example, the root of the configuration namespace has been
       determined to be /cfgs.

       >>Request

       MKCOL

       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: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

  3.3. Configuration Properties

       The standard PROPFIND and PROPPATCH methods can be used on the
       configuration resource to get and set properties on a
       configuration.

  6.3. Access Using Configurations

       Configurations MUST provide configuration
       properties if configurations are supported.  The following list
       identifies pre-defined properties maintained as a special collection.
       Configurations maintain referential members to all revisions that MUST be supported:

       DAV:configurationtype - The type
       are part of the configuration.
       Configurations can choose  Consequently, one approach to make this a read-only property.

       DAV:derivedfrom - The configuration from which
       enumerating the contents of a configuration is
       derived.  Configurations can choose to make this a read-only
       property.

       DAV:inheritancetype - The type use PROPFIND to
       discover the contents of inheritance for the
       configuration.  Configurations collection.

       Alternatively, clients can choose to make this request a read-only
       property.

       DAV:basetime - The base time used to create the configuration.
       Configurations can choose to make this specific resource from a read-only property.

       DAV:configurationame - A user-defined display name for the
       configuration.

       DAV:defaultconfiguration -  This property on the configuration root
       identifies the default workspace configuration approach allows clients to use if one the URL they
       are familiar with.  If a client requests a resource that is not
       specified.

  3.4. Headers
       part of a configuration, then an error 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 support configurations, two new headers are introduced that can
       be used with delete a variety of configuration, use the DAV and HTTP methods.  The following
       list identifies these headers:

       Configuration-Id - This header is used to identify location returned from the
       configuration that is to be used when performing an operation.

       For workspace configurations, this can be specified to set default
       revisions per-configuration, enumeration of checkouts/checkins
       against a specific configuration, or to establish locks specific to
       a configuration.

       If a configuration is not specified, the default workspace
       configuration is used.  All servers have a default workspace where
       resources reside.  The configuration "*" can be specified with
       PROPFIND to locate properties irrespective of configuration.

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

       Note that the configuration id can be used in place of a revision
       id.  In this case, the revision selected is the default revision of
       the versioned resource within the specified configuration.

       Target-Configuration - This header is used to specify a target
       configuration when dealing with cross-configuration operations.
       For example, resources can be copied from one configuration to
       another using the Configuration-Id and Target-Configuration headers
       with the COPY method.

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

  3.5. Deleting Configurations

       To delete a configuration, use the location returned from the
       configuration creation.  Note 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

  3.6. Managing Configuration Content

       Clients need to

  6.5. Resolution Queues

       There are times when an operation cannot be able to access and manage the contents of blocked that will
       result in a
       configuration.  This state that requires user action.  For example, when
       configurations inherit, there is done using the GET, COPY, and DELETE
       methods.

  3.6.1.    Access Using Configurations

       Configurations are maintained as potential for conflicts.
       Resolution queues provide a special collection. mechanism for discovering these
       conditions.

       Configurations track and maintain referential members to all revisions that
       are part a list of the configuration.  Consequently, one approach issues that need to
       enumerating the contents of a configuration is to use PROPFIND to
       discover the contents of the collection.

       Alternatively, clients can request a specific resource from a
       configuration.  This approach allows clients to use the URL they
       are familiar with.  If a client requests be
       resolved as a resource that is not
       part result of a configuration, then an error is returned.

       >>Request

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

  3.6.2.    Adding Resources to a Configuration

       Resources actions.  These lists are added referred to a configuration using as
       resolution queues.  Clients can request the COPY method.  A
       special body tag is used resolution issues and
       react accordingly.  The configuration will continue to indicate that report the resource
       condition until it is being
       added to resolved.

       The resolution queue is obtained by obtaining the
       DAV:resolutionqueue property from the configuration.  This property
       contains all of the identified issues.

       >>Request

       COPY /foo/bar.htm

       PROPFIND /cfgs/FDJE4949 HTTP/1.1
       Host: www.foobar.com
       Depth: infinity
       Configuration-Id: /cfgs/DFEE2034
       Target-Configuration: /cfgs/ERRJ3440
       Content-Type: text/xml
       Content-Length: xxxx xxxxx

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

       If a specific revision is not specified, then the default revision
       is copied.

       Note that clients can also create referential members within the
       configuration collection to add them to the collection.

  3.6.3.    Removing Resources from
       <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 Configuration

       Resources are client has resolved an issue it will automatically be
       removed from a configuration using the DELETE. resolution queue.

  6.6. Configuration Properties

       The
       target URI indicates standard PROPFIND and PROPPATCH methods can be used on the
       configuration resource to delete get and the Configuration-
       Id header to identify the set properties on a
       configuration.  Configurations MUST provide configuration
       properties if configurations are supported.  The Depth header can following list
       identifies pre-defined properties that MUST be
       used to remove collection contents.  A special tag is used to
       indicate that the resource is being removed from supported:

       DAV:configurationtype - The type of the configuration
       (not deleted).

       >>Request
       DELETE /foo/bar.htm HTTP/1.1
       Host: www.foobar.com
       Depth: infinity
       Configuration-Id: /cfgs/DFEE2034
       Content-Type: text/xml
       Content-Length: xxxx

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

       Note that clients configuration.
       Configurations can also delete referential members within the
       configuration collection choose to remove them make this a read-only property.

       DAV:derivedfrom - The configuration from which the collection.

  3.7. Workspace configuration is
       derived.  Configurations

       Workspace configurations provide the ability can choose to track multiple
       revisions of make this a resource independent of the resource in other
       workspace configurations.  This section describes aspects read-only
       property.

       DAV:inheritancetype - The type of inheritance for the
       protocol specific to workspace configurations.

  3.7.1.    Default Workspace
       configuration.  Configurations

       Clients can establish a default workspace configuration that is choose to
       be used, for all clients, if they do not specify make this a workspace read-only
       property.

       DAV:basetime - The base time used to create the configuration.  To do this, clients set
       Configurations can choose to make this a read-only property.

       DAV:defaultconfiguration - This property on the configuration namespace root collection identifying
       identifies the default workspace configuration.

       >>Request

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

       <?xml version="1.0" encoding="utf-8" ?>
       <D:propertyupdate xmlns:D="DAV:">
          <D:set>
            <D:prop>
               <D:defaultconfiguration>/cfgs/RYURUS99009
               </D:defaultconfiguration>
            </D:prop>
          </D:set>
       </D:propertyupdate>

  3.7.2.    Synchronizing Worksapce Configurations

       In some scenarios, clients are working on separate workspace
       configurations to keep themselves isolated from other team members.
       However, they occasionally need to synchronize their workspace
       configuration with the derived-from workspace configuration so that
       they donÆt get too far out to use if one is not
       specified.

       DAV:resolutionqueue - A list of synchronization.  As well, changes
       (or entire configurations) identified issues that require
       client attention.

  6.7. Headers

       To support configurations, two new headers are introduced that can
       be copied from one workspace
       configuration to another.  Both operations are performed using used with a variety of the
       COPY method DAV and special body tags.

       Clients can request HTTP methods.  The following
       list identifies these headers:

       Configuration-Id - This header is used to identify the
       configuration that is to be used when performing an operation.

       For workspace configurations, this can be specified to set default
       revisions per-configuration, enumeration of checkouts/checkins
       against a specific resources are copied by including
       the resource tag. configuration, or to establish locks specific to
       a configuration.

       If no resources are specified, then all
       resources are copied.  Note that configurations MAY fail requests
       that do a configuration is not fully synchronize.

       The example below shows specified, the synchronization of one default workspace
       configuration
       against another. is used.  All servers have a default workspace where
       resources are synchronized.

       >>Request

       COPY /cfgs/DHFHR99392 HTTP/1.1
       Host: www.foobar.com
       Destination: http://www.foobar.com/cfgs/RRURU329049
       Content-Type: text/xml
       Content-Length: xxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:configurationsync xmlns:D="DAV:"/> reside.  The example below shows the synchronization of one configuration
       against another.  The "*" can be specified resources are synchronized with
       PROPFIND to locate properties irrespective of configuration.

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

       Note that the
       indicated time.

       >>Request

       COPY /cfgs/DHFHR99392 HTTP/1.1
       Host: www.foobar.com
       Destination: http://www.foobar.com/cfgs/RRURU329049
       Content-Type: text/xml
       Content-Length: xxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:configurationsync xmlns:D="DAV:">
          <D:resource>/foo/bar.htm</resource>
          <D:resource>/bing/bop.htm</resource>
          <D:basetime>...</D:basetime>
       </D:configurationsync>

       A synchronization request could result configuration id can be used in conflicts.  By default,
       if conflicts exist, place of a revision
       id.  In this case, the synchronization fails and revision selected is the conflicts are
       returned (as shown below). To override, clients should include default revision of
       the
       <DAV:override/> tag.  This tag indicates that versioned resource within the synchronization
       should do as much as possible and return any conflicts.

       >>Response

       TBD specified configuration.

       Target-Configuration - show failure response
       ...
       <D:multistatus>
          <D:response>
            <D:href> http://www.foobar.com/foo/bar.htm</D:href>
            <D:conflict>
               <D:conflictid>VER:DJHFH443</D:conflictid>
               <D:baseversion>VER:DJHFH443</D:baseversion>
               <D:newversion>VER:FDFEE55544</D:newversion>
            </D:conflict>
          <D:response>
          ...
       </D:multistatus>
       ...

       The sample response above shows that each conflict includes an ID
       and a reference to the resource in conflict.  A configuration MAY
       choose to restrict operations until conflicts have been resolved.
       To inform the configuration that a conflict has been resolved,
       clients should include a Conflict-ID This header on PUT, PROPPATCH, etc.
       methods specifying the ID returned in the synchronization response.

            Conflict-ID := "Conflict-ID" ":" URI

       It is permitted for servers used to refuse (fail) synchronization
       requests that do not originate at the root.  That is, arbitrary
       resources.

  3.7.3.    Condensing Workspace Configurations

       Condensing specify a target
       configuration means reducing the number of revisions
       in a configuration.  That is, collapse the changes into a single
       revision.  This is performed by extending the DELETE method.  In
       the example below, all but the latest three versions are condensed
       into a single revision.

       >>Request

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

       <?xml version="1.0" encoding="utf-8" ?>
       <D:condense xmlns:D="DAV:">
          <D:resource>/foo/bar.htm<D:keep>3</D:keep></D:resource>
       </D:condense>

       Note that the DAV:maxrevisions property when dealing with cross-configuration operations.
       For example, resources can be used copied from one configuration to set the
       maximum number of revisions that are maintained for a versioned
       resource.

       If the DAV:revisionid header is specified,
       another using the condensing starts Configuration-Id and Target-Configuration headers
       with the specified revision.  This means that if a versioned
       resource has 10 revisions, revisions 3-6 can be condensed.

       Servers MUST fail this request if there are dependencies on
       revisions COPY method.  Note that will resources CANNOT be eliminated.

  3.8. Configuration Reports 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
       of history and dependency.  To enumerate the supported history
       graphs, clients use PROPFIND and the <DAV:enumreport> <DAV:availablereports>
       property.  The results indicate the different graphs and reports 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:propfind>
       <D:multistatus>
          <D:response>
            <D:href>http://www.foobar.com/cfgs/FHJRH3994</D:href>
            <D:propstat>
               <D:prop>
                 <D:enumreport>
               <D:report><D:href>DAV:configurationderivation</D:href>
               </D:report>
               <D:report><D:href>DAV:configurationmerge</D:href></D:report>
                    <D:report>DAV:configurationderivation</D:report>
                    <D:report>DAV:configurationmerge</D:report>
                 </D:enumreport>
               </D:prop>
       </D:propfind>
            </D:propstat>
            <D:status>HTTP/1.1 200 OK</D:status>
          </D:response>
       </D:multistatus>
       ...

       Note that

       When clients issue PROPFIND requests to obtain reports, they may
       include other properties in the request.  These properties are
       returned for each report styles MUST be specified as DAV:href values.

  3.8.1. item.

  7.1. Configuration Derivation

       Configurations MUST support the DAV:configurationderivation report.
       This enumerates the full derivation of a configuraiton.  Note that
       the limit parameter can be specified to limit the number of items
       returned.  By definition the order 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:enumreport type="DAV:configurationderivation"
          <D:configurationderivation limit=100/>
       </D:propfind>

       >>Response

       ...
       <D:propfind>
          <D:prop>
            <D:enumreport type="DAV:configurationderivation" limit=100>
               <D:configuration id="VER:KJFJ444"/>
               <D:configuration id="VER:KJFJ445"/>
            </D:enumreport>
          </D:prop>
       </D:propfind>
       <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>
       ...

  3.8.2.

  7.2. Configuration Merge Graph

       Configurations SHOULD support the DAV:configurationmerge report.
       This enumerates 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:enumreport type="DAV:configurationmerge"/>
          <D:configurationmerge/>
       </D:propfind>

       >>Response

       ...
       <D:propfind>
          <D:prop>
            <D:enumreport type="DAV:configurationmerge">
               <D:revision id="V1" vresourceid="VER:FFHJE"
                             configurationid="VER:FJJR344">
                 <D:revision id="V2" vresourceid="VER:FFHJE"
                                configurationid="VER:FJJR344">
                    <D:revision id="V3" vresourceid="VER:FFHJE"
                                   configurationid="VER:FJJR344">
                      <D:merge id="V2" vresourceid="VER:FFHJE"
                                  configurationid="VER:FJJR344"/>
                      <D:merge id="V1.2" vresourceid="VER:FFHJE"
                                    configurationid="VER:FJJR344"/>
                    </D:revision>
                 </D:revision>
               </D:revision>
            </D:enumreport>
          </D:prop>
       </D:propfind>

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

  3.9. Resolution Queues

       When

  8. DYNAMIC CONFIGURATIONS

       Dynamic configurations inherit, there is the potential for conflicts.
       Configurations have the option provide a mechanism to help clients manage these
       conflicts.  However, if they do not, then configurations MUST
       return an error if identify all
       revisions that match specific criteria.  For example, "all
       revisions that have the operation would result in label Beta1".  The dynamic configuration is
       a conflict.

       Configurations that help resolve conflicts track view onto the resources and maintain lists 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 issues that need dynamic configurations to be resolved as
       supported.  This specification defines a result of actions.  These
       lists are referred to as resolution queues. 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 can request establish a selection criteria by setting the resolution issues and react accordingly.  Note that
       DAV:selectionrule property.  Once set, the dynamic configuration only manages the list.  That is, the client is
       responsible for resolving
       collection contains references to the issue (or deciding not to) and then
       removing 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 the resolution item.

  3.9.1.    Discovery

       Resolution queue support is optional for configurations.  Support
       for resolution queues is determined by examining selection criteria that are used to
       populate the
       DAV:resolutionqueue property on a dynamic configuration.  If this property  The selection criteria is not blank, then the configuration supports a resolution queue at
       the
       specified URL.  If this property is blank, then it doesnÆt
       support resolution queues.

  3.9.2.    Obtaining Resolutions

       Conflicts can arise against any resource, however, they are always
       associated with as a configuration.  Pending resolutions items are
       obtained by examining set of tags where nesting represents the resolution queue for a configuration.
       expressional ordering.  The resolution queue is actually a configuration-specific
       collection in following tags are available:

       -  DAV:and - The included tags MUST all be true to select

       -  DAV:or - Any of the DAV namespace. included tags MUST be true to select

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

       -  DAV:href - The collection resource
       identifying the resolution queue for a configuration is obtained
       via the DAV:resolutionqueue property on the configuration.  To
       enumerate URL MUST be the pending resolutions, clients use PROPFIND to obtain included URL

       -  DAV:label - A revision MUST have the resources within specified label

       -  DAV:tip - The "tip" revision is selected

       -  DAV:revisionid - The specified revision is selected

       -  DAV:configurationid - The configuration MUST be the collection.

       Each resource within specified
          value

       -  DAV:branchid - The branch MUST be the collection represents a separate
       resolution queue item and are named such that specified value

       -  DAV:depth - Used with DAV:href to indicate a standard ANSI sort
       on the resource name will ensure correct temporal ordering.

  3.9.3.    Processing Resolution Items

       Clients can GET the contents of recursive match
       TBD - provide full DTD

       The following example illustrates a resolution item.  This is an XML
       document selection rule that describes includes
       all revisions in the action /Foo/Bar folder (and below) that caused the resolution item
       to be created.  For example: have been
       labeled as "Beta1".

       <?xml version="1.0" encoding="utf-8" ?>
       <D:resolutionitem
       <D:basicrsr xmlns:D="DAV:">
          <D:resolutionid>http://foobar.com/reso/ZZZZ3493</D:resolutionid>
          <D:resource>http:/foo/bar.htm</D:resource>
          <D:newversion>DAV:FDFEE55544</D:newversion>
       </D:resolutionitem>

       Once
          <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 a client has resolved an issue (or decided mechanism for parallel changes to ignore it), the
       client a resource.
       A workspace configuration is responsible a mechanism for canceling the resolution item.  This is
       done using the DELETE method on parallel changes of
       multiple resources.

       For example, /MySite/ might contain all of the resolution item.

       >>Request
       DELETE http://foobar.com/reso/ZZZZ3493 HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/xml
       Content-Length: 0

  3.10.     Checkin Sets

       Clients may desire Web pages for V1 of
       my companies e-commerce site.   These have been put in the ability to track a set V1
       workspace.  A team responsible for developing V2 of changes as a unit.
       That is, the site would
       create a grouping of related changes.  This new workspace configuration based on V1.  The V2 workspace
       is achieved
       using populated with the MKCOL method to create V1 versions, but these resources can be
       versioned independently.  Essentially all resources have been
       "branched" in a special collection. Clients coordinated fashion.  Since this is a branch, both
       the V1 and the V2 revisions refer to the checkin set on all checkin (or change) requests.  The
       server automatically creates a "share" same versioned resource.
       This allows history and reports to the newly created
       revision in the identified collection.

  3.10.1.   Discovery

       Servers may choose be generated across workspaces.

  9.1. Managing Configuration Content

       Clients need to restrict where checkin sets can be created in able to access and manage the namespace.  Clients can discover this contents of a
       configuration.  This is done using OPTIONS. several different DAV methods.

       The
       Checkin-Sets-Root header identifies valid portions in the
       namespace.  Each header (there COPY method  can be multiple specified) identify used to copy a root and specific revision of a depth.  The BNF for
       resource.  However, this header is:

            Checkin-Sets-Root:= "Checkin-Sets-Root" ":" URL "," Depth
            Depth            := "inifinity" | number

       Note that if a resourceÆs parent results in the namespace has a new versioned resource being
       created.

       Resources are added to and removed from workspace configurations
       using the MKREF and DELREF methods defined
       checkin set root, by the resource CANNOT define DAV Advanced
       Collections Working Group.  Note that direct references are
       required.

       Clients can obtain the contents of a separate root for
       itself.

       This example shows how configuration using PROPFIND
       to discover enumerate the checkin set root for hierarchy under the
       /somefolder resource.

       >> Request

       OPTIONS /somefolder/ HTTP/1.1
       Verify-Extension: DAV:versioning
       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, PIN, MKREF
       Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
       MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, PIN, MKREF
       Verify-Extension: DAV:versioning
       Versioning-Support: DAV:basicversioning, DAV:configurations,
       DAV:checkinsets
       Checkin-Sets-Root: /, infinity
       Content-Length: 0
  3.10.2.   Usage configuation's collection.  As
       well, as stated above, clients can use the Configuration-Id header
       as described previously.

  9.2. Default Workspace Configurations

       Clients create checkin sets using MKCOL and specify can establish a special body
       tag to indicate default workspace configuration that a checkin set collection is being created. 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 the default configuration.

       >>Request

       MKCOL /cs/244

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

       <?xml version="1.0" encoding="utf-8" ?>
       <D:checkinset xmlns:D="DAV:"/>
       <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 the ability to track a set of changes as a unit.
       That is, create a grouping of related changes.  This is achieved
       using the MKCHECKINSET method to create a special collection.
       Clients refer to this the checkin set on all checkin (or change)
       requests.  The server automatically creates a "share" to the newly
       created revision in the identified collection.

       Checkin sets are specific to a configuration and are created using
       the Checkin-Set header. MKCHECKINSET method.  The BNF DAV:checkinsetroot property on a
       configuration specifies the URL of a collection where checkin sets
       for the configuration exist.  This can be used for discovery or
       creation.  If a configuration doesn't support checkin sets, then
       this header is as follows:

            Checkin-Set := "Checkin-Set" ":" URI property will be empty.

       Clients create checkin sets using MKCHECKINSET.  The response
       includes the location of 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

       The following example illustrates use of checkin sets.

       >>Request

       UNLOCK

       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:unlockinfo>

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

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

       DAV:closed - This is a true (1) / false (0) property that indicates
       if this checkin set can be referenced in CHECKIN requests.  When a
       checkin set is created, this property is defaulted to 0.  Note that
       resources MAY choose to disallow clients from setting this property
       to 0 once a client has set it to 1.

       The following properties MUST be supported on all resources:

       DAV:checkinid - This read-only property returns the checkin id
       associated with this revision of the resource.

  4.

       A checkin that references a checkin set MUST be made to the
       configuration associated with the checkin set.

  11.  VERSION MAPPING

       This specification defines headers to specify configurations and
       resource versions.  However, there are times when clients require a
       single URI for when working against configurations or versions.
       Version mapping support allows servers to create namespaces that
       map to configurations and versions.

       Note that mappings are dynamic.  That is, as resources are added,
       removed, and modified, the changes are reflected in any active
       maps.

  4.1.

       To delete a mapping, use DELETE against the URI specified in the
       MKMAP request.

  11.1.     Discovery

       Version mapping

       Mapping support is optional. optional and support is discovered using OPTIONS
       to verify if the MKMAP method is supported.  Using the request body
       and the DAV:verinfo tag, clients can obtain the supported map
       styles.

        This example shows that the /cfgs/DFEE2034 configuration supports
       mapping to the /map/ root in the namespace.

       >> Request

       OPTIONS /cfgs/DFEE2034 HTTP/1.1
       Verify-Extension: DAV:versioning
       Host: foobar.com
       Content-Type: text/xml
       Content-Length: 0 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, PIN, MKREF MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
       MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, PIN, MKREF
       Verify-Extension: MKREF, FREEZE, THAW,
       CHECKIN,
       CHECKOUT, UNCHECKOUT, BRANCH
       Versioning: DAV:versioning
       Versioning-Support: DAV:basicversioning, DAV:mapping
       Mapping-Root: /map/
       Mapping-Styles: DAV:detailedmap, DAV:branchmap, DAV:nestedbranch
       Content-Type: text/xml
       Content-Length: 0

       The BNF for this OPTIONS header is as follows:

            Mapping-Root   := "Mapping-Root" ":" URL

            Mapping-Styles := "Mapping-Styles" ":" URL-List

       Note that multiple Mapping-Root headers is permitted.

  4.2. 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 MKCOL MKMAP method is used to create namespaces based on a
       configuration.  When a configuration is mapped to a new namespace,
       all elements within the configuration can be directly accessed
       within the namespace without requiring the configuration to be
       identified in the header.

       In the example below, a new namespace is created for accessing the
       contents of the /cfgs/DFEE2034 configuration.

       >> Request

       MKCOL /map/mymap

       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

  4.3.

  11.3.     Mapping Resource Versions

       The MKCOL MKMAP method is also used to create namespaces based on a
       resourceÆs
       resource's versions (i.e., its revision graph).  When a resource is
       mapped, its revision history (revision graph) within the
       configuration is made available without requiring the Revision-Id
       header.  Within the mapped namespace, a hierarchy is created for
       the revisions.

       However, there are different ways to map the history.  Consider the
       following revision history of the versioned resource bar.htm:

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

       The following diagrams illustrate possible mappings:

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

        V1                          Primary  Test           Primary
        |                              |       |               |
        +----+--------+                V1     V1.1             +------Test             +------ 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 the example below, a new namespace is created for accessing the
       versions of the /foo/bar.htm resource in the /cfgs/DFEE2034
       configuration.

       >> Request
       MKCOL /map/mymap2

       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 DAV:detailedmap, DAV:branchmap, or
       DAV:nestedbranchmap, they must map MKMAP, then it MUST support DAV:detailedmap as
       illustrated above.

  5.      MISCELLANEOUS FUNCTIONS

       The following sub-sections detail miscellaneous versioning
       functions.

  5.1. Destroy

       Many version management systems use tombstones to note deleted
       items.  These systems also support the ability to permanently
       destroy tombstones for an object.  The DESTROY method provides this
       functionality and resources SHOULD support it, but resources are
       not required to implement it.  Resources MUST return an error for
       DESTROY requests that are not honored.

  5.1.1.    Discovery

       Discovery of this feature is determined by seeing if the resource
       options include the DESTROY method.

  5.1.2.    Usage

       The DESTROY method is used against a specific resource to
       permanently remove it.  This is a namespace level-operation.  That
       is, all resources matching the specified URI are destroyed.

       >>Request

       DESTROY /foo/bar/x.cpp HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/xml
       Content-Length: xxxx
       Note that this request can be qualified by a configuration.
       Requests to DESTROY resources that are in use by other
       configurations MAY fail or delay the destruction until all
       references are removed.

  5.1.3.    Headers

       Clients may chose to display deleted but not destroyed objects
       however they choose.  The header keyword Show-Deleted is used to
       indicate if deleted items should be included in the GET request.
       By default, they are not.  Inclusion of "Show-Deleted: Y" indicates
       that deleted resources should be included.  Using "Show-Deleted: O"
       indicates that only resources that have been deleted should be
       returned.  Using "Show-Deleted: N" indicates that deleted resources
       shouldnÆt be returned.

            Show-Deleted := "Show-Deleted" ":" ("Y" | "N" | "O")

  5.1.4.    Properties

       DAV:isdeleted - A 0/1 property where 1 indicates that the resource
       has been deleted.

  6.

  12.  THE DAV VERSIONING GRAMMAR

       To be supplied - Describe and detail the DTDs

  7.

  13.  INTERNATIONALIZATION CONSIDERATIONS

       To be supplied.

  8.

  14.  SECURITY CONSIDERATIONS

       To be supplied.

  9.

  15.  SCALABILITY

       To be supplied.

  10.

  16.  AUTHENTICATION

       Authentication mechanisms defined in WebDAV will also apply to DAV
       Versioning.

  11.

  17.  IANA CONSIDERATIONS

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

  12.

  18.  COPYRIGHT

       To be supplied.

  13.

  19.  INTELLECTUAL PROPERTY

       To be supplied.

  14.

  20.  REFERENCES

       [DAVVERREQ] TBD, "Requirements for DAV Versioning and Variant
       Authoring", October 1998, internet-draft, work-in-progress, draft-ietf-webdav-
       versionreqs-00.txt 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] Y. Goland, E.J. Whitehead, A. Faizi, S.R. Carter, D.
       Jenson, "Extensions for Distributed Authoring on the World Wide
       Web", October April. 1998, internet-draft, work-in-progress, draft-ietf-
       webdav-protocol-09.
       webdav-protocol-08.

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

  15.

  21.  AUTHOR'S ADDRESSES

       Christopher Kaler, Editor
       Microsoft
       One Microsoft Way
       Redmond 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

       TBD - list all members of the working group

  16.

  22.  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 time format should we use?

       - Should PIN be a method or a property?

       -

       .  What additional resource branching support is needed?

       -

       .  Schema discovery is an issue.  For example, how to
          discover/change mutable/immutable properties?

       -

       .  There are several missing examples / replies that need to be
          specified.

  17.

  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.