WEBDAV Working Group                     Y. Y. Goland, Microsoft
          INTERNET-DRAFT                 E. J. Whitehead, Jr., U.C. Irvine
         <draft-ietf-webdav-protocol-01>              Asad
          <draft-ietf-webdav-protocol-02>               A. Faizi, Netscape
                                                 Stephen R.
                                                       S. R Carter, Novell
                                                        Del
                                                         D. Jensen, Novell
          Expires January 15, 1997                            July 13, March 8, 1998                          September 3, 1997

                   Extensions for Distributed Authoring and Versioning
                                        on the
                                World Wide Web -- 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 documents as Internet-Drafts.

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

          To learn the current status of any Internet-Draft, please check
          the "1id-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), ds.internic.net (US East
          Coast), or ftp.isi.edu (US West Coast).

          Distribution of this document is unlimited. Please send comments
          to the Distributed Authoring and Versioning (WEBDAV) working
          group at <w3c-dist-auth@w3.org>, which may be joined by sending a
          message with subject "subscribe" to <w3c-dist-auth-
          request@w3.org>.

          Discussions of the WEBDAV working group are archived at
          <URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.

          Abstract

          This Document specifies a set of methods and content-types
          ancillary to HTTP/1.1 for the management of resource properties,
          simple name space manipulation, simple resource locking
          (collision avoidance) and resource version control.

                                  Table of Contents
          Abstract
          1    Terminology
          2    Data Model and Methods for DAV Properties
               2.1  Introduction
                   2.1.1............................The
                    2.1.1                            The DAV Property
                   2.1.2.................Existing
                    2.1.2                 Existing Metadata Proposals
                   2.1.3.................Properties
                    2.1.3                 Properties and HTTP Headers
               2.2  A Property Model for HTTP Resources
                   2.2.1....................................Overview
                   2.2.2..........................Property
                    2.2.1                                    Overview
                    2.2.2                          Property Namespace
                   2.2.3.........................Property Attributes

                   2.2.4.....................................Schemas
               2.3  Schemas
                    2.3.1                      PropSchema XML Element
                    2.3.2                             DTD XML Element
                    2.3.3                    DefinedProps XML Element

                    2.3.4                     PropEntries XML Element
                    2.3.5                            Live XML Element
               2.4  DAV Schema
                   2.3.1..............................Live Attribute
                   2.3.2..........................ReadOnly
                    2.4.1                                DAV Property
                    2.4.2                           Level XML Element
                    2.4.3                            Prop XML element
                    2.4.4                       PropLoc XML Attribute
                   2.3.3....................................Elements
              2.4
                    2.4.5                                     Example
               2.5  Property Identifiers
                   2.4.1..........................Problem
                    2.5.1                          Problem Definition
                   2.4.2........................Solution Requirement
                   2.4.3...........................DAV URL Parameter
                   2.4.4...............................Name Encoding
                   2.4.5...........Compatibility with legacy systems
              2.5
               2.6  Link XML Element
                   2.5.1.........................Problem
                    2.6.1                         Problem Description
                   2.5.2.......................Solution
                    2.6.2                       Solution Requirements
                   2.5.3............................Link
                    2.6.3                            Link XML Element
                   2.5.4.............................Src
                    2.6.4                             Src XML Element
                   2.5.5.............................Dst
                    2.6.5                             Dst XML Element
                   2.5.6.....................................Example
              2.6
                    2.6.6                                     Example
               2.7  Multi-Status Response
                    2.7.1                          Problem Definition
                    2.7.2                       Solution Requirements
                    2.7.3                       Multi-Status Response
               2.8  Properties and Methods
                   2.6.1......................................DELETE
                   2.6.2.........................................GET
                   2.6.3............................PROPPATCH Method
                   2.6.4.........................................PUT
                   2.6.5......................................SEARCH
                    2.8.1                                      DELETE
                    2.8.2                                         GET
                    2.8.3                                   PROPPATCH
                    2.8.4                                         PUT
                    2.8.5                                    PROPFIND
          3    A Proposal for Collections of Web Resources and Name Space
          Operations
               3.1  Observations on the HTTP Object Model
                   3.1.1........................Collection
                    3.1.1                        Collection Resources
                    3.1.2Creation and Retrieval of Collection Resources
                   3.1.3.......Source
                    3.1.3       Source Resources and Output Resources
               3.2  MKCOL Method
                   3.2.1.........................Problem
                    3.2.1                         Problem Description
                   3.2.2.......................Solution
                    3.2.2                       Solution Requirements
                   3.2.3.....................................Request
                   3.2.4....................................Response
                   3.2.5.....................................Example
                    3.2.3                                     Request
                    3.2.4                                    Response
                    3.2.5                                     Example
               3.3  INDEX Method
                   3.3.1.........................Problem
                    3.3.1                         Problem Description
                   3.3.2.......................Solution
                    3.3.2                       Solution Requirements
                   3.3.3.................................The
                    3.3.3                                 The Request
                   3.3.4................................The
                    3.3.4                                The Response
                    3.3.5                       Response
                   3.3.5.......................Response Message Body
                   3.3.6.....................................Example
                    3.3.6                                     Example
               3.4  Behavior of RFC 2068 Methods on Collections
                   3.4.1...................GET,
                    3.4.1                   GET, HEAD for Collections
                   3.4.2........................POST
                    3.4.2                        POST for Collections
                   3.4.3.........................PUT
                    3.4.3                         PUT for Collections
                   3.4.4......................DELETE
                    3.4.4                      DELETE for Collections
               3.5  COPY Method
                   3.5.1.........................Problem
                    3.5.1                         Problem Description
                   3.5.2.......................Solution
                    3.5.2                       Solution Requirements
                   3.5.3.................................The
                    3.5.3                                 The Request
                   3.5.4................................The
                    3.5.4                                The Response
                   3.5.5....................................Examples
                    3.5.5                                    Examples
               3.6  MOVE Method
                   3.6.1.........................Problem
                    3.6.1                         Problem Description
                   3.6.2.......................Solution
                    3.6.2                       Solution Requirements
                   3.6.3.................................The
                    3.6.3                                 The Request
                   3.6.4................................The
                    3.6.4                                The Response
                   3.6.5....................................Examples
                    3.6.5                                    Examples
               3.7  Multi-Status Response
                   3.7.1..........................Problem Definition
                   3.7.2.......................Solution Requirements
                   3.7.3.......................Multi-Status Response
                   3.7.4.....................................Example

              3.8  ADDREF Method
                   3.8.1..........................Problem
                    3.7.1                          Problem Definition
                   3.8.2.......................Solution

                    3.7.2                       Solution Requirements
                   3.8.3.................................The
                    3.7.3                                 The Request
              3.9
               3.8  DELREF Method
                   3.9.1..........................Problem
                    3.8.1                          Problem Definition
                   3.9.2.......................Solution
                    3.8.2                       Solution Requirements
                   3.9.3.................................The
                    3.8.3                                 The Request
              3.10
               3.9  PATCH Method
                   3.10.1.........................Problem
                    3.9.1                          Problem Definition
                   3.10.2......................Solution
                    3.9.2                       Solution Requirements
                   3.10.3................................The
                    3.9.3                                 The Request
                   3.10.4.........application/XML
                    3.9.4          application/XML elements for PATCH
                   3.10.5...............................The
                    3.9.5                                The Response
                   3.10.6...................................Examples
              3.11
                    3.9.6                                    Examples
               3.10 Headers
                   3.11.1......................................Depth
                   3.11.2................................Destination
                   3.11.3....................Enforce-Live-Properties
                   3.11.4.......................Duplicate-Properties
                   3.11.5..................................Overwrite
                   3.11.6.............................Destroy
                    3.10.1                                      Depth
                    3.10.2                                Destination
                    3.10.3                    Enforce-Live-Properties
                    3.10.4                       Duplicate-Properties
                    3.10.5                                  Overwrite
                    3.10.6                             Destroy Header
                   3.11.7...................Collection-Member
                    3.10.7                           Mandatory header
                    3.10.8                   Collection-Member Header
              3.12
               3.11 Links
                   3.12.1..................Source
                    3.11.1                  Source Link Property Type
          4    State Tokens
               4.1  Overview
                   4.1.1.........................Problem
                    4.1.1                         Problem Description
                   4.1.2.......................Solution
                    4.1.2                       Solution Requirements
               4.2  State Token Syntax
               4.3  State Token Conditional Headers
                   4.3.1..............................If-State-Match
                   4.3.2.........................If-None-State-Match
                    4.3.1                              If-State-Match
                    4.3.2                         If-None-State-Match
               4.4  State Token Header
               4.5  E-Tags
          5    Locking
               5.1  Problem Description - Overview
                   5.1.1..................Exclusive
                    5.1.1                  Exclusive Vs. Shared Locks
                   5.1.2............................Required
                    5.1.2                            Required Support
               5.2  LOCK Method
                   5.2.1...................................Operation
                   5.2.2The Effect
                    5.2.1                                   Operation
                    5.2.2Effect of Locks on Properties and Containers
                   5.2.3................Locking
                    5.2.3                Locking Replicated Resources
                   5.2.4..............Interaction
                    5.2.4              Interaction with other Methods
                   5.2.5....................Lock
                    5.2.5                    Lock Compatibility Table
                   5.2.6................................Status
                    5.2.6                                Status Codes
                   5.2.7.....................................Example
                   5.2.8....................Lock-Info
                    5.2.7                                     Example
                    5.2.8                    Lock-Info Request Header
                   5.2.9........................Owner
                    5.2.9                        Owner Request Header
                   5.2.10............................Time-Out
                    5.2.10                            Time-Out Header
                   5.2.11.........................State-Token
                    5.2.11                         State-Token Header
               5.3  Write Lock
               5.4  Lock Tokens
                   5.4.1.........................Problem
                    5.4.1                         Problem Description
                   5.4.2...........................Proposed
                    5.4.2                           Proposed Solution
                   5.4.3.......................Lock
                    5.4.3                       Lock Token Definition
               5.5  UNLOCK Method
                   5.5.1..........................Problem
                    5.5.1                          Problem Definition
                   5.5.2.....................................Example
                    5.5.2                                     Example
               5.6  Discovery Mechanisms
                   5.6.1.........................Lock
                    5.6.1                         Lock Type Discovery
                   5.6.2.......................Active
                    5.6.2                       Active Lock Discovery
          6    Version Control
          7    Internationalization Support
          8    Security Considerations
          9    Acknowledgements

          10   References
          11   Authors' Addresses
         Appendix

          1 - Content Type Application/XML
              Syntax
              XML element
              Entity-Name
              Close
              XML Encoding
              Markup Modifier
              XML Syntax Shorthand
         Appendix 2 - Parameter Syntax for Content-Type Application/XML
              Schema Content-Type Parameter
         Appendix 3 – URI Path Encoding
              Problem Definition
              Solution Requirement
              Path Component
         Appendix 4 - XML URI
         Appendix 5 - XML elements
              Ref XML element
              Namespace
                   Namespace XML element
                   AS XML element
                   Required XML element
                   The XML URI and Namespace

         1  Terminology
         Collection    Terminology

          Collection - A resource that contains member resources.

          Member Resource - a resource referred to by a collection. There
          are two types of member resources: external and internal.

          Internal Member Resource - the name given to a member resource of
          a collection whose URI is relative to the URI of the collection.

          External Member Resource - a member resource with an absolute URI
          that is not relative to its parent’s URI.

          Properties – Also known as small-chunk metadata, a hierarchical - A set of name/value pairs that describe contain descriptive
          information about a resource.

          Live Properties  - Properties whose semantics and syntax are
          enforced by the server. For example, a live “read-only” "read-only" property
          that is enforced by the server would disallow PUTs to the
          associated resource.

          Dead properties  - Properties whose semantics and syntax are not
          enforced by the server. A dead “read-only” "read-only" property would not be
          enforced by the server and thus would not be used by the server
          as a reason to disallow a PUT on the associated resource.

          2    Data Model and Methods for DAV Properties

          2.1  Introduction

          2.1.1     The DAV Property

          Properties are pieces of data that describe the state of a
          resource. Properties are data about data. The term property is
          used within this specification to disambiguate the concept from
          the overloaded terms “metadata” "metadata" and “attribute”. "attribute".
          Properties are used within distributed authoring environments to
          provide for efficient discovery and management of resources. For
          example, a ‘subject’ 'subject' property might allow for the indexing of all
          resources by their subject, and an ‘author’ 'author' property might allow
          for the discovery of what authors have written which documents.

          2.1.2     Existing Metadata Proposals

          Properties have a long played an essential role in the
          maintenance of large document repositories, and many current
          proposals contain some notion of a property. These include PICS
          [Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney,
          1996], Web Collections, XML [Bray, Sperberg-McQueen, 1997],
          several proposals on representing relationships within HTML,
          digital signature manifests (DCMF), and a position paper on Web
          metadata architecture [Berners-Lee, 1997].

          Some proposals come from a digital library perspective. These
          include the Dublin Core [Weibel et al., 1995] metadata set and
          the Warwick Framework [Lagoze, 1996], a container architecture
          for different metadata schemas. The literature includes many

          examples of metadata, including MARC [MARC, 1994], a
          bibliographic metadata format, RFC 1807 [Lasher, Cohen, 1995], a
          technical report bibliographic format employed by the Dienst
          system, and the proceedings from the first IEEE Metadata
          conference describe many community-specific metadata sets.

          Participants of the 1996 Metadata II Workshop in Warwick, UK
          [Lagoze, 1996], noted that, "new metadata sets will develop as
          the networked infrastructure matures" and "different communities
          will propose, design, and be responsible for different types of
          metadata." These observations can be corroborated by noting that
          many community-specific sets of metadata already exist, and there
          is significant motivation for the development of new forms of
          metadata as many communities increasingly make their data
          available in digital form, requiring a metadata format to assist
          data location and cataloging.

          2.1.3     Properties and HTTP Headers

          Properties already exist, in a limited sense, within HTTP through
          the use of message headers. However, in distributed authoring
          environments a relatively large number of properties are needed
          to
         fully describe the state of a resource, and setting/returning them
          all through HTTP headers is inefficient. Thus a mechanism is
          needed which allows a principal to identify a set of properties
          in which the principal is interested and to then set or retrieve
          just those properties.

          2.2  A Property Model for HTTP Resources

          2.2.1     Overview

          The DAV property model is based on name/value/attribute triples. name/value doubles. The name
          of a property identifies the property’s property's syntax and semantics, and
          provides an address with which to refer to a property. The name
          and value of a property is an octet stream. The
         attributes of a property are expressed as a set well-formed XML
          element, where the name of name/value pairs that are
         not directly addressable. Attributes are retrieved in conjunction
         with retrieving a property, and are set when changing a property’s
         value. This specification defines two attributes, live, which
         indicates if the property’s syntax and semantics property is enforced by the server, name of the XML
          element, and readonly, which indicates that the property’s value may of the property MUST be retrieved but not set. either blank, or a
          well-formed XML element value.

          2.2.2     Property Namespace

          2.2.2.1   Problem Definition

          The requirement is to be able to associate a value with a
          property name on a resource and to be able to directly address
          that value.

          2.2.2.2   Solution Requirement

          Ideally a property namespace should work well with extant
          property implementations as well as database systems. The DAV
          property namespace has been specified with the following two
          facts in mind:
          ·    Namespaces associated with flat file systems are certainly ubiquitous.

            Many
          ·    The majority of databases use a fixed schema mechanism, which mechanism.
          The last point makes efficient implementation of hierarchical
          properties difficult. Specifically, each property has a random
          set of children; the best a relational database can do is provide

          a table with name and value, where the value is a series of
          indexes into other tables and each index represents a specific
          value. However most RDBS do not provide for table pointers, only
          index values. Such a system would have to be jury-rigged to
          handle table pointers. In addition, indexing systems are
          optimized for a small set of relatively large tables;
          hierarchical property systems tend toward many properties, each
          with different numbers and types of children, thus potentially
          requiring a table for each child.

          It would seem best to implement a flat property namespace,
          inducing a natural isomorphism between DAV and most native file
          systems. Adopting such a model should will not restrict RDBS from taking
          full advantage of their search facilities.

          However, it seems that future trends might be toward hierarchical
          properties. As such, Therefore, DAV requirements [] [Slein et al.] stipulate
          that the design of the flat property system MUST be such that it
          will be possible to add true hierarchical properties later
          without breaking downlevel clients. Specifically, a flat client
          MUST be able to speak to a hierarchical server and a hierarchical
          client MUST be able to speak to a flat server. Worst case either
          way MUST be that the request fails.

          2.2.2.3   Property Names

          A property name identifies both the syntax and semantics of the property’s
          property's value. It is critical that property names do not
          collide, e.g., two principals defining the same property name
          with two different meanings.

          The URI framework provides for a mechanism to prevent namespace
          collision and for varying degrees of administrative control.
          Rather than reinvent these desirable features, DAV properties
          make use of them by requiring that all DAV property names MUST be
          URIs.  Since a property is also an XML element, the name of the
          XML element is a URI.

          The property namespace is flat, that is, it is not possible to
          string together a series of property names in order to refer to a
          hierarchy of properties. Thus it is possible to refer to a
          property A B but not a property A/B.

            2.2.3     Property Attributes

            The attributes of A/B, where is also a property provide information about
          defined on the
            property. Note that a property contains information about a resource.

            Attributes consist of name/value pairs whose value MUST be a
            string. Attributes are

          Finally, it is not directly addressable, rather they
            are retrieved and defined possible to define the same property twice as
          this would cause a collision in the context resource's property
          namespace.

          2.3  Schemas

          A schema is a group of other property
            operations. For example, names and XML elements.

          Schema discovery is used to determine if one retrieves a property value,
            the attributes will also be returned. If one sets system supports a property
            value, one may also specify the values for its attributes.

            All attributes on a server MUST be live. This means that the
            server MUST only record attributes with syntax and semantics
            the server understands and enforces. This normally means
            that clients can not define new attributes on a property;
            clients may only make use of the attributes supported by the
            server.

            If a client submits an attribute when setting a property
            then the server MUST NOT record the property unless it
            accepts the values specified for the corresponding
            attributes. Thus, if a property value is submitted with a
            live attribute then the server MUST NOT record the value
            unless the server understands and enforces the syntax and
            semantics of the property.

            2.2.4     Schemas

            A schema is a group of property names, attributes, and XML
            elements.

            It is often useful to indicate support for a particular
            schema in a request or a response. Schema discovery is also
            useful for determining if a system supports a group of
            properties, attributes, or XML elements. A
          group of properties or XML elements. A property does not
          necessarily contain sufficient information to identify any
          schema(s) to which it may belong.

          As with property names, schemas MUST use URIs as their names.

            2.3 DAV Schema
            The DAV Schema is specified as
            http://www.ietf.org/standards/dav/. This schema is used to
            indicate

          A resource declares its support for

            properties and attributes that can be defined on a resource
               and

            XML elements that can be returned in responses.

            All DAV compliant servers MUST support schema by defining a
          property whose name is the DAV schema. same as the schema's. The property
          SHOULD contain the PropSchema XML element.

          2.3.1     Live Attribute     PropSchema XML Element

          Name: http://www.ietf.org/standards/dav/live     http://www.ietf.org/standards/dav/PropSchema
          Purpose:  To indicate that the property has its syntax and
            semantics enforced by the resource on which it is recorded. provide information about properties
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any property
          Values= “=” <”><”>

            Description: This attribute is used to indicate that the
            resource expressing the   [DTD] [DefinedProps]
          Description:This property understands and enforces contains the syntax and semantics definition of the property. The absence schema.
          This definition consists of the
            Live attribute in two parts. A DTD element that
          contains a response indicates to the client DTD that
            the corresponding property does not have its syntax declares all XML elements and
            semantics enforced by DefinedProps
          that defines any properties associated with the resource on which schema. As with
          all XML it is recorded.
            If a live attribute is included when setting the value of a
            property then the server SHOULD set the property if the
            property will be live and MUST NOT set the property if the
            property will not possible to add extra XML elements. Therefore
          schemas may define extra XML elements which are to be live. included
          with their values.

          2.3.2     ReadOnly Attribute     DTD XML Element

          Name: http://www.ietf.org/standards/dav/readonly          http://www.ietf.org/standards/dav/DTD
          Purpose:  To indicate that a property can be retrieved, but
            not set through contain the property mechanism. DTD for XML elements associated with the
          schema.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any property

            Values= “=” <”><”>

            Description: This attribute is used to indicate that the
            property can only be retrieved, not set through the property
            mechanism. This attribute is not meant as an access control
            mechanism but rather to reflect the fact that the property
            is not designed to have its value set through the property
            mechanism. If this attribute is included when setting the
            value of a property, the request MUST be rejected since
            accepting the value would violate ReadOnly attribute. A
            server MUST NOT effect a property protocol element that is
            inconsistent or ill-defined with respect to the element’s
            attribute state, were it to be expressed.
          Values:   XML Declaration statements

          2.3.3     Elements

            2.3.3.1   Prop     DefinedProps XML element Element

          Name: http://www.ietf.org/standards/dav/prop          http://www.ietf.org/standards/dav/DefinedProps
          Purpose:  To specify the name and value of contain a property list of properties defined by the schema.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any

            Values: PropName PropValue

            2.3.3.2   PropName
          Values=   1*PropEntries

          2.3.4     PropEntries XML element Element

          Name: http://www.ietf.org/stnadards/dav/name          http://www.ietf.org/standards/dav/PropEntries
          Purpose:  To specify contain the name of a defined property, which MUST be a
            URI. the DTD of
          its value, and its live/dead status.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   DefinedProps
          Values=   Prop

            Values: URI

            2.3.3.3   PropValue [DTD] [Live]
          Description:Prop contains the name of the property. The DTD
          contains the DTD of the property's value. Live, if defined,
          indicates that the property has semantics and syntax that are
          enforced by the server.

          2.3.5     Live XML element Element

          Name: http://www.ietf.org/standards/dav/propvalue          http://www.ietf.org/standards/dav/Live
          Purpose: To specify  If present this indicates the value server MUST enforce the
          syntax and semantics of a the property.
          Schema:   http://www.ietf.org/standards/dav/
          Parent: Prop

            Values: The contents of a property.   PropEntries

          2.4 Property Identifiers

            2.4.1     Problem Definition  DAV Schema

          The addition of DAV properties Schema is specified as
          http://www.ietf.org/standards/dav/. This schema is used to the HTTP object model
            introduces the need
          indicate support for a mechanism to unambiguously refer
            to either the body of the resource or the
          ·    properties of that may be defined on a
            resource.

            2.4.2     Solution Requirement

            The mechanism used for referring to the resource body must
            also and
          ·    XML elements that may be usable returned in responses.

          2.4.1     DAV Property

          Name:          http://www.ietf.org/standards/dav
          Purpose:  Defines support for referring to the resource’s properties,
            such that even non-DAV aware clients can retrieve DAV
            properties.

            2.4.3 schema and protocol.
          Schema:   http://www.ietf.org/standards/dav/
          Values=   PropSchema Level
          Description:This property indicates that the resource supports
          the DAV URL Parameter schema and protocol to the level indicated. THE VALUE IN
          PROPSCHEMA IS TBD, WE NEED TO PROVIDE IT IN AN APPENDIX.

          2.4.2     Level XML Element

          Name:          http://www.ietf.org/standards/dav/level
          Purpose:  To allow for indicate the specification level of property information in DAV compliance the context resource
          meets.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   DAV
          Values=   "1" | "2" | "3"
          Description:A value of an http scheme URL, a switch is needed. The
            switch 1 for level indicates that following path segments specify a
            property location. To this end the “DAV” param is introduced
            for use with http scheme URLs. The path segment to resource
          supports the right property and namespace sections of the DAV param MUST be formatted according to
          specification. Level 2 indicates that the XML Link
            standard, described in Appendix 3.

            2.4.4     Name Encoding

            Properties on a resource are given URIs as a name. Thus, in
            order to be able to refer to a property one must be able to
            put supports level
          1 and the property’s URI into an HTTP URI.

            For example, lock section of the author property specification, with full name
            http://www.w3.org/standards/z39.50/author is defined on
            http://somewhere.com/resource.

            To create a reference to minimum
          locking capability of the author one would perform write lock. Level 3 indicates support
          for levels 1 and 2 as well as support for the
            following steps.

            Add versioning section
          of the DAV parameter to the base URI,
               http://somewhere.com/resource;DAV.

            Add “/” specification.

          2.4.3     Prop XML element

          Name:          http://www.ietf.org/standards/dav/prop
          Purpose:  Contains properties related to refer a resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values:   XML Elements
          Description:The Prop XML element is a generic container for
          properties defined on resources. All elements inside Prop MUST
          define properties related to the root resource. No other elements may
          be used inside of a Prop element.

          2.4.4     PropLoc XML Attribute

          Name:          http://www.ietf.org/standards/dav/PropLoc
          Purpose:  To specify the resource’s property
               namespace, http://somewhere.com/resource;DAV/.

            Change location of the author property’s name into parameter format by
               changing “/”s associated property.
          Schema:   http://www.ietf.org/standards/dav/
          Values=   URL
          Description:This attribute is used with elements inside of Props
          contained in responses to “!”s and encasing specify the entire value in
               parenthesis. URL of the property on the
          associated resource. The value must PropLoc attribute MUST NOT be encased in parenthesis used in
               order to indicate the “/” to “!” translation.
          requests.

          2.4.5     Example

          <?XML:Namespace href="http://www.ietf.org/standards/dav/"
          AS="D"/>
          <?XML:Namespace href="AIIM:Dublin:" AS="A"/>
          <D:Prop>
               <A:Author
          D:PropLoc="http://www.foo.com/resource/props/Author">
                    Larry Masinter
               </A:Author>

          </D:Prop>

          The
               translation “/” to “!” is done in order to prevent
               confusion over segments boundaries, and to make sure previous specifies that the syntax for relative URIs remains well-defined.
               http://somewhere.com/resource;DAV/(http:!!www.w3.org!stand
               ards!z39.50!author).

            The process is now complete, property author exists on some
          unspecified resource and that the URL property can be used in a
            GET or PATCH to retrieve or alter the value. See appendix 3
            for more information.

            2.4.5     Compatibility with legacy systems

            2.4.5.1   Problem Definition directly
          referenced at http://www.foo.com/resource/props/Author. The HTTP parameter space
          resource upon which the property is uncontrolled, thus someone may
            already defined must be using a parameter with determined
          from context.

          2.5  Property Identifiers

          2.5.1     Problem Definition

          DAV properties are resources and thus may have a URI where the
          value of “DAV” for some
            end other than an instance of the one described here. Thus a client sending
            a property may be retrieved.  This URI with a DAV param
          is separate from the URI name of the property, which identifies
          the syntax and semantics of the property, but which does not give
          information on how to a server may receive access the value of an unexpected
            or inappropriate response.

            2.4.5.2   Solution Requirement instance of the
          property.

          A mechanism server is needed free to prevent namespace collisions.

            2.4.5.3   Proposed Solution

            All DAV compliant servers MUST honor the DAV param type on
            http URLs. Thus if a client knows assign whatever URI it is talking chooses to a DAV
            server, it can safely send identify an http URL with the DAV param.

            The client may send the http URL with the DAV param
            extension to
          instance of a property defined on a resource. In fact, a server that
          is free not known to be DAV compliant
            if reveal the URI of an instance of a particular
          resource and instead require that the client uses PEP [Connolly, 1997] to prevent
            collisions. The proper PEP header is:

            DAVPEP = “PEP: {{map “DAV”}{strength must}}”

            Note: this PEP header is not compliant with [Connolly,
            1997]; access the PEP authors have indicated they property
          through PROPFIND and PROPPATCH.  However, many servers will change the
            format want
          to make allow clients to directly manipulate properties. On these
          servers, a client can discover the example legal.

            2.5 URI of an instance of a
          property by performing a PROPFIND and examining the PropLoc
          attribute, if returned, of each property.

          2.6  Link XML Element

            2.5.1

          2.6.1     Problem Description

          A mechanism is needed to associate resources with other
          resources. These associations, also known as links, consist of three
          values, a type describing the nature of the association, the
          source of the link, and the destination of the link. In the case
          of annotation, neither the source nor the destination of a link
          need be the resource upon which the link is recorded.

            2.5.2

          2.6.2     Solution Requirements

          The association mechanism MUST make use of the DAV property
          mechanism in order to make the existence of the associations
          searchable.

            2.5.3

          2.6.3     Link XML Element

          Name:          http://www.ietf.org/standards/dav/link
          Purpose: The XML document which is  To identify a property as a link and to contain the value
          source and destination of a that link.
          Schema:   http://www.ietf.org/standards/dav/
          Values= An XML document which MUST have a src and dst XML
            element.

            Description: Link   1*Src 1*Dst
          Description:Link is used to provide the source sources and one or
            more destinations
          of the a link. The type of the property containing the Link XML
          element provides the type of the link. Link is a multivalued
            element,so multi-valued
          element, so multiple Links may be used together to indicate
          multiple links with the same type.

            2.5.4

          2.6.4     Src XML Element

          Name: http://www.ietf.org/standards/dav/src
          Purpose: To indicate the source of a link.
          Schema: http://www.ietf.org/standards/dav/
          Parent: http://www.ietf.org/standards/dav/link
          Values= URI

            2.5.5

          2.6.5     Dst XML Element

          Name: http://www.ietf.org/standards/dav/Dst
          Purpose: To indicate one or more destinations the destination of a link
          Schema: http://www.ietf.org/standards/dav/
          Parent: http://www.ietf.org/standards/dav/link
          Values= URI

            2.5.6

          2.6.6     Example

            <XML>
                 <Namespace><Ref>http://www.ietf.org/standards/dav/</><A
                 S>D</></>

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" AS = "D"/>
          <?XML:Namespace
               href = "http://www.foocorp.com/Project/" AS = "F"/>
          <D:Prop>
                      <Propname>Source</>
                      <Propvalue>
                           <XML:XML>
                                <Namespace>

                                     <Ref>http://www.ietf.org/standards/
                                dav/</><AS>D</>
                                </>
                                <Namespace>

                                     <Ref>http://www.foocorp.com/Project
                                /</><AS>F</>
                                </>
                                <D:Link>
                                     <F:ProjectFiles>Source</>
                                     <src>http://foo.bar/program</>

                      <dst>http://foo.bar/source/main.c</>
                                </>
                                <D:Link>
                                     <F:ProjectFiles>Library</>
                                     <src>http://foo.bar/program</>

                      <dst>http://foo.bar/source/main.lib</>
                                </>
                                <D:Link>
                                     <F:ProjectFiles>Makefile</>
                                     <src>http://foo.bar/program</>

                      <dst>http://foo.bar/source/makefile</>
            </>  </>  </>  </>  </>
               <Source>
                    <Link>
                         <F:ProjFiles>Source</F:ProjFiles>
                         <src>http://foo.bar/program</src>
                         <dst>http://foo.bar/src/main.c</dst>
                    </Link>
                    <Link>
                         <F:ProjFiles>Library</F:ProjFiles>
                         <src>http://foo.bar/program</src>
                         <dst>http://foo.bar/src/main.lib</dst>
                    </Link>
                    <Link>
                         <F:ProjFiles>Makefile</F:ProjFiles>
                         <src>http://foo.bar/program</src>
                         <dst>http://foo.bar/src/makefile</dst>
               <Link>
               </Source>
          </D:Prop>

          In this example the resource http://foo.bar/program has a source
          property defined which contains three links. Each link contains
          three elements, two of which, src and dst, are part of the DAV
          schema defined in this document, and one which is defined by the
          schema http://www.foocorp.com/project/ (Source, Library, and
          Makefile). A client which only implements the elements in the DAV
          spec will not understand the foocorp elements and will ignore
          them, thus seeing the expected source and destination links. An
          enhanced client may know about the foocorp elements and be able
          to present the user with additional information about the links.

            2.6 Properties and Methods

            2.6.1     DELETE

          2.7  Multi-Status Response

          2.7.1     Problem Definition

          Some methods effect more than one resource. The delete method, when used on a property, causes effect of the
            property to be removed.

            2.6.2     GET

            A GET
          method on a property returns the name each of the property. Accept
            types scoped resources may be used to different, as such
          a return format that can specify the format effect of the method on each
          resource is needed.

          2.7.2     Solution Requirements

          The solution must:
          - communicate the status code and reason
          - give the URI of the resource on which the method was invoked
          -    be consistent with other return value,
            but all DAV compliant servers body formats
          -

          2.7.3     Multi-Status Response

          The default multi-status response body is an text/xml HTTP entity
          that contains a single XML element called multiresponse, which
          contains a set of XML elements called response, one for each 200,
          300, 400, and 500 series status code generated during the method
          invocation.  100 series status codes MUST NOT be recorded in a
          response XML element.

          2.7.3.1   MultiResponse

          Name: http://www.ietf.org/standards/dav/multiresponse
          Purpose:  Contains multiple response messages.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Value:    1*Response [ResponseDescription]
          Description:The ResponseDescription at minimum support the top level is used to
          provide a
            return type general message describing the over arching nature of application/XML.
          the response. If application/XML this value is used
            as available an application MAY use
          it instead of presenting the individual response format then it MUST include descriptions
          contain within the
            http://www.ietf.org/standards/dav/ schema.

            2.6.2.1   Example

            GET bar;DAV/(http:!!www.w3.org!standards!z39.50!Authors)
            HTTP/1.1
            Host: foo.com

            HTTP/1.1 200 OK
            Content-Type: application/xml
            Content-Length: xxxx
            E-tag: “1234”
            Last-Modified: xxxx

            <XML>
                 <XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
            /><AS>D</></>
                 <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/
            </><AS>Z</></>
                 <D:prop>
                      <propname>Z:Authors</>
                      <propvalue>
                           <XML:XML>
                                <Namespace>

                                     <Ref>http://www.ietf.org/standards/
                                dav/</>
                                     <AS>D</>
                                </>
                                <Namespace>

                                <Ref>http://www.w3.com/standards/z39.50/
                           </>
                                     <AS>Z</>
                                </>
                                <Z:Author>Jane Doe</>
                                <Z:Author>Joe Doe</>
                                <Z:Author>Lots o’Doe</>
            </>  </>  </>  </>

            GET bar;DAV/(Dublin:Producer) HTTP/1.1
            Host: foo.com

            HTTP/1.1 200 OK

            Content-Type: application/xml
            Content-Length: xxxx
            E-tag: “2345”
            Last-Modified: xxxx

            <XML>
                 <XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
            /><AS>D</></>
                 <XML:Namespace><Ref>Dublin</><AS>Du</></>
                 <D:prop>
                      <propname>Du:Producer</>
                      <propvalue><XML:XML>Marcus Doe</></>
            </>  </>

            GET bar;DAV/ HTTP/1.1
            Host: foo.com

            HTTP/1.1 200 OK
            Content-Type: application/xml
            Content-Length: xxxx
            E-tag; “1234”
            Last-Modified: xxxx

            <XML>
                 <XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
            /><AS>D</></>
                 <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/
            </><AS>Z</></>
                 <XML:Namespace><Ref>Dublin</><AS>Du</></>
                 <D:prop>
                      <propname>Z:Authors</>
                      <propvalue>
                           <XML:XML>
                                <Namespace>

                                     <Ref>http://www.ietf.org/standards/
                                dav/</>
                                     <AS>D</>
                                </>
                                <Namespace>

                                <Ref>http://www.w3.com/standards/z39.50/
                           </>
                                     <AS>Z</>
                                </>
                                <Z:Author>Jane Doe</>
                                <Z:Author>Joe Doe</>
                                <Z:Author>Lots o’Doe</>
                 </>  </>  </>
                 <D:prop>
                      <propname>Du:Producer</>
                      <propvalue><XML:XML>Marcus Doe</></>
            </>  </>

            2.6.3     PROPPATCH Method

            The PROPPATCH method specifies how to alter a property. The
            message body controls the actual action taken by responses.

          2.7.3.2   Response

          Name: http://www.ietf.org/standards/dav/response
          Purpose:  Holds a
            PROPPATCH. All DAV compliant servers are required to support single response
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Value:    (Prop | HREF) Status [ResponseDescription]
          Description: Prop MUST contain one or more empty XML elements
          representing the use name of properties. Multiple properties may be
          included if the application/XML content-type using same response applies to them all. If HREF is
          used then the
            http://www.ietf.org/standards/dav/proppatch/ schema in response refers to a
            PROPPATCH method problem with a request-URI that points to the
            resource upon which the property is defined.

            The changes in a http://www.w3.com/standards/dav/proppatch/
            request MUST be atomically executed, partial results are referenced
          resource, not
            allowed.

            2.6.3.1   Request URI

            The request URI of a PROPPATCH method with the
            http://www.ietf.org/standards/dav/proppatch/ schema MUST
            point to the resource upon which the property is defined.

            2.6.3.2   PropertyUpdate XML element property.

          2.7.3.3   Status

          Name: http://www.ietf.org/standards/dav/PropertyUpdate http://www.ietf.org/standards/dav/status
          Purpose: To contain  Holds a request single HTTP status-line
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Response
          Value:    status-line   ;status-line defined in [Fielding et al.,
          1997]

          2.7.3.4   ResponseDescription

          Name:
          http://www.ietf.org/standards/dav/ResponseDescription
          Purpose:  Contains a message that can be displayed to alter the properties on a
            resource. user
          explaining the nature of the response.
          Schema:   http://www.ietf.org/standards/dav/

          Parent: <XML>

            Values= *(Create | Remove | Insert)   Multiresponse and/or Response
          Value:    Any
          Description:   This XML element is a container for the provides information required suitable to modify the
          be presented to a user.

          2.8  Properties and Methods

          2.8.1     DELETE

          As properties on the
            resource. This XML element is multivalued.

            2.6.3.3   Create XML element

            Name: http://www.ietf.org/standards/dav/create

            Purpose: To create are resources, the DAV deletion of a property specified inside causes
          the
            Create XML element.

            Schema: http://www.ietf.org/standards/dav/

            Parent: http://www.ietf.org/standards/dav/PropertyUpdate

            Values= Prop

            Description: This XML element contains a Prop same result as the only
            element. The PropName contains deletion of any resource. It is worth
          pointing out that the name deletion of a property effects both direct
          manipulation, that is by the property's URL, as well as indirect
          discovery and manipulation, that is PROPPATCH and PROPFIND.

          2.8.2     GET

          A GET with a Request-URI that identifies a property to
            be created or overwritten. The PropValue XML element
            contains returns the
          name and value of the new that property.

            2.6.3.4   Remove XML element

            Name: http://www.ietf.org/standards/dav/remove

            Purpose: To remove  Accept types may be used to
          specify the format of the return value, but all DAV compliant
          servers MUST at minimum support a return type of text/xml. If
          text/xml is used as the response format then it MUST return the
          name and value of the property specified inside using the
            Remove Prop XML element.

            Schema: http://www.ietf.org/standards/dav/

            Parent: http://www.ietf.org/standards/dav/PropertyUpdate

            Values= PropName

            Description: Remove specifies

          2.8.2.1   Example

          The following example assumes that the property specified in
            PropName should be removed. Specifying property's URL, originally
          generated by the removal of server, was discovered by examining the proploc
          XML attribute returned on a
            property that does not exist is not an error.

            2.6.3.5   Response Codes result from a FINDPROP.

          GET /bar.html;prop=z39.50_authors HTTP/1.1
          Host: foo.com

          HTTP/1.1 200 OK 
          Content-Type: text/xml
          Content-Length: xxxx
          E-tag: "1234"
          Last-Modified: xxxx

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" AS = "D"/>
          <?XML:Namespace
               href = "http://www.w3.com/standards/z39.50/"AS = "Z"/>
          <D:prop>
               <Z:Authors>
                    <Z:Author>Jane Doe</Z:Author>
                    <Z:Author>Joe Doe</Z:Author>
                     <Z:Author>Lots o'Doe</Z:Author>
               </Z:Authors>
          </D:prop>

          2.8.3     PROPPATCH

          The command succeeded. As there can be a mixture of
            PUT and DELETEs PROPPATCH method processes instructions specified in a body, a 201 Create seems inappropriate.

            400 Bad Request – The client has provide a value whose
            syntax is illegal for the property.

            401 Unauthorized – The client does not have authorization
          request body to

            alter one of create and/or remove properties defined on the properties. This error also occurs if a
            property is inherently read only.

            403 Forbidden – The client, for reasons
          resource identified by Request-URI.

          All DAV compliant servers MUST process instructions which are
          specified using the server chooses
            not to specify, can not alter one PropertyUpdate, Create, and Remove XML
          elements of the properties.

            405 Conflict – DAV schema.  The client has provided a value whose
            semantics are not appropriate for the property.

            413 Request Entity Too Long – If a particular property is
            too long to be recorded then a composite request message body MUST

          contain at least one PropertyUpdate XML error will be
            returned indicating the offending property.

            2.6.3.6   Example

            PROPPATCH bar;DAV/ HTTP/1.1
            Host: www.foo.com
            Content-Type: application/XML
            Content-Length: xxxx

            <XML>
                 <Namespace><Ref>http://www.ietf.org/standards/dav/</><A
            S>D</></>
                 <Namespace><Ref>http://www.w3.com/standards/z39.50/</><
            AS>Z</></>
                 <D:PropertyUpdate>
                      <Create><prop>
                           <propname>Z:authors</>
                           <propvalue>
                                <XML:XML>
                                <Namespace>

                 <Ref>http://www.ietf.org/standards/dav/proppatch/</>
                                <AS>D</>
                                </>
                                <Namespace>

                 <Ref>http://www.w3.com/standards/z39.50/</>
                                     <AS>Z</>
                                </>
                                <Z:Author>Jim Whitehead</>
                                <Z:Author>Roy Fielding</>
                           </>
                      </>
                      <Remove><propname>Z:Copyright-Onwer</></>
            </>  </>

            2.6.4     PUT

            A PUT is specified element.  Instruction
          processing MUST occur in the order instructions are received
          (i.e., from top to control what is returned by a
            GET. However bottom), and MUST be performed atomically.

          2.8.3.1   PropertyUpdate XML element

          Name:          http://www.ietf.org/standards/dav/PropertyUpdate
          Purpose:  To contain a GET request to alter the properties on a property always returns some sort of
            property containment format. As such PUT can not be used if
            the Request-URI refers to
          resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   *(Create | Remove)
          Description:This XML element is a property.

            2.6.5     SEARCH

            2.6.5.1   Request-URI

            The request-URI of container for the search method is information
          required to modify the URI of properties on the resource. .

            The Depth header MUST NOT be used on a SEARCH method which
            contains a Limited-Search This XML
          element (“limited search”).

            2.6.5.2   Command Format

            The message body stipulates the action of a SEARCH method.
            This section defines an application/xml content type using
            the http://www.ietf.org/standards/dav/ schema. This method is not normally cacheable.

            2.6.5.2.1 Limited-Search multi-valued.

          2.8.3.2   Create XML element

          Name: http://www.ietf.org/standards/dav/limited-search          http://www.ietf.org/standards/dav/create
          Purpose:  To specify create the set of matching DAV properties specified inside the
          Create XML element.
          Schema:   http://www.ietf.org/standards/dav/
          Parent: <XML>

            Values: The value is a single OR   http://www.ietf.org/standards/dav/PropertyUpdate
          Values=   Prop
          Description:This XML element. The OR element
            may only contain AND XML elements, and MUST contain at least
            one AND element.

            Description: This property indicates a very limited search.
            The search may only be on HTTP properties.

            2.6.5.2.2 OR XML element

            Name: http://www.ietf.org/standards/dav/or

            Purpose: To take its members, evaluate them, get a true or
            false result, “or” the results together, and have that be
            the total result.

            Schema: http://www.ietf.org/standards/dav/

            Parent: Limited-Search XML element

            Values: AND Prop XML
          element.

            2.6.5.2.3 AND XML element

            Name: http://www.ietf.org/sandards/dav/and

            Purpose: To take its members, evaluate them, get a true or
            false result, “and” The elements contained by Prop specify the results together, name and have
          value of properties that be
            the total result.

            Schema: http://www.ietf.org/standards/dav

            Parent: OR are created on Request-URI. If a
          property already exists then its value is replaced. The Prop XML
          element

            Values: Zero or one Name XML element, and zero or one Value
            XML element. There MUST be at least one Name or Value NOT contain a PropLoc XML
            element.

            2.6.5.2.4 Name attribute.

          2.8.3.3   Remove XML element

          Name: http://www.ietf.org/standards/dav/name          http://www.ietf.org/standards/dav/remove
          Purpose:  To provide a pattern against which property names
            are to be compared. If remove the name matches then DAV properties specified inside the property
            evaluates to true, otherwise false.
          Remove XML element.
          Schema:   http://www.ietf.org/standards/dav/
          Parent: AND XML element

            Values: Match-Stream

            2.6.5.2.5 Value XML element

            Name: http://www.ietf.org/standards/dav/value

            Purpose: To provide a pattern against which property values
            are to be compared. If   http://www.ietf.org/standards/dav/PropertyUpdate
          Values=   Prop
          Description:Remove specifies that the value matches then properties specified in
          Prop should be removed. Specifying the removal of a property
            evaluates to true, otherwise false.

            Schema: http://www.ietf.org/standards/dav/

            Parent: AND XML element

            Values: Match-Stream

            2.6.5.2.6 Match-String XML element

            Name: http://www.ietf.org/standards/dav/match-string

            Purpose: To specify a search pattern to be matched against
            an octet stream

            Schema: http://www.ietf.org/standards/dav/

            Parent: Name or Value XML element

            Values: (“*” | “?” | EncodedOctet)
            EncodedOctet = <An EncodedOctet uses XML encoding to encode
            “*” and “?” as well as “<” and “>”

            Description: This element provides a template against which
            anything that can
          does not exist is not an error. All the elements in Prop MUST be expressed
          empty, as an octet stream may only the names of properties to be
            compared. “*” is a wildcard that matches zero or more
            unspecified contiguous octets. “?” is a wildcard that
            matches exactly one unspecified octet.

            2.6.5.3 removed are
          required.

          2.8.3.4   Response Format

          The response is an application/xml message MUST have a response body which that contains a single SearchResult XML element whose contents
            are a series of XML elements representing matching
            properties.

            2.6.5.3.1 SearchResult XML element

            Name: http://www.ietf.org/standards/dav/searchresult

            Purpose: To contain
          multiresponse identifying the results of for each property.

          2.8.3.5   Response Codes

          200 OK - The command succeeded. As there can be a SEARCH request

            Schema: http://www.ietf.org/standards/dav/

            Parent: Any, usually <XML>

            Values: Zero or more Prop XML elements (defined mixture of
          Create and Removes in
            Properties draft)

            Description: a body, a 201 Create seems inappropriate.
          403 Forbidden - The SearchResult XML element provides client, for reasons the
            context server chooses not to inform
          specify, can not alter one of the properties.
          405 Conflict - The client that its contents has provided a value whose semantics
          are not just
            some XML element, but an appropriate for the property. This includes trying to set
          read only properties.
          413 Request Entity Too Long - If a particular property is too
          long to be recorded then a composite XML representation of error will be returned

          indicating the requested offending property.

            2.6.5.4   Example

                 SEARCH  /container/ HTTP/1.1
                 Host: www.foo.bar
                 Content-Length: xxxx
                 Content-Type: application/xml

                 <XML>
                      <XML:Namespace>
                           <Ref>http://www.ietf.org/standards/dav/</>
                           <AS>S</>
                      </>
                      <S:limited-search>

                           <OR>
                                <AND>
                                     <Name>*</>
                                </>
                           </>
                      </>
                 </>

                 HTTP/1.1 200 OK
                 Content-Type: application/xml
                 Content-Length: xxxxx

                 <XML>
                      <XML:Namespace>
                           <Ref>http://www.ietf.org/standards/dav/</>
                           <As>S</>
                      </>
                      <XML:Namespace>
                           <Ref>http://www.foo.bar/boxschema</>
                           <AS>R</>
                      </>
                      <S:SearchResult>
                           <Prop>
                                <PropName>R:bigbox</>
                                <PropValue>
                                     <XML:XML>
                                          <BoxType>Box type A</>
                                     </>
                                </>
                           </>
                           <Prop>
                                <PropName>R:author</>
                                <PropValue>
                                     <XML:XML>
                                          <Name>J.J.
                 Dingleheimerschmidt</>
                                     </>
                                </>
                           </>
                      </>
                 </>

            The result will return all properties on the container and
            its members. In this case only two properties were found,
            one on the container and one on one of its members, both
            properties are live.

            3  A Proposal for Collections of Web Resources and Name
          417 Insufficient Space Operations

            3.1 Observations on the HTTP Object Model
            As a prerequisite for specification of collections and name Resource - The resource does not have
          sufficient space operations for to record the Web, a model for collection
            resources and for namespace topology must be given.  This
            section describes a new type state of Web resource, the collection
            resource, and provides a model for discussing the
            relationship between the resources that are generated as resource after the
            result
          execution of a data-producing process, and this method.
          418 Atomicity Failure - The command was not executed because of
          an atomicity failure elsewhere the source resources
            that describe caused the process.

            3.1.1     Collection Resources entire command to
          be aborted.

          2.8.3.6   Example

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

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" AS = "D"/>
          <?XML:Namespace
               href = "http://www.w3.com/standards/z39.50/" AS = "Z"/>
          <D:PropertyUpdate>
               <Create>
                    <prop>
                         <Z:authors>
                              <Z:Author>Jim Whitehead</Z:Author>
                              <Z:Author>Roy Fielding</Z:Author>
                         </Z:authors>
                    </Prop>
               </Create>
               <Remove>
                    <prop><Z:Copyright-Owner/></prop>
               </Remove>
          </D:PropertyUpdate>

          HTTP/1.1 405 Conflict
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace
               href="http://www.ietf.org/standards/dav/" AS = "D"/>
          <?XML:Namespace
               href="http://www.w3.com/standards/z39.50/" AS = "Z"/>
          <D:MultiResponse>
               <ResponseDescription> Copyright Owner can not be deleted or
          altered.</ResponseDescription>
               <Response>
                    <Prop><Z:authors/></Prop>
                    <Status>HTTP/1.1 418 Atomicity Failure</Status>
               </Response>
               <Response>
                    <Prop><Z:Copyright-Owner/></Prop>
                    <Status>HTTP/1.1 405 Conflict</Status>
               </Response>
          </D:MultiResponse>

          2.8.4     PUT

          A collection PUT is a Web resource type whose primary state specified in order to control what is returned by a
            set of URIs and associated values that are recorded as
            properties GET.
          However a GET on a property always returns a predefined property
          containment format. Therefore PUT can not be used if the resource. Request-
          URI refers to a property.

          2.8.5     PROPFIND

          The URIs identify resources PROPFIND method retrieves properties defined on Request-URI.
          The request message body is an XML document that are members of MUST contain
          only one PropFind XML element, which specifies the collection. type of
          property find action to be performed.  The values associated
            with each URI include information such as XML element contained
          by PropFind specifies the Last Modified
            Date, Entity Tag, Creation Date, Content Type, Display Name, type of action to be performed:
          retrieve all property names and whether the member is values (AllProp), retrieve only
          specified property names and values (Prop), or retrieve only a collection.

            A member
          list of all property names (Propname).  When a collection Prop XML element
          is either an internal member
            resource, which MUST have present, it specifies a URI that is relative to the base
            URI list of the collection, or an external member resource, which
            has a URI which is not relative to the base URI names of the
            collection. External member resources properties whose
          name and value are further subdivided
            into propagate members, which have recursive method
            invocations propagated to them, and no-propagate members,
            which do not.

            A collection resource may be viewed and returned.  The Prop element, when used as
          within a compound
            resource in which the collection FINDPROP request body MUST be empty.

          The response is a container for a group
            of related resources that, together, form a larger logical
            unit.  For example, text/xml message body that contains a collection of HTML resources where
            each resource is
          MultiResponse XML element which describes the chapter results of the
          attempts to retrieve the various properties. If a book can property was
          successfully retrieved then its value MUST be viewed as a
            compound resource representing returned in the entire book.

            Some methods, when invoked on a collection, affect
          prop XML element. In the
            entire collection.  For example, it is possible to copy an
            entire collection case of Allprop and its contents with just a single copy
            method request. The model for performing these operations is Findprop, if a tree traversal.  The method is invoked on the collection,
            which then performs the method on itself before propagating
          principal does not have the method right to all its internal members and propagate
            external members.  If these are non-collection resources,
            the request method is processed.  However, know if the request is
            propagated to another collection, then the propagation
            begins again.  This sequence a particular
          property exists, an error MUST NOT be returned. The results of actions causes the
          this method to SHOULD NOT be propagated as a tree traversal of cached.

          2.8.5.1   Propfind XML element

          Name:          http://www.ietf.org/standards/dav/Propfind
          Purpose:  To specify the members set of the
            collections.  It matching properties
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   (Prop | Allprop | Propname)
          Description: Propfind is incumbent upon the client to perform any
            locking operation on a container element for the collection or subordinate members exact
          specification of a PROPFIND request.

          2.8.5.2   Allprop

          Name:          http://www.ietf.org/standards/dav/Allprop
          Purpose:  To specify that it deems necessary in order all properties are to maintain state
            consistency during be returned
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Propfind
          Description: Its presence in a PROPFIND request specifies the execution of  such methods.

            3.1.2     Creation
          name and Retrieval value of Collection Resources

            Since all properties defined on the existing HTTP methods for creating (PUT, POST) and
            retrieving (GET) a resource were defined for non-collection
            resources, it is not surprising MUST be
          returned.

          2.8.5.3   Propname

          Name:          http://www.ietf.org/standards/dav/Propname
          Purpose:  To specify that the semantics names of these
            methods do not transfer well to collections. For example,
            the PUT method is all properties defined to store on
          the request entity under
            the Request-URI.  While a description format for a
            collection can readily be constructed that could be used
            with PUT, the implications of sending such a description to
            the server resource are undesirable.  For example, if a description
            of a collection that omitted some existing resources were
            PUT to a server, this might be interpreted as returned.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Propfind
          Description: Its presence in a command to
            remove those members.  This would extend PUT to perform
            DELETE functionality, which is undesirable since it changes PROPFIND request specifies the semantics
          name of PUT, and makes it difficult to control
            DELETE functionality with an access control scheme based all properties defined on
            methods.

            While the POST method is sufficiently open-ended that a
            “create a collection” POST command could be constructed,
            this is undesirable because it would resource MUST be difficult to provide
            separate access control for collection creation and other
            uses of POST if they both use returned.

          2.8.5.4   PropFindResult XML element

          Name: http://www.ietf.org/standards/dav/PropFindResult
          Purpose: To contain the same method. results of a SEARCH request
          Schema: http://www.ietf.org/standards/dav/
          Parent: Any
          Values: Prop

          2.8.5.5   Example 1 - Prop

          PROPFIND  /container/ HTTP/1.1
          Host: www.foo.bar
          Content-Length: xxxx
          Content-Type: text/xml

          <?XML:Namespace href =
               "http://www.ietf.org/standards/dav/" AS = "G"/>
          <?XML:Namespace href =
               "http://www.foo.bar/boxschema/" AS = "B"/>
          <G:PROPFIND>
               <prop>
                    <B:bigbox>
                    <B:author>
                    <B:DingALing>
                    <B:Random>
               </prop>
          </G:PROPFIND>

          HTTP/1.1 207 Partial Success
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace
               href ="http://www.ietf.org/standards/dav/" AS = "S">
          <?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
          <D:MultiResponse>
               <ResponseDescription> There has been an access violation
          error. </ResponseDescription>
               <Response>
                    <Prop>
                         <R:bigbox D:Proploc="http://prop.com/BoxType">
                              <BoxType>Box type A</BoxType>
                         </R:bigbox>
                         <R:author D:Proploc="http://prop.com/Author">
                              <Name>J.J. Dingleheimerschmidt</Name>
                         </R:author>
                    </Prop>
                    <Status>HTTP/1.1 200 Success</Status>
          </Response>
               <Response>
                    <Prop><R:DingALing/><R:Random/></>
                    <Status>HTTP/1.1 403 Forbidden</Status>
                    <ResponseDescription> The GET method when applied to collections is also
            problematic.  While it might seem desirable to user does not have GET access to
          the DingALink property. </ResponseDescription>
               </Response>
          </D:MultiResponse>

          The result will return a listing of all properties on the members of a collection, container. In this is
            foiled by the existence of the “index.html” de-facto
            standard namespace redirection, in which a GET request on a
            collection is automatically redirected
          case only two properties were found. The principal did not have
          sufficient access rights to see the index.html
            resource.

            Because of the difficulty of reusing some existing third and fourth properties
          so an error was returned.

          2.8.5.6   Example 2 - Allprop

          PROPFIND  /container/ HTTP/1.1
            methods for collections, two new resource creation/retrieval
            methods are needed.
          Host: www.foo.bar
          Content-Length: xxxx
          Content-Type: text/xml

          <?XML:Namespace href =
               "http://www.ietf.org/standards/dav/" AS = "G"/>

          <G:PROPFIND>
               <Allprop/>
          </G:PROPFIND>

          HTTP/1.1 200 Success
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace href =
               "http://www.ietf.org/standards/dav/" As = "S">
          <?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
          <S:MultiResponse>
               <Prop>
                    <R:bigbox D:Proploc="http://prop.com/BigBox">
                         <BoxType>Box type A</BoxType>
                    </R:bigbox>
                    <R:author D:Proploc="http://prop.com/Author">
                         <Name>Hadrian</Name>
                    </R:author>
               </Prop>
               <Status>HTTP/1.1 200 Success</Status>
          </S:MultiResponse>

          This specification introduces the MKCOL
            method for creating collection resources, and the INDEX
            method for retrieving the contents of a collection.

            The exact definition of particular client only had the behavior of GET right to see two properties,
          BoxType and PUT on
            collections Author. No error is defined later in this draft.

            3.1.3     Source Resources and Output Resources

            For many resources, the entity returned by GET exactly
            matches the persistent state of the resource, for example, a
            GIF file stored on a disk.  For this simple case, the URL at
            which a resource is accessed is identical to the URL at
            which remaining
          properties, as the source (the persistent state) of client does not even have sufficient rights to
          know they exist. If the resource is
            accessed. This is also client did have the case for HTML source files that
            are right to know they
          existed but did not processed by have the server prior right to transmission.

            However, HTML files can sometimes be processed by the server
            before being transmitted as see their value, a return entity body.  Server-
            side-include directives within an HTML file instruct 201
          Partial Success with a
            server to replace the directive with another value, such multiresponse, as used in the current date. previous
          example, would have been returned.

          2.8.5.7   Example 3 - Propname

          PROPFIND  /container/ HTTP/1.1
          Host: www.foo.bar
          Content-Length: xxxx
          Content-Type: text/xml

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" AS = "G"/>
          <G:PROPFIND>
               <Propname/>
          </G:PROPFIND>

          HTTP/1.1 200 Success
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" As = "S">
          <?XML:Namespace
               href = "http://www.foo.bar/boxschema" AS = "R">
          <S:MultiResponse>
               <Prop>
                    <R:bigbox D:Proploc="http://prop.com/BigBox"/>
                    <R:author D:Proploc="http://prop.com/Author"/>
                    <R:DingALing/>
                    <R:Random/>
               </Prop>
               <Status>HTTP/1.1 200 Success</Status>
          </S:MultiResponse>

          In this case, what is returned by GET
            (HTML plus date) differs from the persistent state case only two of the
            resource (HTML plus directive). Typically there is no way to
            access the HTML file containing the unprocessed directive.

            Sometimes the entity returned by GET is the output of a
            data-producing process that is described by one or more
            source resources (that may not even properties have a location in direct URLs
          available, while the
            URL namespace). other two properties can only be referenced

          via PROPFIND and PROPPATCH.

          3    A single data-producing process may
            dynamically generate the state Proposal for Collections of Web Resources and Name Space
             Operations

          3.1  Observations on the HTTP Object Model

          As a potentially large number
            of output resources. An example prerequisite for specification of this is collections and name space
          operations for the Web, a CGI script that model for collection resources and for
          namespace topology must be given.  This section describes a "finger" gateway process that maps part new
          type of Web resource, the
            namespace of collection resource, and provides a server into finger requests, such as
            http://www.foo.bar.org/finger_gateway/user@host.

            In
          model for discussing the absence of distributed authoring capability, relationship between the fact resources that the source resource(s) for server
          are generated output do
            not have a mapping to as the URI namespace is not result of a problem, data-producing process, and has desirable security benefits. However, if remote
            editing of the
          source resource(s) resources that describe the process.

          3.1.1     Collection Resources

          A collection is desired, they should be
            given a location in Web resource type whose primary state is a set
          of URIs and associated values that are recorded as properties on
          the URI namespace. This source location
            should not be one resource.  The URIs identify resources that are members of
          the locations at which collection.  The values associated with each URI include
          information such as the generated
            output is retrievable, since in general it is impossible for Last Modified Date, Entity Tag, Creation
          Date, Content Type, Display Name, and whether the server to differentiate requests for source resources
            from requests for process output resources. There member is often a
            many-to-many relationship between source resources and
            output resources.

            For DAV compliant servers all output resources
          collection.

          A member of a collection is either an internal member resource,
          which MUST have a
            single source resource (and URI that source resource is relative to the base URI of the
          collection, or an external member resource, which has a URI), URI which
          is not relative to the base URI of the source collection. External
          member resources are further subdivided into propagate members,
          which have recursive method invocations propagated to them, and
          no-propagate members, which do not.

          A collection resource SHOULD may be stored in viewed and used as a single
            link on the output compound
          resource with type DAV:/ Source. Note
            that by storing the source URI in links on the output
            resources, the burden of discovering which the source collection is placed on
            the authoring client. 

            In the general case, a large number container for a group of source
          related resources can
            comprise that, together, form a data-producing process that generates many output
            resources, creating larger logical unit.
          For example, a many-to-many relationship between
            output collection of HTML resources and source resources. If where each output
            resource had links back to every source resource in
          is the
            data-producing process, there chapter of a book can be viewed as a potentially large
            number of such links. Due to the potentially large number of
            links, and compound resource
          representing the lack of entire book.

          Some methods, when invoked on a policy for ordering access to
            multiple sources, explicit storage of source relationships collection, affect the entire
          collection.  For example, it is limited possible to cases copy an entire
          collection and its contents with only just a single source resource.

            3.2 MKCOL Method

            3.2.1     Problem Description copy method
          request. The client needs a way to create model for performing these operations is a collection.

            3.2.2     Solution Requirements tree
          traversal.  The solution:

            Must ensure that a collection has been made (i.e. that it
               responds to method is invoked on the INDEX method) as opposed collection, which then
          performs the method on itself before propagating the method to a non-
               collection resource.
          all its internal members and propagate external members.  If a collection could not be made, it
               must indicate a failure to the principal.

            Requires that
          these are non-collection resources, the server MAY, request method is
          processed.  However, if necessary, create any
               intermediate collections so that the underlying storage
               medium request is self-consistent.

            3.2.3     Request

            The MKCOL propagated to another
          collection, then the propagation begins again.  This sequence of
          actions causes the method creates to be propagated as a new collection resource at tree traversal of
          the
            location specified by members of the Request-URI. If collections.  It is incumbent upon the Request-URI
            exists then MKCOL must fail.

            During MKCOL processing, a server MAY add the Request-URI client
          to
            one or more collections within the server’s controlled
            namespace.

            3.2.3.1   MKCOL Without Request Body

            When MKCOL is invoked without a request body then perform any locking operation on the collection created has no members.

            3.2.3.2   MKCOL With Request Body

            A MKCOL request message MAY contain a message body.  The
            behavior of a MKCOL request when the body is present is
            limited to creating collections, or subordinate
          members that it deems necessary in order to maintain state
          consistency during the execution of a collection,
            bodies of members  such methods.

          3.1.2     Creation and properties on the collections or
            members. If Retrieval of Collection Resources

          Since the server receives existing HTTP methods for creating (PUT, POST) and
          retrieving (GET) a MKCOL request entity type resource were defined for non-collection
          resources, it does is not support or understand it MUST respond with a 415
            (Unsupported Media Type) status code.

            3.2.3.3   Creating Multiple Collections

            The server MAY create intermediate collections if they surprising that the semantics of these
          methods do not already exist. transfer well to collections. For example, if the PUT

          method is defined to store the request entity under the Request-
          URI.  While a description format for a collection
            http://server/a/ already exists in can readily be
          constructed that could be used with PUT, the server’s namespace,
            then while performing implications of
          sending such a MKCOL description to create http://server/a/b/c/ the server may also create are undesirable.  For
          example, if a description of a collection at
            http://server/a/b/.

            3.2.4     Response

            Responses from that omitted some
          existing resources were PUT to a MKCOL request are not cacheable, since
            MKCOL has non-idempotent semantics.

            201 (Created) - The structured resource was created in its
            entirety.

            403 (Forbidden) - The server does not allow the creation of
            collections at the given location in its namespace.

            415 (Unsupported Media Type)– The server does not support
            the request type of the body.

            416 (Unprocessable Entity) - A new status code.  The server
            understands server, this might be
          interpreted as a command to remove those members.  This would
          extend PUT to perform DELETE functionality, which is undesirable
          since it changes the content type semantics of the request entity, but was
            unable PUT, and makes it difficult to process the contained instructions.

            3.2.5     Example

            This example creates a container collection called
            /webdisc/xfiles/
          control DELETE functionality with an access control scheme based
          on methods.

          While the server www.server.org.

                 MKCOL /webdisc/xfiles/ HTTP/1.1
                 Host: www.server.org

                 HTTP/1.1 201 Created

            3.3 INDEX Method

            3.3.1     Problem Description

            A mechanism POST method is needed to discover if sufficiently open-ended that a resource is "create a
          collection" POST command could be constructed, this is
          undesirable because it would be difficult to provide separate
          access control for collection creation and other uses of POST if so, list its members.

            3.3.2     Solution Requirements
          they both use the same method.

          The solution:

            must allow a client GET method when applied to discover collections is also problematic.
          While it might seem desirable to have GET return a listing of the
          members of a collection

            must always provide a machine-readable description of collection, this is foiled by the
               membership existence of the
          "index.html" de-facto standard namespace redirection, in which a collection

            3.3.3     The Request

            The INDEX method returns
          GET request on a machine-readable representation collection is automatically redirected to the
          index.html resource.

          Because of the membership difficulty of the reusing some existing HTTP/1.1
          methods for collections, two new resource at creation/retrieval
          methods are needed.  This specification introduces the MKCOL
          method for creating collection resources, and the Request-URI.  For a
            collection, INDEX MUST return method
          for retrieving the contents of a machine-readable list collection.

          The exact definition of its
            members. the behavior of GET and PUT on
          collections is defined later in this draft.

          3.1.3     Source Resources and Output Resources

          For other many resources, the information entity returned by
            INDEX is undefined, and MAY vary.  The request message body
            of an INDEX request SHOULD be ignored.

            The Depth header can be used to indicate how much GET exactly matches
          the persistent state of a
            result can be generated for the response. The specific
            values allowed resource, for example, a GIF file
          stored on a disk.  For this simple case, the depth header when used with the INDEX
            method are 1 and infinity. The 1 value indicates that the
            internal and external member resources should be reported in URL at which a
          resource is accessed is identical to the result, infinity indicates that all internal and
            external member resources and all their descendants should
            be in URL at which the result. If source
          (the persistent state) of the Depth header resource is not given, then 1 accessed. This is assumed. Servers MUST honor a depth of 1. Servers MAY
            honor infinity.  If also
          the server does case for HTML source files that are not support processed by the value of
          server prior to transmission.

          However, HTML files can sometimes be processed by the depth header then server
          before being transmitted as a 412 (Precondition failed) MUST be
            returned.

            3.3.4     The Response

            200 (OK) – The server MUST send an application/xml response return entity which describes body.  Server-side-
          include directives within an HTML file instruct a server to
          replace the collection.

            404 (Not Found) - Same behavior directive with another value, such as HTTP 1.1. The server
            never had the resource, or current
          date.  In this case, what is returned by GET (HTML plus date)
          differs from the server permanently deleted persistent state of the resource and has (HTML plus
          directive). Typically there is no knowledge that it ever existed. This
            error code implies that, essentially, way to access the server has no
            information about HTML file
          containing the unprocessed directive.

          Sometimes the Request URI.

            3.3.5     Response Message Body

            The default INDEX response for a resource is an
            application/xml HTTP entity (i.e., an Extensible Markup
            Language (XML) document) returned by GET is the output of a data-
          producing process that contains is described by one or more source
          resources (that may not even have a location in the URL
          namespace).  A single XML element
            called collectionresource which describes data-producing process may dynamically
          generate the collection,
            and state of a set potentially large number of XML elements called memberesource which
            describe the members output
          resources. An example of the collection.

            The response from INDEX this is cacheable, and SHOULD be
            accompanied by an ETag header (see section 13.3.4 a CGI script that describes a
          "finger" gateway process that maps part of RFC
            2068). If GET and INDEX return different entities for the
            same resource state, they MUST return different entity tags.

            The server MUST transmit the following XML elements for each
            member resource namespace of a collection: Ref, IsCollection, Content-
            Type, External. The
          server MUST transmit into finger requests, such as
          http://www.foo.bar.org/finger_gateway/user@host.

          In the following XML
            elements if it can generate any meaningful values absence of distributed authoring capability, the fact that

          the source resource(s) for them:
            Creation-Date, Last-Modified, DisplayName, Content-Language.
              The server SHOULD transmit Etag XML elements for each
            member (see section 13.3.4 of RFC 2068).

            The value of content-type, last-modified, and etag XML
            elements MUST be identical generated output do not have a
          mapping to the value URI namespace is not a problem, and has desirable
          security benefits. However, if remote editing of the response
            header field source
          resource(s) is desired, they should be given a location in the
          URI namespace. This source location should not be one of the same name
          locations at which the generated output is retrievable, since in
          general it is impossible for the HTTP/1.1 specification.
             Since server to differentiate requests
          for source resources from requests for process output resources.
          There is often a many-to-many relationship between source
          resources and output resources.  For DAV compliant servers all
          output resources which have a single source resource (and that
          source resource has a URI), the HTTP/1.1 header fields are described in terms URI of the on-the-wire entity, the values presented by INDEX are
            those that would source resource SHOULD
          be generated if stored in a single link on the output resource was accessed
            using with type
          http://www.ietf.org/standards/dav/link/Source. Note that by
          storing the GET method without content negotiation.

            3.3.5.1   CollectionResource

            Name: http://www.ietf.org/standards/dav/collectionresource

            Purpose:  Describes a collection

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   <XML>

            Value:MemberResource

            3.3.5.2   MemberResource

            Name: http://www.ietf.org/standards/dav/memberresource

            Purpose:  Describes a member source URI in links on the output resources, the
          burden of a collection

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   CollectionResource

            Value:Ref, IsCollection, Content-Type, External, Creation-
            Date, Last-Modified, ETag, DisplayName (other XML elements
            MAY also be present)

            3.3.5.3   Ref

            See XML definition.

            3.3.5.4   IsCollection

            Name: http://www.ietf.org/standards/dav/iscollection

            Purpose:  This is a boolean value which is set to “true” if discovering the entry source is a collection

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:(“true” | “false”)

            3.3.5.5   Content-Type

            Name: http://www.ietf.org/standards/dav/content-type

            Purpose:  The content-type of placed on the member resource.

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:media-type   ; defined in Section 3.7 authoring
          client.

          In the general case, a large number of [HTTP11] source resources can
          comprise a data-producing process that generates many output
          resources, creating a many-to-many relationship between output
          resources and source resources. If no meaningful content-type each output resource had links
          back to every source resource in the data-producing process,
          there can be generated, then an
            empty value MUST be given.

            3.3.5.6   External

            Name: http://www.ietf.org/standards/dav/external

            Purpose:  If present, this element indicates a potentially large number of such links. Due to the resource is
            an external member
          potentially large number of links, and the lack of a policy for
          ordering access to multiple sources, explicit storage of source
          relationships is limited to cases with only a single source
          resource.

          3.2  MKCOL Method

          3.2.1     Problem Description

          The client needs a way to create a collection.  If

          3.2.2     Solution Requirements

          The solution:
          -    Must ensure that a collection has been made (i.e. that it
            responds to the value is
            “propagate,” INDEX method) as opposed to a non-collection
            resource. If a collection could not be made, it is must indicate a propagate member,
            failure to the principal.
          -    The server MAY, if necessary, create any intermediate
            collections so that the value is “no-
            propagate,” it underlying storage medium is a no-propagate member.

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:(“propagate” | “no-propagate”)

            3.3.5.7   Creation-Date

            Name: http://www.ietf.org/standards/dav/creation-date

            Purpose: self-
            consistent.
          -

          3.2.3     Request

          The date the MKCOL method creates a new collection resource was created.

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:The date MUST be given in RFC 1123 format (rfc-1123
            production, defined in section 3.3.1 of [HTTP11]

            3.3.5.8   Last-Modified

            Name: http://www.ietf.org/standards/dav/last-modified

            Purpose:  The date at the resource was last modified.

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:The date MUST be given in RFC 1123 format (rfc-1123
            production, defined in section 3.3.1 of [HTTP11]

            3.3.5.9   ETag

            Name: http://www.ietf.org/standards/dav/etag

            Purpose:  The entity tag of
          location specified by the resource.

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:entity-tag    ; defined in Section 3.11 of [HTTP11]

            3.3.5.10  DisplayName

            Name: http://www.ietf.org/standards/dav/displayname

            Purpose:  A name for Request-URI. If the resource that is suitable for
            presentation Request-URI exists
          then MKCOL must fail.

          During MKCOL processing, a server MAY add the Request-URI to one
          or more collections within the server’s controlled namespace.

          3.2.3.1   MKCOL Without Request Body

          When MKCOL is invoked without a person

            Schema:   http://www.ietf.org/standards/dav/

            Parent:   MemberResource

            Value:Any valid XML character data (from XML specification)

            3.3.5.11  Content-Language

            Name:     http://www.ietf.org/standards/dav/content-language

            Purpose:  Describes request body then the natural language(s) collection
          created has no members.

          3.2.3.2   MKCOL With Request Body

          A MKCOL request message MAY contain a message body.  The behavior
          of a MKCOL request when the intended
            audience for the resource.

            Schema:   http://www.ietf.org.standards/dav/

            Parent:   MemberResource

            Value:    1#language-tag ;language-tag body is defined in section
            14.13 present is limited to
          creating collections, members of RFC 2068

            3.3.6     Example

                 INDEX /user/yarong/dav_drafts/ HTTP/1.1
                 Host: www.microsoft.com
                 Depth: 1

                 HTTP/1.1 200 OK
                 Content-Type: application/xml
                 Content-Length: xxx
                 Last-Modified: xxx
                 ETag: “fooyyybar”

                 <XML>
                 <XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
                 /><As>D</></>
                 <D:CollectionResource>
                      <MemberResource>
                           <XML:Ref>namespace.doc</>
                           <IsCollection>false</>
                           <Content-Type>application/msword</>
                           <External>false</>
                           <Creation-Date>Thu, 20 Mar 1997 23:05:25
                 GMT</>
                           <Last-Modified>Fri, 22 Aug 1997 18:22:56
                 GMT</>
                           <Etag>8675309</>
                           <DisplayName>WebDAV Name Space Operations
                 Draft</>
                           <Content-Language>en</>
                 </>  </>
                 </>

            This example shows the result of the INDEX method applied to

            the collection resource
            http://www.microsoft.com/er/yarong/dav_drafts/.  It returns a response body in XML format, which gives information about
            the container’s sole member,
            http://www.microsoft.com/users/yarong/dav_drafts/namespace.d
            oc.

            3.4 Behavior collection, bodies of RFC 2068 Methods members
          and properties on Collections
            With the introduction of collections or members. If the collection resource server
          receives a MKCOL request entity type to the
            HTTP object model, it is necessary to define the behavior of
            the existing methods (defined in RFC 2068) when invoked on does not support or
          understand it MUST respond with a
            collection resource to avoid ambiguity.  While some methods,
            such as OPTIONS and TRACE behave identically when applied to
            collections, GET, HEAD, POST, PUT, and DELETE require some
            additional explanation.

            3.4.1     GET, HEAD for 415 (Unsupported Media Type)
          status code.

          3.2.3.3   Creating Multiple Collections

          The semantics of GET are unchanged when applied to a
            collection, since GET is defined as, “retrieve whatever
            information (in server MAY create intermediate collections if they do not
          already exist. For example, if the form of an entity) is identified by collection http://server/a/
          already exists in the
            Request-URI” [HTTP11]. GET when applied server’s namespace, then while performing a
          MKCOL to create http://server/a/b/c/ the server may also create a
          collection MAY
            return the contents of an “index.html” resource, at http://server/a/b/.

          3.2.4     Response

          Responses from a human-
            readable view of MKCOL request are not cacheable, since MKCOL has
          non-idempotent semantics.
          201 (Created) - The structured resource was created in its
          entirety.
          403 (Forbidden) - The server does not allow the contents creation of
          collections at the collection, or
            something else altogether, and hence it is possible the
            result of a GET on a collection will bear no correlation to given location in its namespace.
          415 (Unsupported Media Type)- The server does not support the state
          request type of the collection.

            Similarly, since body.
          416 (Unprocessable Entity) - A new status code.  The server
          understands the definition content type of HEAD is a GET without a
            response message body, the semantics of HEAD do not require
            any modification when applied request entity, but was
          unable to collection resources.

            3.4.2     POST for Collections

            Since by definition the actual function performed by POST is
            determined by process the server and often depends contained instructions.

          3.2.5     Example

          This example creates a container collection called
          /webdisc/xfiles/ on the particular
            resource, the behavior of POST when applied to collections
            cannot be modified because it server www.server.org.
               MKCOL /webdisc/xfiles/ HTTP/1.1
               Host: www.server.org

               HTTP/1.1 201 Created

          3.3  INDEX Method

          3.3.1     Problem Description

          A mechanism is largely undefined.  Thus
            the semantics of POST do not require any modification when
            applied needed to discover if a collection.

            3.4.3     PUT for Collections

            In HTTP/1.1, PUT stores the request entity under the
            Request-URI, resource is a collection
          and hence if so, list its semantics are limited members.

          3.3.2     Solution Requirements

          The solution:
          -    must allow a client to non- discover the members of a collection resources.  If
          -    must always provide a PUT is invoked on machine-readable description of the
            membership of a collection
          -

          3.3.3     The Request

          The INDEX method returns a machine-readable representation of the
          membership of the resource it MUST fail.

            When at the PUT operation creates Request-URI.  For a new non-collection
            resource, collection,
          INDEX MUST return a server MAY add that resource’s URI to one or
            more collections within machine-readable list of its members.  For
          other resources, the server’s controlled namespace.

            3.4.4     DELETE for Collections

            When DELETE information returned by INDEX is applied undefined,
          and MAY vary.  The request message body of an INDEX request
          SHOULD be ignored.

          The Depth header can be used to indicate how much of a collection resource, all
            internal members MUST result can
          be recursively deleted. generated for the response. The
            dav:link/propagate specific values allowed for
          the depth header when used with the INDEX method are 1 and
          infinity. The 1 value indicates that the internal and external members MUST
          member resources should be deleted reported in the result, infinity
          indicates that all internal and
            their links must be removed. dav:link/nopropagate external
            members MUST have only their link removed; the member resources
            MUST not and all
          their descendants should be deleted.

            The in the result. If the Depth header does is
          not apply to the DELETE method. It
            cannot be used to limit the extent of the operation. If it given, then 1 is present it assumed. Servers MUST be ignored.

            When applied to any resource, the DELETE method deletes all
            properties on the Request-URI.

            During DELETE processing, honor a server depth of 1.
          Servers MAY remove honor infinity.  If the URI of server does not support the
            deleted resource(s) from collections within its controlled
            namespace.

            3.4.4.1   New Response Codes for DELETE

            207 (Partial Success) Only some
          value of the member resources were
            deleted. The response entity will describe any errors.

            500 (Server Error) The resource was in such depth header then a state that it
            could not 412 (Precondition failed) MUST
          be deleted. returned.

          3.3.4     The response entity will describe
            reason for the error.

            3.5 COPY Method

            3.5.1     Problem Description

            Currently, in order to create a copy of a resource, the
            client must GET Response

          200 (OK) - The server MUST send an application/xml response
          entity and then PUT that entity to which describes the
            desired destination. This requires (1) an entity to be
            transmitted to and from collection.
          404 (Not Found) - Same behavior as HTTP 1.1. The server never had
          the resource, or the server and (2) that permanently deleted the resource
            be expressible as an entity with complete fidelity. and
          has no knowledge that it ever existed. This is problematic because of error code implies
          that, essentially, the network traffic involved
            in making a copy, and because there is often server has no way to fully
            express information about the
          Request URI.

          3.3.5     Response Message Body

          The default INDEX response for a resource as is an application/xml
          HTTP entity without a loss of fidelity.

            3.5.2     Solution Requirements

            The solution:

            MUST allow a principal to create a copy of (i.e., an Extensible Markup Language (XML) document)
          that contains a resource
               without having to transmit single XML element called collectionresource
          which describes the resource to collection, and from the
               server.

            3.5.3     The Request

            The COPY method creates a duplicate set of XML elements called
          memberesource which describe the source resource,
            given by the Request-URI, in the destination resource, given
            by members of the Destination header. collection.

          The Destination header MUST response from INDEX is cacheable, and SHOULD be
            present.  The exact behavior accompanied
          by an ETag header (see section 13.3.4 of RFC 2068). If GET and
          INDEX return different entities for the COPY method depends on
            the type of same resource state, they
          MUST return different entity tags.

          The server MUST transmit the source resource.

            3.5.3.1   COPY following XML elements for HTTP/1.1 resources

            When the source each
          member resource is not a collection, and is not of a
            property, collection: Ref, IsCollection, Content-Type,
          External. The server MUST transmit the body following XML elements if
          it can generate any meaningful values for them: Creation-Date,
          Last-Modified, DisplayName, Content-Language.   The server SHOULD
          transmit Etag XML elements for each member (see section 13.3.4 of the destination resource
          RFC 2068).

          The value of content-type, last-modified, and etag XML elements
          MUST be
            octet-for-octet identical to the body value of the source
            resource. Alterations to the destination resource do not
            modify the source resource. Alterations to the source
            resource do not modify the destination resource. Thus, all
            copies are performed “by-value”.

            If the Duplicate-Properties response header is “false,” then
            properties SHOULD NOT be copied to field of
          the destination resource.
            If same name in the Duplicate-Properties header is “false” and HTTP/1.1 specification.  Since the
            Enforce-Live-Properties HTTP/1.1
          header is also present, the request
            MUST fail with a 412 (Precondition Failed) status code.
            [Ed. Note: what if resource to be copied has no properties,
            and no properties fields are explicitly named described in terms of the header?]

            All properties on a source resource SHOULD be duplicated on

            the destination resource following the definition for
            copying properties.

            3.5.3.2   COPY for Properties

            Live properties SHOULD be duplicated as identically behaving
            live properties at on-the-wire entity,
          the destination resource. Since they values presented by INDEX are
            live properties, the server determines those that would be generated
          if the syntax and
            semantics (hence value) of these properties.  Properties
            named by the Enforce-Live-Properties header MUST be live on
            the destination resource, or resource was accessed using the GET method MUST fail.  If without content
          negotiation.

          3.3.5.1   CollectionResource

          Name:     http://www.ietf.org/standards/dav/collectionresource

          Purpose:  Describes a
            property is not named by Enforce-Live-Properties and cannot collection
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   <XML>
          Value:    MemberResource

          3.3.5.2   MemberResource

          Name: http://www.ietf.org/standards/dav/memberresource
          Purpose:  Describes a member of a collection
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   CollectionResource
          Value:    Ref, IsCollection, Content-Type, External, Creation-
          Date, Last-Modified, ETag, DisplayName (other XML elements MAY
          also be copied live, then its present)

          3.3.5.3   Ref

          See XML definition.

          3.3.5.4   IsCollection

          Name: http://www.ietf.org/standards/dav/iscollection
          Purpose:  This is a boolean value MUST be duplicated in an
            identically named, dead resource on the destination
            resource.

            For every dead property defined on the source resource,
            there SHOULD be an octet-for-octet identical dead property
            on which is set to "true" if the destination resource.

            3.5.3.3   COPY for Collections
          entry is a collection
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    ("true" | "false")

          3.3.5.5   Content-Type

          Name: http://www.ietf.org/standards/dav/content-type
          Purpose:  The Depth and Overwrite headers govern the behavior content-type of COPY
            for collections.

            When performing a recursive copy, all HTTP/1.1 request
            headers are duplicated on the propagated method request
            except for the precondition headers If-Modified-Since, If-
            Match, If-None-Match, If-Range, If-Unmodified-Since, which
            should only be applied to the Request-URI member resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    media-type   ; defined in order to
            determine if the operation should Section 3.7 of [Fielding et
          al., 1997]
           If no meaningful content-type can be performed. The
            Destination header generated, then an empty
          value MUST be rewritten to preserve given.

          3.3.5.6   External

          Name: http://www.ietf.org/standards/dav/external
          Purpose:  If present, this element indicates the
            membership resource is an
          external member of the destination collection, i.e., by appending
            the relative URI of collection.  If the member to the URI of the destination
            collection.

            A Depth of “0” indicates the collection MUST duplicate all
            of its external members in a new collection at the
            Destination. Since the COPY method value is not propagated to its
            members, no internal member resource "propagate,"
          it is duplicated.

            A Depth of “1” indicates the collection MUST a propagate member, if the
            COPY to all internal, non-collection members.  If the
            Overwrite header value is "no-propagate," it is “true” a
          no-propagate member.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    ("propagate" | "no-propagate")

          3.3.5.7   Creation-Date

          Name: http://www.ietf.org/standards/dav/creation-date
          Purpose:  The date the COPY method duplicates all of
            its external members resource was created.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    The date MUST be given in a new collection at RFC 1123 format (rfc-1123
          production, defined in section 3.3.1 of [Fielding et al., 1997]

          3.3.5.8   Last-Modified

          Name: http://www.ietf.org/standards/dav/last-modified
          Purpose:  The date the Destination.
            If resource was last modified.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    The date MUST be given in RFC 1123 format (rfc-1123
          production, defined in section 3.3.1 of [Fielding et al., 1997]

          3.3.5.9   ETag

          Name: http://www.ietf.org/standards/dav/etag
          Purpose:  The entity tag of the Overwrite header is “false” and resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    entity-tag    ; defined in Section 3.11 of [Fielding et
          al., 1997]

          3.3.5.10  DisplayName

          Name: http://www.ietf.org/standards/dav/displayname
          Purpose:  A name for the destination resource that is suitable for
          presentation to a collection, person
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   MemberResource
          Value:    Any valid XML character data (from XML specification)

          3.3.5.11  Content-Language

          Name:     http://www.ietf.org/standards/dav/content-language
          Purpose:  Describes the COPY method does not duplicate
            its external members, but is propagated to all internal,
            non-collection members.

            A Depth natural language(s) of “infinity” indicates the collection MUST
            propagate the COPY method to all internal members. If intended
          audience for the
            Overwrite header resource.
          Schema:   http://www.ietf.org.standards/dav/
          Parent:   MemberResource
          Value:    1#language-tag ;language-tag is “true,” the COPY method MUST duplicate
            all of its external members defined in a new collection at the
            Destination. If the Overwrite header is “false” and section
          14.13 of RFC 2068

          3.3.6     Example

               INDEX /user/yarong/dav_drafts/ HTTP/1.1
               Host: www.microsoft.com
               Depth: 1

               HTTP/1.1 200 OK
               Content-Type: application/xml
               Content-Length: xxx
               Last-Modified: xxx
               ETag: "fooyyybar"

               <XML>
               <XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><As
               >D</></>
               <D:CollectionResource>
                    <MemberResource>
                         <XML:Ref>namespace.doc</>
                         <IsCollection>false</>
                         <Content-Type>application/msword</>
                         <External>false</>
                         <Creation-Date>Thu, 20 Mar 1997 23:05:25 GMT</>

                         <Last-Modified>Fri, 22 Aug 1997 18:22:56 GMT</>
                         <Etag>8675309</>
                         <DisplayName>WebDAV Name Space Operations Draft</>
                         <Content-Language>en</>
               </>  </>
               </>
          This example shows the
            destination resource is a collection, then result of the COPY INDEX method
            does not duplicate its external members, but is propagated applied to all internal members.

            3.5.3.4   Type Interactions

            If the destination
          collection resource identifies
          http://www.microsoft.com/er/yarong/dav_drafts/.  It returns a property and
          response body in XML format, which gives information about the
            source resource is not a property, then
          container’s sole member,
          http://www.microsoft.com/users/yarong/dav_drafts/namespace.doc.

          3.4  Behavior of RFC 2068 Methods on Collections

          With the copy SHOULD
            fail.

            If introduction of the destination resource identifies a collection and resource type to the
            Overwrite header HTTP
          object model, it is “true,” prior necessary to performing define the copy, behavior of the server MUST perform a DELETE operation
          existing methods (defined in RFC 2068) when invoked on the
            collection.

            3.5.4     The Response

            200 (OK) The source resource was successfully copied to a
            pre-existing destination resource.

            201 (Created) The source
          collection resource was successfully copied. to avoid ambiguity.  While some methods, such
          as OPTIONS and TRACE behave identically when applied to
          collections, GET, HEAD, POST, PUT, and DELETE require some
          additional explanation.

          3.4.1     GET, HEAD for Collections

          The copy operation resulted in the creation semantics of GET are unchanged when applied to a new
            resource.

            207 (Partial Success) Only some of the member resources were
            copied. The return entity body describes collection,
          since GET is defined as, "retrieve whatever information (in the status code for
            each resource.

            412 (Precondition Failed) This status code MUST be returned
            if
          form of an entity) is identified by the server was unable Request-URI" [Fielding et
          al., 1997]. GET when applied to maintain a collection MAY return the liveness
          contents of an "index.html" resource, a human-readable view of
          the
            properties listed in contents of the Enforce-Live-Properties header, collection, or
            if the Overwrite header is false, something else altogether, and
          hence it is possible the state result of the
            destination resource is non-null.

            500 (Server Error) The resource was in such a GET on a collection will
          bear no correlation to the state that it
            could not be copied. This may occur if of the Destination
            header indicated an external (from collection.

          Similarly, since the point definition of view HEAD is a GET without a
          response message body, the semantics of HEAD do not require any
          modification when applied to collection resources.

          3.4.2     POST for Collections

          Since by definition the
            server) resource and actual function performed by POST is
          determined by the server has no capability to copy to
            an external resource.

            502 (Bad Gateway) - This may occur when copying to external
            resources and often depends on the destination server refused to accept particular
          resource, the
            resource.

            3.5.5     Examples

            3.5.5.1   Overwrite Example

            This example shows resource
            http://www.ics.uci.edu/~fielding/index.html being copied behavior of POST when applied to collections cannot
          be modified because it is largely undefined.  Thus the location
            http://www.ics.uci.edu/users/f/fielding/index.html.  The
            contents semantics
          of POST do not require any modification when applied to a
          collection.

          3.4.3     PUT for Collections

          In HTTP/1.1, PUT stores the destination resource were overwritten, if
            non-null.

                 COPY /~fielding/index.html HTTP/1.1
                 Host: www.ics.uci.edu
                 Destination:
                 http://www.ics.uci.edu/users/f/fielding/index.html
                 Overwrite: “true”

                 HTTP/1.1 200 OK

            3.5.5.2   No Overwrite Example

            The following example shows the same copy operation being
            performed, except with request entity under the Overwrite header set Request-URI,
          and hence its semantics are limited to “false.”
             A response of 412, Precondition Failed, is returned because
            the destination resource has non-collection resources.
          If a non-null state.

                 COPY /~fielding/index.html HTTP/1.1
                 Host: www.ics.uci.edu
                 Destination:
                 http://www.ics.uci.edu/users/f/fielding/index.html

                 HTTP/1.1 412 Precondition Failed

            3.6 MOVE Method

            3.6.1     Problem Description

            The move operation PUT is invoked on a collection resource is it MUST fail.

          When the logical equivalent
            of PUT operation creates a copy followed by new non-collection resource, a delete.

            In HTTP 1.1, the procedure could be performed in several
            steps. First,
          server MAY add that resource’s URI to one or more collections
          within the client could issue a GET server’s controlled namespace.

          3.4.4     DELETE for Collections

          When DELETE is applied to retrieve a
            representation of a collection resource, issue a all internal

          members MUST be recursively deleted. The dav:link/propagate
          external members MUST be deleted and their links must be removed.
          dav:link/nopropagate external members MUST have only their link
          removed; the resources MUST not be deleted.

          The Depth header does not apply to the DELETE method. It cannot
          be used to remove limit the
            resource from extent of the server, then use PUT operation. If it is present it
          MUST be ignored.

          When applied to place any resource, the resource DELETE method deletes all
          properties on the server with Request-URI.

          During DELETE processing, a new URI. As is server MAY remove the case URI of the
          deleted resource(s) from collections within its controlled
          namespace.

          3.4.4.1   New Response Codes for DELETE

          207 (Partial Success) Only some of the member resources were
          deleted. The response entity will describe any errors.

          500 (Server Error) The resource was in such a state that it could
          not be deleted. The response entity will describe reason for the
          error.

          3.5  COPY - Method

          3.5.1     Problem Description

          Currently, in order to create a copy of a resource, the client
          must GET an entity and then PUT that entity to the desired
          destination. This requires (1) an entity to be transmitted to and
          from the server and (2) that the resource be expressible as an
          entity with complete fidelity.   This is problematic because of
          the network traffic involved in making a move, copy, and because there
          is often no way to fully express a resource as an entity without
          a loss of fidelity fidelity.

          3.5.2     Solution Requirements

          The solution:
          - server
            move functionality is preferable.

            With a DAV server,    MUST allow a principal may accomplish this task by
            issuing a COPY and then DELETE. Network load decreases, but
            the server load may still be significant because the server
            must to create a duplicate resource. Were copy of a server resource
            without having to know
            beforehand that a principal intended transmit the resource to perform COPY and
            DELETE operations in succession, it could avoid the creation
            of a duplicate resource.

            3.6.2     Solution Requirements

            The solution:

            Must prevent the unneeded transfer of entity bodies from and
               to the server.

            Must prevent the unneeded creation of copies by the server.

            3.6.3

          3.5.3     The Request

          The MOVE method is defined as the logical equivalent of a COPY followed by method creates a DELETE duplicate of the source resource, performed
            atomically.

            3.6.4     The Response

            200 (OK) - The resource was moved. A successful response
            must contain the Content-Location header, set equal to given
          by the
            URI Request-URI, in source. This lets caches properly flush any cached
            entries for the source. Unfortunately destination resource, given by the Content-Location
          Destination header.  The Destination header only allows a single value so it is not possible for
            caches unfamiliar with MUST be present.  The
          exact behavior of the MOVE COPY method to properly clear
            their caches.

            207 (Partial Success) Only some depends on the type of the member
          source resource.

          3.5.3.1   COPY for HTTP/1.1 resources were
            moved.  The return entity

          When the source resource is not a collection, and is not a
          property, the body will give of the status code for
            each resource.

            412 (Precondition Failed) This status code destination resource MUST be returned
            if the server was unable octet-for-
          octet identical to maintain the liveness body of the source resource. Alterations
          to the destination resource do not modify the source resource.
          Alterations to the source resource do not modify the destination

          resource. Thus, all copies are performed "by-value".

          If the Duplicate-Properties header is "false," then properties listed in
          SHOULD NOT be copied to the Enforce-Live-Properties header, or
            if destination resource. If the Overwrite
          Duplicate-Properties header is false, "false" and the state of the
            destination resource Enforce-Live-
          Properties header is non-null.

            501 (Not Implemented) - This may occur also present, the request MUST fail with a
          412 (Precondition Failed) status code.  [Ed. Note: what if
          resource to be copied has no properties, and no properties are
          explicitly named in the Destination
            header specifies header?]

          All properties on a source resource which is outside its domain of
            control (e.g., stored SHOULD be duplicated on another server) the
          destination resource and following the
            server either refuses or is incapable of moving to an
            external resource.

            502 (Bad Gateway) - This may occur when moving to external
            resources and definition for copying
          properties.

          3.5.3.2   COPY for Properties

          Live properties SHOULD be duplicated as identically behaving live
          properties at the destination server refused to accept the resource.

            3.6.5     Examples

            3.6.5.1   Overwrite Example

            This example shows resource
            http://www.ics.uci.edu/~fielding/index.html being moved to Since they are live
          properties, the location
            http://www.ics.uci.edu/users/f/fielding/index.html.  The
            contents of server determines the destination resource were overwritten, if
            non-null.

                 MOVE /~fielding/index.html HTTP/1.1
                 Host: www.ics.uci.edu
                 Destination:
                 http://www.ics.uci.edu/users/f/fielding/index.html
                 Overwrite: true

                 HTTP/1.1 200 OK
                 Content-Location:
                 http://www.ics.uci.edu/users/f/fielding/index.html

            3.7 Multi-Status Response

            3.7.1     Problem Definition

            Certain methods (COPY, MOVE, syntax and DELETE) when applied to a
            collection might be recursively applied to all sub-members semantics (hence
          value) of these properties.  Properties named by the collection.  In this case, it Enforce-
          Live-
          Properties header MUST be live on the destination resource, or
          the method MUST fail.  If a property is possible that not named by Enforce-
          Live-
          Properties and cannot be copied live, then its value MUST be
          duplicated in an identically named, dead resource on the
            operation will succeed
          destination resource.

          For every dead property defined on some member resources and fail the source resource, there
          SHOULD be an octet-for-octet identical dead property on
            others, thus generating a 207 (Partial Success) status code.
             A principal may need to know which members of the
            collection succeeded and which failed.

            3.7.2     Solution Requirements
          destination resource.

          3.5.3.3   COPY for Collections

          The solution must:

            - communicate the status code Depth and reason

            - give Overwrite headers govern the URI behavior of the resource COPY for
          collections.

          When performing a recursive copy, all HTTP/1.1 request headers
          are duplicated on which the propagated method was
               invoked

            - be consistent with other return body formats

            3.7.3     Multi-Status Response

            The default multi-status response body is an application/xml
            HTTP entity that contains a single XML element called
            multiresponse, which contains a set of XML elements called
            response, one request except for each 200, 300, 400, and 500 series status
            code generated during the method invocation.  100 series
            status codes MUST NOT
          precondition headers If-Modified-Since, If-Match, If-None-Match,
          If-Range, If-Unmodified-Since, which should only be recorded applied to
          the Request-URI in a response XML element.
            Each response XML element contains two sub-entities, ref, order to determine if the operation should be
          performed. The Destination header MUST be rewritten to preserve
          the membership of the destination collection, i.e., by appending
          the relative URI of the resource on which member to the method was invoked, and
            status, which holds URI of the status-line from destination
          collection.

          A Depth of "0" indicates the collection MUST duplicate all of its
          external members in a new collection at the Destination. Since
          the COPY method
            invocation. is not propagated to its members, no internal
          member resource is duplicated.

          A multi-status response Depth of "1" indicates the collection MUST be present when a 207 (Partial
            Success) status code propagate the COPY
          to all internal, non-collection members.  If the Overwrite header
          is returned by "true" the initial COPY method
            invocation.

            3.7.3.1   MultiResponse

            Name:
                   http://www.ietf.org/standards/dav/multiresponse/multi
            response

            Purpose:  Contains multiple response messages.

            Schema:   http://www.ietf.org/standards/dav/multiresponse/

            Parent:   <XML>

            Value:1*Response

            3.7.3.2   Response

            Name:
                   http://www.ietf.org/standards/dav/multiresponse/respo
            nse

            Purpose:  Holds duplicates all of its external members
          in a single response

            Schema:   http://www.ietf.org/standards/dav/multiresponse/

            Parent:   MultiResponse

            Value:Ref, Status

            3.7.3.3   Status

            Name:
                   http://www.ietf.org/standards/dav/multiresponse/statu
            s

            Purpose:  Holds new collection at the Destination. If the Overwrite header
          is "false" and the destination resource is a single HTTP status-line

            Schema:   http://www.ietf.org/standards/dav/multiresponse/

            Parent:   Response

            Value:status-line   ;status-line defined in [HTTP11]

            3.7.4     Example collection, the COPY /users/jdoe/collection/ HTTP/1.1
            Host: www.doecorp.com
            Destination:
            http://www.doecorp.com/users/jdoe/othercollection/
            Depth: infinity
            Overwrite: false

            HTTP/1.1 207 Partial Success
            Content-Type: application/xml
            Content-Length: xxx

            <XML>
            <XML:Namespace><Ref>http://www.ietf.org/standards/dav/multir
            esponse/</><As>R</></>
            <R:MultiResponse>
                 <Response>

                 <XML:Ref>http://www.doecorp.com/users/jdoe/collection/i
            ndex.html</>
                      <Status>HTTP/1.1 412 Precondition Failed</>
                 </>
                 <Response>

                 <XML:Ref>http://www.doecorp.com/users/jdoe/collection/r
            eport.html</>
                      <Status>HTTP/1.1 200 OK</>
                 </>
            </>
            </>

            3.8 ADDREF Method

            3.8.1     Problem Definition

            There needs to be a way to add an external member to a
            collection.

            3.8.2     Solution Requirements

            The solution must:

            allow access control

            allow referencing to URIs of external members

            not require a body

            3.8.3     The Request

            The ADDREF
          method adds the URI specified in the Collection-
            Member header as an does not duplicate its external member members, but is propagated
          to all internal, non-collection members.

          A Depth of "infinity" indicates the collection
            specified by MUST propagate the Request-URI. The value in
          COPY method to all internal members. If the Collection-
            Member Overwrite header MUST be an absolute URI meeting is
          "true," the
            requirements COPY method MUST duplicate all of an its external member URI.  The propagation
            type of

          members in a new collection at the external URI Destination. If the Overwrite
          header is specified in "false" and the Collection-
            Member Header.

            3.9 DELREF Method

            3.9.1     Problem Definition

            There needs to be destination resource is a way to remove an collection,
          then the COPY method does not duplicate its external member from a
            collection.

            3.9.2     Solution Requirements

            The solution must:

            allow access control

            allow referencing members, but
          is propagated to URIs of external members all internal members.

          3.5.3.4   Type Interactions

          If the destination resource identifies a property and the source
          resource is not require a body

            3.9.3     The Request

            The DELREF method removes property, then the URI specified in copy SHOULD fail.

          If the
            Collection-Member destination resource identifies a collection and the
          Overwrite header from is "true," prior to performing the collection specified by copy, the Request-URI.

            3.10 PATCH Method

            3.10.1    Problem Definition

            At present, if
          server MUST perform a principal wishes DELETE operation on the collection.

          3.5.4     The Response

          200 (OK) The source resource was successfully copied to modify a resource, they
            must issue a GET against the resource, modify their local pre-
          existing destination resource.

          201 (Created) The source resource was successfully copied.  The
          copy of operation resulted in the resource, and then issue creation of a PUT to place the
            modified resource on the server. This procedure is
            inefficient because new resource.

          207 (Partial Success) Only some of the entire member resources were
          copied. The return entity body describes the status code for a resource must each
          resource.

          412 (Precondition Failed) This status code MUST be
            transmitted to and from returned if
          the server in order was unable to make even
            small changes.  Ideally, maintain the update entity transmitted to liveness of the server should be proportional properties
          listed in size to the
            modifications.

            3.10.2    Solution Requirements

            The solution must:

            allow partial modification of a resource without having to
               transmit Enforce-Live-Properties header, or if the entire modified resource

            allow byte-range patching

            allows extensions so that patches can be done beyond simple
               byte-range patching

            allow ranges to be deleted, inserted, Overwrite
          header is false, and replaced

            3.10.3    The Request

            The PATCH method contains a list of differences between the
            original version state of the destination resource identified by is
          non-
          null.

          500 (Server Error) The resource was in such a state that it could
          not be copied. This may occur if the Request-
            URI and Destination header indicated
          an external (from the desired content point of view of the server) resource after and
          the PATCH
            action server has been applied. The list of differences is in a
            format defined by the media type of the entity (e.g.,
            "application/diff") and must include sufficient information no capability to allow copy to an external resource.

          502 (Bad Gateway) - This may occur when copying to external
          resources and the destination server refused to convert accept the original version
          resource.

          3.5.5     Examples

          3.5.5.1   Overwrite Example

          This example shows resource
          http://www.ics.uci.edu/~fielding/index.html being copied to the
          location http://www.ics.uci.edu/users/f/fielding/index.html.  The
          contents of the destination resource were overwritten, if non-
          null.

               COPY /~fielding/index.html HTTP/1.1
               Host: www.ics.uci.edu
               Destination:
               http://www.ics.uci.edu/users/f/fielding/index.html
               Overwrite: "true"

               HTTP/1.1 200 OK

          3.5.5.2   No Overwrite Example

          The following example shows the same copy operation being
          performed, except with the Overwrite header set to "false."  A
          response of 412, Precondition Failed, is returned because the desired version.

            Since
          destination resource has a non-null state.
               COPY /~fielding/index.html HTTP/1.1
               Host: www.ics.uci.edu
               Destination:
               http://www.ics.uci.edu/users/f/fielding/index.html

               HTTP/1.1 412 Precondition Failed

          3.6  MOVE Method

          3.6.1     Problem Description

          The move operation on a resource is the semantics logical equivalent of PATCH are non-idempotent, responses
            to this method are not cacheable.

            If a
          copy followed by a delete.

          In HTTP 1.1, the request appears (at least initially) to procedure could be
            acceptable, performed in several steps.
          First, the server MUST transmit an interim 100 response
            message after receiving client could issue a GET to retrieve a representation
          of a resource, issue a DELETE to remove the empty line terminating resource from the
            request headers and continue processing
          server, then use PUT to place the resource on the request.

            While server support for PATCH is optional, if with a server does
            support PATCH, it MUST support at least
          new URI. As is the application/xml
            diff format defined below.  Support case for the VTML difference
            format [VTML] is recommended, but not required.

            3.10.4    application/XML elements for PATCH

            The resourceupdate XML elementXML element contains a set COPY - because of
            XML sub-entities that describe modification operations.  The
            name the network traffic
          involved in making a move, and meaning of these XML elements because there is given below.
            Processing of these directives MUST be performed in the
            order encountered within the XML document.  A directive
            operates on the often no way to
          fully express a resource as modified by all previous
            directives (executed in sequential order).

            3.10.4.1  ResourceUpdate

            Name:
                   http://www.ietf.org/standards/dav/patch/resourceupdat
            e

            Purpose:  Contains an ordered set entity without a loss of changes to fidelity
          - server move functionality is preferable.

          With a non-
            collection, non-property resource.

            Schema:   http://www.ietf.org/standards/dav/patch/

            Parent:   <XML>

            Value:*(Insert | Delete | Replace)

            3.10.4.2  Insert

            Name: http://www.ietf.org/standards/dav/patch/insert

            Purpose:  Insert DAV server, a principal may accomplish this task by
          issuing a COPY and then DELETE. Network load decreases, but the XML elementXML element’s contents
            starting exactly at
          server load may still be significant because the specified octet.

            Schema:   http://www.ietf.org/standards/dav/patch/

            Parent:   ResourceUpdate

            Value:The insert XML elementXML element MUST contain an
            octet XML elementXML element server must
          create a duplicate resource. Were a server to know beforehand
          that specifies an octet
            position within a principal intended to perform COPY and DELETE operations
          in succession, it could avoid the body creation of a duplicate
          resource.  A value of “end”
            specifies

          3.6.2     Solution Requirements

          The solution:
          -    Must prevent the end unneeded transfer of entity bodies from and
            to the resource.  The body server.
          -    Must prevent the unneeded creation of copies by the insert
            XML elementXML element contains server.

          3.6.3     The Request

          The MOVE method is defined as the octets to be inserted.

            3.10.4.3  Delete

            Name: http://www.ietf.org/standards/dav/patch/delete

            Purpose:  Removes the specified range logical equivalent of octets.

            Schema:   http://www.ietf.org/standards/dav/patch/

            Parent:   ResourceUpdate

            Value:The Delete XML elementXML element MUST contain an
            octet-range XML elementXML element. The value a COPY
          followed by a DELETE of this XML
            elementXML element is empty.

            Discussion: The octets which are deleted are removed, which
            means the source resource, performed
          atomically.

          3.6.4     The Response

          200 (OK) - The resource is collapsed and was moved. A successful response must
          contain the length of Content-Location header, set equal to the
            resource is decremented by URI in
          source. This lets caches properly flush any cached entries for
          the size of source. Unfortunately the octet range.  It Content-Location header only allows
          a single value so it is not appropriate to replace deleted octets possible for caches unfamiliar with zeroed-out
            octets, since zero is a valid octet value.

            3.10.4.4  Replace

            Name: http://www.ietf.org/standards/dav/patch/replace

            Purpose:  Replaces
          the specified range MOVE method to properly clear their caches.

          207 (Partial Success) Only some of octets with the
            contents of member resources were
          moved.  The return entity body will give the XML element.  If status code for each
          resource.

          412 (Precondition Failed) This status code MUST be returned if
          the number server was unable to maintain the liveness of octets the properties
          listed in the
            XML element is different from Enforce-Live-Properties header, or if the number of octets
            specified, Overwrite
          header is false, and the update MUST be rejected.

            Schema:   http://www.ietf.org/standards/dav/patch/

            Parent:   ResourceUpdate

            Value:The Replace XML element MUST contain an octet-range
            XML element.  The contents state of the entity are destination resource is
          non-
          null.

          501 (Not Implemented) - This may occur if the replacement
            octets.

            3.10.4.5  Octet-Range Attribute

            Name:
                 http://www.ietf.org/standards/dav/patch/octet-range

            Purpose:  Specifies Destination header
          specifies a range of octets resource which the enclosing
            property effects.

            Schema:   http://www.ietf.org/standards/dav/patch/

            Parent:        Insert, Delete, Replace

            Value:         number [“-“ (number | “end”)]

                      Number = 1*Digit

            Description: Octet numbering begins with 0. If the octet
            contains a single number then the operation is to begin at
            that octet outside its domain of control
          (e.g., stored on another server) resource and to continue for a length specified by the
            operation. In the case server either
          refuses or is incapable of a delete, this would mean moving to
            delete but a single octet. In the case of an insert this
            would mean external resource.

          502 (Bad Gateway) - This may occur when moving to begin external
          resources and the insertion at destination server refused to accept the specified octet and
          resource.

          3.6.5     Examples

          3.6.5.1   Overwrite Example
          This example shows resource
          http://www.ics.uci.edu/~fielding/index.html being moved to continue for the length
          location http://www.ics.uci.edu/users/f/fielding/index.html.  The
          contents of the included value, extending
            the destination resource were overwritten, if necessary. In the case of replace, the
            replace begins at the specified octet and overwrites all
            that follow non-
          null.
               MOVE /~fielding/index.html HTTP/1.1
               Host: www.ics.uci.edu
               Destination:
               http://www.ics.uci.edu/users/f/fielding/index.html
               Overwrite: true

               HTTP/1.1 200 OK
               Content-Location:
               http://www.ics.uci.edu/users/f/fielding/index.html

          3.7  ADDREF Method

          3.7.1     Problem Definition

          There needs to the length be a way to add an external member to a
          collection.

          3.7.2     Solution Requirements

          The solution must:
          -    allow access control
          -    allow referencing to URIs of external members
          -    not require a body

          3.7.3     The Request

          The ADDREF method adds the included value.  Octet
            values MUST specify locations URI specified in the state of the resource
            prior Collection-Member
          header as an external member to the processing of collection specified by the PATCH method.

            3.10.5
          Request-URI. The Response

            200 (OK) - The request entity body was processed without
            error, resulting value in the Collection-Member header MUST be an update to

          absolute URI meeting the state requirements of an external member URI.
          The propagation type of the resource.

            409 (Conflict) external URI is specified in the
          Collection-Member Header.

          3.8  DELREF Method

          3.8.1     Problem Definition

          There needs to be a way to remove an external member from a
          collection.

          3.8.2     Solution Requirements

          The solution must:
          - If    allow access control
          -    allow referencing to URIs of external members
          -    not require a body

          3.8.3     The Request

          The DELREF method removes the update information URI specified in the request
            message body does not make sense given Collection-
          Member header from the current state collection specified by the Request-URI.

          3.9  PATCH Method

          3.9.1     Problem Definition

          At present, if a principal wishes to modify a resource, they must
          issue a GET against the resource, modify their local copy of the resource (e.g., an instruction
          resource, and then issue a PUT to delete place the modified resource on
          the server. This procedure is inefficient because the entire
          entity for a non-existent
            line), this status code MAY resource must be returned.

            415 (Unsupported Media Type) - The server does not support transmitted to and from the content type of server
          in order to make even small changes.  Ideally, the update instructions in entity
          transmitted to the request
            message body.

            416 (Unprocessable Entity) - A new status code.  The server
            understands should be proportional in size to the content type
          modifications.

          3.9.2     Solution Requirements

          The solution must:
          -    allow partial modification of the request entity, but was
            unable a resource without having to process
            transmit the contained instructions.

            3.10.6    Examples

            3.10.6.1  HTML file modification entire modified resource
          -    allow byte-range patching
          -    allows extensions so that patches can be done beyond simple
          byte-range patching
          -    allow ranges to be deleted, inserted, and replaced

          3.9.3     The following example shows Request

          The PATCH method contains a modification list of differences between the title
          original version of the resource identified by the Request-URI
          and
            contents the desired content of the HTML resource
            http://www.example.org/hello.html.

            Before:

                 <HTML>
                 <HEAD>
                 <TITLE>Hello world HTML page</TITLE>
                 </HEAD>
                 <BODY>
                 <P>Hello, world!</P>
                 </BODY>
                 </HTML>

            PATCH Request:                     Response: after the PATCH hello.html HTTP/1.1
                 Host: www.example.org
                 Content-Type: application/xml
                 Content-Length: xxx

                                               HTTP/1.1 100 Continue
                 <XML>
                 <XML:Namespace><ref>http://www.ietf.org/standards/dav/p

                 atch/</><AS>D</></>
                 <D:ResourceUpdate>
                      <Replace><octet-range>14</>&003CTITLE&003ENew
                 Title&003C/TITLE&003E</>
                      <Delete><octet-range>38-50</>
                      <Insert><octet-range>86</>&003CP&003ENew
                 paragraph&003C/P&003E
                 </>
                 </></>
                                               HTTP/1.1 200 OK
            After:

                 <HTML>
                 <HEAD>
                 <TITLE>New Title</TITLE>
                 </HEAD>
                 <BODY>
                 <P>Hello, world!</P>
                 <P>New paragraph</P>
                 </BODY>
                 </HTML>

            3.11 Headers

            3.11.1    Depth action
          has been applied. The Depth header determines the depth to which a method list of differences is
            propagated on a resource’s children.

                 Depth = “Depth” “:” DepthToken
                 DepthToken = "0" | "1" | "infinity" | token

            The optional token allows for extension. A server MUST
            ignore a Depth header with an unknown value.

            3.11.2    Destination

            The Destination header specifies in a destination resource for
            methods such as COPY format defined
          by the media type of the entity (e.g., "application/diff") and MOVE, which take two URIs as
            parameters.

                 Destination= “Destination” “:” URI

            3.11.3    Enforce-Live-Properties

            The Enforce-Live-Properties header specifies properties that
            MUST be “live” after they are copied (moved)
          must include sufficient information to allow the
            destination resource server to
          convert the original version of a copy (or move). If the value “*”
            is given for resource to the header, then it designates all live
            properties on desired
          version.

          Since the source resource.

                 EnforceLiveProperties = "Enforce-Live-Properties” “:"
                 (“*” | 1#( Property-Name ))
                 Property-Name = <“> URI <“>

            3.11.4    Duplicate-Properties

            The Duplicate-Properties header instructs the server whether semantics of PATCH are non-idempotent, responses to duplicate the source resource’s properties onto
          this method are not cacheable.

          If the
            destination resource during a COPY or MOVE.  A value of
            “false” requires that request appears (at least initially) to be acceptable, the
          server MUST NOT duplicate on the
            destination resource any properties that are defined on transmit an interim 100 response message after
          receiving the
            source resource.  By default, empty line terminating the value of this header is
            “true,” and a client MAY omit this header from a request
            when its value is “true.”

                 Duplicate-Properties = “Duplicate-Properties” “:”
                 (“true” | “false”)

            3.11.5    Overwrite

            The Overwrite header specifies whether headers and
          continue processing the request.

          While server should
            overwrite the state of a non-null destination resource
            during support for PATCH is optional, if a COPY or MOVE.  A value of “false” states that the server does
          support PATCH, it MUST NOT perform the COPY or MOVE operation if support at least the
            state of application/xml diff
          format defined below.  Support for the destination resource VTML difference format
          [VTML] is non-null. By default,
            the value recommended, but not required.

          3.9.4     application/XML elements for PATCH

          The resourceupdate XML elementXML element contains a set of Overwrite is “false,” XML
          sub-entities that describe modification operations.  The name and a client MAY omit
            this header from a request when its value
          meaning of these XML elements is “false.” While
            the Overwrite header appears to duplicate the functionality given below. Processing of these
          directives MUST be performed in the If-Match: * header of HTTP/1.1, If-Match applies only
            to order encountered within the Request-URI, and not to
          XML document.  A directive  operates on the Destination resource as modified
          by all previous directives (executed in sequential order).

          3.9.4.1   ResourceUpdate

          Name: http://www.ietf.org/standards/dav/patch/resourceupdate
          Purpose:  Contains an ordered set of changes to a COPY or
            MOVE.

                 Overwrite = “Overwrite” “:” (“true” non-collection,
          non-property resource.
          Schema:   http://www.ietf.org/standards/dav/patch/
          Parent:   <XML>
          Value:    *(Insert | “false”)

            3.11.6    Destroy Header

            When deleting a resource Delete | Replace)

          3.9.4.2   Insert

          Name: http://www.ietf.org/standards/dav/patch/insert
          Purpose:  Insert the client often wishes to specify XML elementXML element’s contents starting
          exactly what sort at the specified octet.
          Schema:   http://www.ietf.org/standards/dav/patch/
          Parent:   ResourceUpdate
          Value:    The insert XML elementXML element MUST contain an octet
          XML elementXML element that specifies an octet position within
          the body of delete is being enacted. a resource.  A value of "end" specifies the end of
          the resource.  The Destroy
            header, used with PEP, allows body of the client insert XML elementXML element
          contains the octets to specify be inserted.

          3.9.4.3   Delete

          Name: http://www.ietf.org/standards/dav/patch/delete
          Purpose:  Removes the end
            result they desire. specified range of octets.
          Schema:   http://www.ietf.org/standards/dav/patch/
          Parent:   ResourceUpdate
          Value:    The Destroy header Delete XML elementXML element MUST contain an
          octet-
          range XML elementXML element. The value of this XML elementXML
          element is specified as
            follows:

                 DestroyHeader = "Destroy" ":" #Choices
                 Choices = "VersionDestroy" | "NoUndelete" | "Undelete"
                 | Token empty.
          Discussion: The Undelete token requests that, if possible, octets which are deleted are removed, which means
          the resource
            should be left in a state such that it can be undeleted. The
            server is not required to honor this request.

            The NoUndelete token requests that collapsed and the length of the resource MUST NOT be
            left in a state such that it can be undeleted.

            The VersionDestroy token includes is
          decremented by the functionality size of the
            NoUndelete token and extends it octet range.  It is not
          appropriate to include having the server
            remove all versioning references to the resource that it has
            control over.

            3.11.7    Collection-Member Header

            The Collection-Member header specifies the URI of an
            external resource to be added/deleted to/from replace deleted octets with zeroed-out octets,
          since zero is a collection.

                 CollectionMember = “Collection-Member” “:” PropType SP
                 URI
                 PropType = “propagation” “=” (“prop” | “noprop”)

            3.12 Links

            3.12.1    Source Link Property Type valid octet value.

          3.9.4.4   Replace

          Name: http://www.ietf.org/standards/dav/link/source http://www.ietf.org/standards/dav/patch/replace
          Purpose:  The destination  Replaces the specified range of octets with the source link identifies
          contents of the
            resource that contains XML element.  If the unprocessed source number of octets in the link’s
            source. XML
          element is different from the number of octets specified, the
          update MUST be rejected.
          Schema:   http://www.ietf.org/standards/dav/link/   http://www.ietf.org/standards/dav/patch/
          Parent:   Any.

            Value:An   ResourceUpdate
          Value:    The Replace XML document with zero or more link element MUST contain an octet-range XML elements.

            Discussion:
          element.  The source contents of the link (src) is typically entity are the

            URI replacement octets.

          3.9.4.5   Octet-Range Attribute

          Name:          http://www.ietf.org/standards/dav/patch/octet-
          range
          Purpose:  Specifies a range of the output resource on octets which the link enclosing
          property effects.
          Schema:   http://www.ietf.org/standards/dav/patch/
          Parent:        Insert, Delete, Replace
          Value:         number ["-" (number | "end")]
                    Number = 1*Digit
          Description: Octet numbering begins with 0. If the octet contains
          a single number then the operation is defined, to begin at that octet and
            there is typically only one destination (dst)
          to continue for a length specified by the operation. In the case
          of a delete, this would mean to delete but a single octet. In the link,
            which is
          case of an insert this would mean to begin the URI where insertion at the unprocessed source
          specified octet and to continue for the length of the included
          value, extending the resource may be accessed.  When more than one link
            destination exists, DAV asserts no policy on partial
            ordering.

            4  State Tokens

            4.1 Overview

            4.1.1     Problem Description

            There are times when a principal will want to predicate
            successful execution of a method on if necessary. In the current state of a
            resource.  While HTTP/1.1 provides a mechanism for
            conditional execution case of methods using entity tags via
          replace, the
            “If-Match” and “If-None-Match” headers, replace begins at the mechanism is not
            sufficiently extensible to express conditional statements
            involving more generic state indicators, such as lock
            tokens.

            The fundamental issue with entity tags is specified octet and overwrites
          all that they can only
            be generated by a resource. However there are times when a
            client will want to be able to share state tokens between
            resources, potentially on different servers, as well as be
            able follow to generate certain types the length of lock tokens without first
            having to communicate with a server.

            For example, a principal may wish to require that resource B
            have a certain state the included value.  Octet
          values MUST specify locations in order for a method to successfully
            execute on resource A. If the client submits an e-tag from
            resource B to resource A, then A has no way state of knowing that the e-tag is meant to describe resource B.

            Another example occurs when a principal wishes prior
          to predicate the successful completion processing of a method on the absence of any
            locks on a resource. It is not sufficient to submit PATCH method.

          3.9.5     The Response

          200 (OK) - The request entity body was processed without error,
          resulting in an “If-
            None-Match: *” as this refers update to the existence of an entity,
            not state of a lock.

            This draft defines the term “state token” as an identifier
            for a state of a resource. The sections below define
            requirements for state tokens and provide a  state token
            syntax, along with two new headers which can accept

          409 (Conflict) - If the new
            state token syntax.

            4.1.2     Solution Requirements

            4.1.2.1   Syntax

            Self-Describing. A state token must be self describing such
            that upon inspecting a update information in the request message
          body does not make sense given the current state token it is possible to
            determine what sort of state token it is, what resource(s)
            it applies to, and what state it represents.

            This self-describing nature allows servers the resource
          (e.g., an instruction to accept tokens
            from other servers and potentially delete a non-existent line), this status
          code MAY be able to coordinate
            state information cross resource and cross site through
            standardized protocols. For example, returned.

          415 (Unsupported Media Type) - The server does not support the execution
          content type of a the update instructions in the request on resource message
          body.

          416 (Unprocessable Entity) - A can be predicated on new status code.  The server
          understands the state content type of
            resource B, where A and B are potentially on different
            servers.

            Client Generable. The state token syntax must allow, when

            appropriate, for clients the request entity, but was
          unable to generate a state token without
            having first communicated with process the contained instructions.

          3.9.6     Examples

          3.9.6.1   HTML file modification

          The following example shows a server.

            One drawback modification of entity tags is that they are set by the
            server, title and there is no interoperable algorithm for
            calculating an entity tag. Consequently, a client cannot
            generate an entity tag from a particular state of a
            resource.  However, a state token which encodes an MD5 state
            hash could be calculated by a client based on a client-held
            state
          contents of a resource, and then submitted the HTML resource http://www.example.org/hello.html.
          Before:
               <HTML>
               <HEAD>
               <TITLE>Hello world HTML page</TITLE>

               </HEAD>
               <BODY>
               <P>Hello, world!</P>
               </BODY>
               </HTML>
          PATCH Request:                     Response:
               PATCH hello.html HTTP/1.1
               Host: www.example.org
               Content-Type: application/xml
               Content-Length: xxx

                                             HTTP/1.1 100 Continue
               <XML>
               <XML:Namespace><ref>http://www.ietf.org/standards/dav/patch/
               </><AS>D</></>
               <D:ResourceUpdate>
                    <Replace><octet-range>14</>&003CTITLE&003ENew
               Title&003C/TITLE&003E</>
                    <Delete><octet-range>38-50</>
                    <Insert><octet-range>86</>&003CP&003ENew
               paragraph&003C/P&003E
               </>
               </></>
                                             HTTP/1.1 200 OK
          After:
               <HTML>
               <HEAD>
               <TITLE>New Title</TITLE>
               </HEAD>
               <BODY>
               <P>Hello, world!</P>
               <P>New paragraph</P>
               </BODY>
               </HTML>

          3.10 Headers

          3.10.1    Depth

          The Depth header determines the depth to which a server in a
            conditional method invocation.

            Another potential use for client generable state tokens is
          propagated on a resource’s children.
               Depth = "Depth" ":" DepthToken
               DepthToken = "0" | "1" | "infinity" | token

          The optional token allows for extension. A server MUST ignore a client to generate lock tokens
          Depth header with wild card fields, an unknown value.

          3.10.2    Destination

          The Destination header specifies a destination resource for
          methods such as COPY and hence MOVE, which take two URIs as parameters.
               Destination= "Destination" ":" URI

          3.10.3    Enforce-Live-Properties

          The Enforce-Live-Properties header specifies properties that MUST
          be able to express conditionals such as: “only
            execute this GET if there "live" after they are no write locks on this
            resource.”

            4.1.2.2   Conditonals

            Universal. A solution must be applicable copied (moved) to all requests.

            Positive and Negative. Conditional expressions must allow
            for the expression destination
          resource of both positive and negative state
            requirements.

            4.2 State Token Syntax
            State tokens are URLs employing a copy (or move). If the following syntax:

            State-Token = “StateToken:” Type “:” Resources “:” State-
            Info
            Type = “Type” “=” Caret-encoded-URL
            Resources = “Res” “=” Caret-encoded-URL
            Caret-encoded-URL value "*" is given for the
          header, then it designates all live properties on the source
          resource.
               EnforceLiveProperties = “^” Resource “^”
            Resource "Enforce-Live-Properties" ":" ("*" |

               1#( Property-Name ))
               Property-Name = <A <"> URI where all “^” characters <">

          3.10.4    Duplicate-Properties

          The Duplicate-Properties header instructs the server whether to
          duplicate the source resource’s properties onto the destination
          resource during a COPY or MOVE.  A value of "false" requires that
          the server MUST NOT duplicate on the destination resource any
          properties that are escaped>
            State-Info = *(uchar | reserved)  ; uchar, reserved defined
            section 3.2.1 on the source resource.  By default,
          the value of RFC 2068

            This proposal has created a new URL scheme for state tokens
            because this header is "true," and a state token names client MAY omit this
          header from a network resource using request when its
            normal name, which value is typically state-invariant, along with
            additional information that "true."
               Duplicate-Properties = "Duplicate-Properties" ":" ("true" |
               "false")

          3.10.5    Overwrite

          The Overwrite header specifies a particular whether the server should
          overwrite the state of a non-null destination resource during a
          COPY or MOVE.  A value of "false" states that the resource.  Encoding server MUST NOT
          perform the state information into COPY or MOVE operation if the
            native URL scheme state of the network
          destination resource was not felt to be
            safe, since freedom from name space collisions could not be
            guaranteed. If is non-null. By default, the value of
          Overwrite is "false," and a client MAY omit this proposal header from a
          request when its value is accepted, "false." While the StateToken URL
            scheme will need Overwrite header
          appears to be defined and registered with IANA.

            State Token URLs begin with duplicate the URL scheme name “StateToken”
            rather than the name functionality of the particular state token type they
            represent in order If-Match: * header
          of HTTP/1.1, If-Match applies only to make the URL self describing. Thus it
            is possible Request-URI, and not to examine
          the URL and know, at Destination of a minimum, that
            it is COPY or MOVE.
               Overwrite = "Overwrite" ":" ("true" | "false")

          3.10.6    Destroy Header

          When deleting a state token.

            Labeled name/value pairs are used within resource the token to allow
            new fields client often wishes to be added. Processors specify
          exactly what sort of state tokens MUST be
            prepared delete is being enacted. The Destroy header,
          used with PEP [Connolly et al., 1997], allows the client to accept
          specify the fields in whatever order they are
            present and MUST ignore any fields end result they do not understand. desire. The “Type” field specifies the type of Destroy header is
          specified as follows:
               DestroyHeader = "Destroy" ":" #Choices
               Choices = "VersionDestroy" | "NoUndelete" | "Undelete" |
               Token

          The Undelete token requests that, if possible, the state information
            encoded resource
          should be left in the a state token. A URL such that it can be undeleted. The
          server is used in order not required to avoid
            namespace collisions. honor this request.

          The “Res” field identifies NoUndelete token requests that the resource for which the MUST NOT be left
          in a state such that it can be undeleted.

          The VersionDestroy token includes the functionality of the
          NoUndelete token specifies a particular state. Since commas and spaces
            are acceptable URL characters, a caret extends it to include having the server
          remove all versioning references to the resource that it has
          control over.

          3.10.7    Mandatory header

          The Mandatory header is used to delimit a
            URL. Since indicate a caret is an acceptable URL character, any

            instances list of it other header
          field names which must be escaped using understood by the % escape
            convention.

            The State-Info production is expanded upon in descriptions receiver before the
          contents of specific state token types, and is intended to contain the state description information for message can be stored, cached, or presented to a particular state
            token.

            4.3 State Token Conditional Headers

            4.3.1     If-State-Match

            If-State-Match = "If-State-Match" ":" (“AND” | “OR”) 1#(“<”
            State-Token “>”)

            The If-State-Match
          user. This header is intended to have similar
            functionality used to alert the If-Match header defined in section
            14.25 of RFC 2068.

            If receiver that, unlike the AND keyword is used and all
          default behavior, it cannot safely ignore the semantics of the state tokens
            identify
          listed field-names if they are not understood.

                 Mandatory      = "Mandatory" ":" 1#field-name

          3.10.8    Collection-Member Header

          The Collection-Member header specifies the state URI of an external
          resource to be added/deleted to/from a collection.
               CollectionMember = "Collection-Member" ":" PropType SP URI
               PropType = "propagation" "=" ("prop" | "noprop")

          3.11 Links

          3.11.1    Source Link Property Type

          Name: http://www.ietf.org/standards/dav/link/source
          Purpose:  The destination of the resource, then source link identifies the server MAY
            perform
          resource that contains the requested method. If unprocessed source of the OR keyword is used and
            any link’s
          source.
          Schema:   http://www.ietf.org/standards/dav/link/
          Parent:   Any.
          Value:    An XML document with zero or more link XML elements.
          Discussion: The source of the state tokens identifies link (src) is typically the current state URI of
          the
            resource, then server MAY perform output resource on which the requested method.  If
            neither link is defined, and there is
          typically only one destination (dst) of the keyword requirements link, which is met, the server MUST
            NOT perform
          URI where the requested method, and MUST return a 412
            (Precondition Failed) response.

            4.3.2     If-None-State-Match

            If-None-State-Match = "If-None-State-Match" “:” 1#(“<”
            State-Token “>”)

            The If-None-State-Match header is intended to have similar
            functionality to the If-None-Match header defined in section
            14.26 of RFC 2068.

            If any of the state tokens identifies the current state unprocessed source of the resource, the server MUST NOT perform the requested
            method.  Instead, if the request method was GET, HEAD,
            INDEX, or GETMETA, the server SHOULD respond with resource may be accessed.
          When more than one link destination exists, DAV asserts no policy
          on partial ordering.

          4    State Tokens

          4.1  Overview

          4.1.1     Problem Description

          There are times when a 304 (Not
            Modified) response, including the cache-related entity-
            header fields (particularly ETag) principal will want to predicate
          successful execution of a method on the current state of
            the a
          resource.  For all other request methods, the server
            MUST respond with  While HTTP/1.1 provides a status of 412 (Precondition Failed).

            If none of the state tokens identifies the current state mechanism for conditional
          execution of methods using entity tags via the resource, the server MAY perform the requested method.

            Note that the “AND” "If-Match" and “OR” keywords specified with
          "If-
          None-Match" headers, the If-
            State-Match header are intentionally not defined for If-
            None-State-Match, because this functionality mechanism is not
            required.

            4.4 State Token Header
            State-Token-Header = “State-Token” “:” 1#(“<” State-Token
            “>”)
            The State Token header is intended to have similar
            functionality sufficiently extensible
          to the etag header defined in section 14.20 of
            RFC 2068. express conditional statements involving more generic state
          indicators, such as lock tokens.

          The purpose of the tag fundamental issue with entity tags is to return state tokens
            defined on a resource in that they can only be
          generated by a response. The contents of the
            state-token resource. However there are not guaranteed times when a client
          will want to be exhaustive and are
            generally used able to return a new share state token that has been
            defined tokens between resources,
          potentially on different servers, as the result well as be able to generate
          certain types of lock tokens without first having to communicate
          with a method. server.

          For example, if a LOCK principal may wish to require that resource B have
          a certain state in order for a method were to successfully executed execute on a
          resource A. If the response
            would include a state token header with the lock state token
            included.

            4.5 E-Tags
            E-tags have already been deployed using the If-Match and If-
            None-Match headers.  Introducing two mechanisms to express
            e-tags would only confuse matters, therefore e-tags should
            continue client submits an e-tag from resource B to be expressed using quoted strings and
          resource A, then A has no way of knowing that the If-
            Match and If-None-Match headers.

            5  Locking

            5.1 Problem Description - Overview
            Locking e-tag is used to arbitrate access meant
          to a describe resource amongst
            principals that have equal access rights to that resource.

            This draft allows locks B.

          Another example occurs when a principal wishes to vary over two parameters, the
            number of principals involved and predicate the type
          successful completion of access to be
            granted. This draft will only provide for a method on the definition absence of
            locking for one access type, write. However, the syntax any locks on

          a resource. It is
            extensible enough not sufficient to submit an "If-None-Match: *"
          as this refers to allow for the specification existence of other
            access types. It is a goal an entity, not of this proposal that it use a lock.

          This draft defines the
            same access verbs term "state token" as will be defined in the access control
            draft.

            5.1.1     Exclusive Vs. Shared Locks

            The most basic form of LOCK is an exclusive lock. This is identifier for a
            lock where the access right in question is only granted to
          state of a
            single principal. resource. The need sections below define requirements for this arbitration results from
          state tokens and provide a desire to avoid having to constantly merge results. In
            fact, many users so dislike having to merge  state token syntax, along with two
          new headers which can accept the new state token syntax.

          4.1.2     Solution Requirements

          4.1.2.1   Syntax

          Self-Describing. A state token must be self describing such that they would
            rather serialize their access to
          upon inspecting a resource rather than have state token it is possible to constantly perform merges.

            However, there are times when the goal determine what
          sort of a lock is not state token it is, what resource(s) it applies to, and
          what state it represents.

          This self-describing nature allows servers to
            exclude others accept tokens from exercising an access right but rather
          other servers and potentially be able to
            provide coordinate state
          information cross resource and cross site through standardized
          protocols. For example, the execution of a mechanism for principals to indicate that they
            intend to exercise their access right.  Shared locks are
            provided for this case. request on resource A shared lock allows multiple
            principals to receive a lock, hence any principal with
            appropriate access
          can get be predicated on the lock.

            With shared locks there state of resource B, where A and B are two trust sets that affect a
            resource.
          potentially on different servers.

          Client Generable. The first trust set is created by access
            permissions. Principals who are trusted, state token syntax must allow, when
          appropriate, for example, may
            have permission to write the resource, those who are not,
            don't.  Among those who have access permission clients to write the
            resource, the set of principals who have taken out generate a shared
            lock also must trust each other, creating state token without having
          first communicated with a (probably)
            smaller trust server.

          One drawback of entity tags is that they are set within the access permission write set.

            Starting with every possible principal on the Internet, in
            most situations by the vast majority of these principals will
            not have write access to server,
          and there is no interoperable algorithm for calculating an entity
          tag. Consequently, a given resource.  Of the small
            number who do have write access, some principals may decide
            to guarantee their edits are free client cannot generate an entity tag from overwrite conflicts
            by using exclusive write locks in conjunction with a
            precondition header (If-State-Match) that checks for
            existence
          particular state of the lock prior to writing the a resource. Others
            may decide they trust their collaborators (the potential set
            of collaborators being the set of principals who have write
            permission) and use  However, a shared lock, state token which informs their
            collaborators that
          encodes an MD5 state hash could be calculated by a principal is potentially working client based
          on the
            resource.

            The WebDAV extensions to HTTP do not need to provide all a client-held state of
            the communications paths necessary for principals a resource, and then submitted to

            coordinate their activities.  When using shared locks,
            principals may a
          server in a conditional method invocation.

          Another potential use any out of band communication channel to
            coordinate their work (e.g., face-to-face interaction,
            written notes, post-it notes on the screen, telephone
            conversation, email).  The intent of for client generable state tokens is for a shared
          client to generate lock is tokens with wild card fields, and hence
          be able to let
            collaborators know who else is potentially working on a
            resource..

            Why not use exclusive express conditionals such as: "only execute this GET
          if there are no write locks on this resource."

          4.1.2.2   Conditonals

          Universal. A solution must be applicable to all requests.
          Positive and Negative. Conditional expressions must allow for the time?  Experience
            from initial Web distributed authoring systems has indicated
            that exclusive write locks
          expression of both positive and negative state requirements.

          4.2  State Token Syntax
          State tokens are often too rigid.  An
            exclusive write lock URLs employing the following syntax:
          State-Token = "StateToken:" Type ":" Resources ":" State-Info
          Type = "Type" "=" Caret-encoded-URL
          Resources = "Res" "=" Caret-encoded-URL
          Caret-encoded-URL = "^" Resource "^"
          Resource = <A URI where all "^" characters are escaped>
          State-Info = *(uchar | reserved)  ; uchar, reserved defined
          section 3.2.1 of RFC 2068

          This proposal has created a new URL scheme for state tokens
          because a state token names a network resource using its normal
          name, which is used to enforce typically state-invariant, along with additional
          information that specifies a particular editing
            process: take out exclusive write lock, read the resource,
            perform edits, write state of the resource, release resource.

          Encoding the lock.  What
            happens if state information into the lock isn't released?  While native URL scheme of the time-out
            mechanism provides one solution, if you need
          network resource was not felt to force the
            release of a lock immediately, it doesn't help much.
            Granted, an administrator can release the lock for you, but
            this could become a significant burden for large sites.
            Further, what if the administrator can't be reached
            immediately?

            Despite their potential problems, exclusive write locks are
            extremely useful, safe, since often a guarantee of freedom from
            overwrite conflicts is exactly what name
          space collisions could not be guaranteed. If this proposal is needed.  The
            solution: provide exclusive write locks, but also provide a
            less strict mechanism in
          accepted, the form of shared locks which can
            be used by a set of people who trust each other and who have
            access to a communications channel external StateToken URL scheme will need to HTTP which
            can be used to negotiate writing to defined and
          registered with IANA.

          State Token URLs begin with the resource.

            5.1.2     Required Support

            A DAV compliant server is not required to support locking URL scheme name "StateToken"
          rather than the name of the particular state token type they
          represent in
            any form. If order to make the server does support locking URL self describing. Thus it may choose is
          possible to support any combination of exclusive examine the URL and shared locks for
            any access types.

            The reason for this flexibility is that server implementers
            have said know, at a minimum, that they it is a
          state token.

          Labeled name/value pairs are willing used within the token to accept minimum
            requirements on all services but locking. Locking policy
            strikes allow new
          fields to the very heart be added. Processors of their resource management and
            versioning systems and they require control over what sort
            of locking will state tokens MUST be made available. For example, some systems
            only support shared write locks while others only provide
            support for exclusive write locks. As each system is
            sufficiently different prepared
          to merit exclusion of certain locking
            features, accept the authors fields in whatever order they are proposing that locking be allowed
            as present and MUST
          ignore any fields they do not understand.
          The "Type" field specifies the sole axis type of negotiation within DAV.

            5.2 LOCK Method

            5.2.1     Operation

            A lock method invocation creates the lock specified by the
            Lock-Info header on state information
          encoded in the request-URI. Lock method requests
            SHOULD NOT have a request body. A user-agent SHOULD submit
            an Owner header field with a lock request. state token. A successful response URL is used in order to a lock invocation MUST include a
            Lock-Token header. If avoid
          namespace collisions.

          The "Res" field identifies the server supports a time based lock
            removal mechanism on resource for which the resource, a successful lock
            invocation SHOULD return state token
          specifies a Time-Out header.

            5.2.2     The Effect of Locks on Properties particular state. Since commas and Containers

            By default spaces are
          acceptable URL characters, a lock affects the entire state of the resource,
            including its associated properties. As such it caret is illegal used to specify a lock on delimit a property. For containers, URL.
          Since a lock also
            affects the ability to add or remove members. The nature caret is an acceptable URL character, any instances of it
          must be escaped using the effect depends % escape convention.

          The State-Info production is expanded upon the type in descriptions of access control involved.
             The Depth header expresses the general semantics of a LOCK
            method request when invoked on a collection (note that
          specific lock types may restrict state token types, and is intended to contain the effect of a lock, state
          description information for
            example limiting the allowable values of a particular state token.

          4.3  State Token Conditional Headers

          4.3.1     If-State-Match

          If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#("<"
          State-
          Token ">")

          The If-State-Match header is intended to have similar
          functionality to the Depth header):

            A Depth If-Match header (defined defined in section 14.25 of
          RFC 2068.

          If the namespace draft) may be used
               on a LOCK method when the LOCK method AND keyword is applied to a
               collection resource. The legal values for Depth on a LOCK
               are 0, 1, used and Infinity. A Depth all of 0 instructs the
               resource to just lock the container. As previously
               mentioned, depending on state tokens identify
          the type state of lock, the lock affects resource, then the ability to add or remove members of server MAY perform the container.

            @.A Depth of 1 means that
          requested method. If the container OR keyword is locked used and a LOCK
               is executed on the container’s propagate members with a
               Depth any of 0 and If-Range, If-Modified-Since, If-Unmodified-
               Since, If-Match and If-None-Match headers are dropped.
               However, the effects state
          tokens identifies the current state of the LOCK MUST be atomic in that
               either resource, then server
          MAY perform the container and all of its members are locked or
               no lock is granted. The result requested method.  If neither of a Depth 1 lock the keyword
          requirements is a
               single lock token which represents met, the lock on server MUST NOT perform the
               container requested
          method, and all of its members. This lock token may be
               used in an If-State-Match or If-Not-State-Match MUST return a 412 (Precondition Failed) response.

          4.3.2     If-None-State-Match

          If-None-State-Match = "If-None-State-Match" ":" 1#("<" State-
          Token ">")

          The If-None-State-Match header
               against is intended to have similar
          functionality to the If-None-Match header defined in section
          14.26 of RFC 2068.

          If any of the resources covered by the lock. Since state tokens identifies the lock token represents a lock on all current state of the resources, an
               UNLOCK using that token will remove
          resource, the lock from all
               included resources, not just server MUST NOT perform the resource requested method.
          Instead, if the UNLOCK request method was
               executed on.

            @.A Depth of infinity means that GET, HEAD, INDEX, or GETMETA,

          the LOCK is recursively
               executed, server SHOULD respond with a Depth 304 (Not Modified) response,
          including the cache-related entity-header fields (particularly
          ETag) of infinity, on the collection and
               all current state of its propagate members and the resource.  For all of their propagate
               members. As other
          request methods, the server MUST respond with a Depth status of 412
          (Precondition Failed).

          If none of 1, the LOCK must be granted in
               total or not at all. Otherwise the lock operates in state tokens identifies the
               same manner as a Depth current state of 1 lock.

            The default behavior when locking a container is to act as
            if a “Depth: 0” header had been placed on the method.

            5.2.3     Locking Replicated Resources

            Some servers automatically replicate resources across
            multiple URLs. In such a circumstance
          resource, the server MAY only
            accept a lock on one of the URLs if perform the server can guarantee requested method.

          Note that the lock will be honored across all the URLs.

            5.2.4     Interaction "AND" and "OR" keywords specified with other Methods

            Only two methods, MOVE and DELETE, have side effects which
            involve locks. When a resource is moved, its lock SHOULD be
            moved with it. However the If-
          State-
          Match header are intentionally not defined for If-None-State-
          Match, because this may functionality is not always be possible and
            there required.

          4.4  State Token Header

          State-Token-Header = "State-Token" ":" 1#("<" State-Token ">")
          The State Token header is currently no proposal intended to create a header which
            would specify that the lock request should fail if the
            resource’s locks can not be maintained. A COPY MUST NOT copy
            any locks on the source resource over have similar functionality
          to the destination
            resource. Deleting a resource MUST remove all locks on the
            resource.

            5.2.5     Lock Compatibility Table etag header defined in section 14.20 of RFC 2068. The table below describes the behavior that occurs when a
            lock request is made on a resource.

            Current lock state/      Shared Lock       Exclusive Lock
            Lock request
            None                     True              True
            Shared Lock              True              False
            Exclusive Lock           False             False*
            Legend: True = lock MAY be granted.  False = lock MUST NOT
            be granted.  *=if the principal requesting the lock is the
            owner
          purpose of the lock, the lock MAY be regranted.

            The current lock tag is to return state of tokens defined on a
          resource is given in a response. The contents of the
            leftmost column, state-token are not
          guaranteed to be exhaustive and lock requests are listed in the first
            row.  The intersection of generally used to return a row and column gives
          new state token that has been defined as the result of a lock request. method.
          For example, if a shared lock is held LOCK method were successfully executed on a resource, and an exclusive lock is requested,
          resource the table
            entry is “false”, indicating response would include a state token header with the
          lock must not be granted.

            If an exclusive lock is re-requested by the principal who
            owns the lock, state token included.

          4.5  E-Tags
          E-tags have already been deployed using the lock MAY If-Match and If-None-
          Match headers.  Introducing two mechanisms to express e-tags
          would only confuse matters, therefore e-tags should continue to
          be regranted. If expressed using quoted strings and the lock If-Match and If-None-
          Match headers.

          5    Locking

          5.1  Problem Description - Overview

          Locking is
            regranted, the same lock token used to arbitrate access to a resource amongst
          principals that have equal access rights to that was previously issued
            MUST be returned.

            5.2.6     Status Codes

            412 “Precondition Failed” – The included state-token was not
            enforceable on this resource.

            416 “Locked” – The resource is locked so the method has been
            rejected.

            5.2.7     Example

            LOCK /workspace/webdav/proposal.doc HTTP/1.1
            Host: webdav.sb.aol.com
            Lock-Info: LockType=Write LockScope=Exclusive
            Owner: <http://www.ics.uci.edu/~ejw/contact.html>

            HTTP/1.1 200 OK
            State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http:/
            /www.ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Wri
            te:LockScope=Exclusive:ServerID=12382349AdfFFF
            Time-Out: ClockType=Activity TimeType=second;604800

          This example shows draft allows locks to vary over two parameters, the successful creation number
          of an exclusive
            write lock on resource
            http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The
            resource http://www.ics.uci.edu/~ejw/contact.html contains
            contact information for principals involved and the owner type of the lock. The server
            has an activity-based timeout policy in place on this
            resource, which causes the lock access to automatically be removed
            after 1 week (604800 seconds). The response has a Lock-Token
            header that gives the state token URL granted. This
          draft will only provide for the lock token
            generated by this lock request.

            5.2.8     Lock-Info Request Header

            The Lock-Info header specifies the scope and type definition of a lock locking for a LOCK method request. The one
          access type, write. However, the syntax specification below is
            extensible, allowing new type and scope identifiers extensible enough to be
            added.

            LockInfo = “Lock-Info” “:” DAVLockType SP DAVLockScope CRLF
            DAVLockType = “LockType” “=” DAVLockTypeValue
            DAVLockTypeValue = (“Write” | *(uchar | reserved))
            DAVLockScope = “LockScope” “=” DAVLockScopeValue
            DAVLockScopeValue = (“Exclusive” |”Shared” | *(uchar |
            reserved))

            5.2.9     Owner Request Header

            5.2.9.1   Problem Description

            When discovering
          allow for the list of owners specification of locks on a resource, other access types. It is a principal may want to be able to contact the owner
            directly. For goal
          of this to proposal that it use the same access verbs as will be possible
          defined in the access control draft.

          5.1.1     Exclusive Vs. Shared Locks

          The most basic form of LOCK is an exclusive lock. This is a lock discovery
            mechanism must provide enough information for
          where the lock owner
            to be contacted.

            5.2.9.2   Solution Requirements

            Not all systems have authentication procedures that provide
            sufficient information to identify a particular user access right in a
            way that question is meaningful only granted to a human. single
          principal. The need for this arbitration results from a desire to
          avoid having to constantly merge results. In addition, fact, many systems users so
          dislike having to merge that do have sufficient information, such as they would rather serialize their
          access to a name and e-
            mail address, do not resource rather than have the ability to associate this
            information with constantly perform
          merges.

          However, there are times when the lock discovery mechanism. Therefore goal of a
            means lock is needed not to allow principals
          exclude others from exercising an access right but rather to

          provide
            authentication in a manner which will be meaningful mechanism for principals to a
            human.

            The From header (defined in RFC 2068), which contains only
            an email mailbox, is not sufficient for the purposes of
            quick identification. When desperately looking indicate that they intend
          to exercise their access right.  Shared locks are provided for someone
          this case. A shared lock allows multiple principals to remove receive a
          lock, e-mail is often not sufficient. A
            telephone number (cell number, pager number, etc.) would be
            better. Furthermore, the email address in the From field may
            or may not support including hence any principal with appropriate access can get the owners name and
          lock.

          With shared locks there are two trust sets that name
            is often set to an alias anyway. Therefore affect a header more
            flexible than From is required.

            5.2.9.3   Syntax

            Owner = "Owner" ":" ((“<” URI “>”)  | quoted-string)
          resource.  The URI SHOULD provide a means first trust set is created by access permissions.
          Principals who are trusted, for either directly
            contacting example, may have permission to
          write the principal (such as a telephone number or e-
            mail URI), or for discovering resource, those who are not, don't.  Among those who
          have access permission to write the principal (such as resource, the
            URL set of
          principals who have taken out a homepage).  The quoted string SHOULD provide shared lock also must trust each
          other, creating a
            means for directly contacting (probably) smaller trust set within the principal, such as a name
            and telephone number.

            5.2.10    Time-Out Header

            5.2.10.1  Problem Description

            In a perfect world principals take out locks, use access
          permission write set.

          Starting with every possible principal on the
            resource as needed, and then remove Internet, in most
          situations the lock when it is no
            longer needed. However, this scenario is frequently vast majority of these principals will not
            completed, leaving active but unused locks. Reasons for this
            include client programs crashing and loosing information
            about locks, users leaving their systems for the day and
            forgetting have
          write access to remove their locks, etc. As a result of this
            behavior, servers need given resource.  Of the small number who do
          have write access, some principals may decide to establish a policy guarantee their
          edits are free from overwrite conflicts by which they
            can remove using exclusive write
          locks in conjunction with a lock without input from precondition header (If-State-Match)
          that checks for existence of the lock owner. Once
            such a policy is instituted, the server also needs a
            mechanism prior to inform writing the principal
          resource. Others may decide they trust their collaborators (the
          potential set of collaborators being the policy.

            5.2.10.2  Solution Requirements

            There are two basic lock removal policies, administrator set of principals who
          have write permission) and
            time based remove. In the first case use a shared lock, which informs their
          collaborators that a principal other than is potentially working on the lock owner has sufficient access rights
          resource.

          The WebDAV extensions to order the
            lock removed, even though they did HTTP do not take it out. User-
            agents MUST assume that such a mechanism is available and
            thus locks need to provide all of the
          communications paths necessary for principals to coordinate their
          activities.  When using shared locks, principals may arbitrarily disappear at use any time. If their
            actions require confirmation out
          of band communication channel to coordinate their work (e.g.,
          face-to-face interaction, written notes, post-it notes on the existence
          screen, telephone conversation, email).  The intent of a shared
          lock then
            the If-State headers are available.

            The second solution, is the time based removal policy.
            Activity based systems set to let collaborators know who else is potentially working
          on a timer as soon as resource.

          Why not use exclusive write locks all the time?  Experience from
          initial Web distributed authoring systems has indicated that
          exclusive write locks are often too rigid.  An exclusive write
          lock is
            taken out. Every time used to enforce a method is executed on particular editing process: take out
          exclusive write lock, read the resource, perform edits, write the timer is reset. If
          resource, release the timer runs out, lock.  What happens if the lock is
            removed.

            Finally, some systems only allow locks isn't
          released?  While the time-out mechanism provides one solution, if
          you need to exist for force the
            duration release of a session, where lock immediately, it doesn't
          help much.  Granted, an administrator can release the lock for
          you, but this could become a session is defined as significant burden for large sites.
          Further, what if the
            time when administrator can't be reached immediately?

          Despite their potential problems, exclusive write locks are
          extremely useful, since often a guarantee of freedom from
          overwrite conflicts is exactly what is needed.  The solution:
          provide exclusive write locks, but also provide a less strict
          mechanism in the HTTP connection that was form of shared locks which can be used by a set
          of people who trust each other and who have access to take out the
            lock remains connected. This mechanism is used a
          communications channel external to allow
            programs HTTP which are likely to can be improperly exited, such as
            JAVA programs running used to
          negotiate writing to the resource.

          5.1.2     Required Support

          A DAV compliant server is not required to support locking in a browser, any
          form. If the server does support locking it may choose to take out locks
            without leaving a lot support
          any combination of ownerless exclusive and shared locks around when for any access
          types.

          The reason for this flexibility is that server implementers have
          said that they are improperly exited.

            5.2.10.3  Syntax

            TimeOut = "Time-Out" ":" ((TimeOutType SP Session) |
            TimeOutVal |
                      Session) CRLF
            TimeOutType = ClockType SP TimeType
            ClockType = “ClockType” “=” ClockTypeValue
            ClockTypeValue = “Activity”
            TimeType = “TimeType” “=” TimeTypeValue
            TimeTypeValue = “Second” “;” DAVTimeOutVal
            DAVTimeOutVal = 1*digit
            Session = “Session” “=” (“Yes” | “No”)

            The “Second” TimeType specifies willing to accept minimum requirements on all
          services but locking. Locking policy strikes to the number very heart of seconds
          their resource management and versioning systems and they require
          control over what sort of locking will be made available. For
          example, some systems only support shared write locks while
          others only provide support for exclusive write locks. As each
          system is sufficiently different to merit exclusion of certain
          locking features, the authors are proposing that
            may elapse before locking be
          allowed as the sole axis of negotiation within DAV.

          5.2  LOCK Method

          5.2.1     Operation

          A lock method invocation creates the lock is automatically removed. specified by the Lock-
          Info header on the request-URI. Lock method requests SHOULD NOT
          have a request body. A
            server user-agent SHOULD submit an Owner header
          field with a lock request.

          A successful response to a lock invocation MUST not generate include a time out value for “second”
            greater than 2^32-1. Lock-
          Token header. If no the server supports a time based system is in use then lock removal
          mechanism on the resource, a Time-Out header
            MUST NOT be returned. The Time-Out header MUST only be
            returned in successful lock invocation SHOULD
          return a response to Time-Out header.

          5.2.2     Effect of Locks on Properties and Containers

          By default a LOCK request.When session lock affects the entire state of the resource,
          including its associated properties. As such it is set illegal to yes then whatever clocktype and timetype is being used,
            their effects are scoped within that particular session. So
            an absolute
          specify a lock with on a ten day expiration period will only
            remain active so long as the session remains active. A
            DAVTimeOutVal value must be greater than zero.

            Clients MAY include TimeOut headers in their LOCK requests.
            However property. For containers, a lock also affects
          the server is not required ability to honor add or even consider remove members. The nature of the request. effect
          depends upon the type of access control involved.  The primary purpose in allowing clients to
            submit a TimeOut Depth
          header is to inform the server if expresses the
            client is requesting general semantics of a session based lock. If LOCK method request
          when invoked on a timeout is
            associated with collection (note that specific lock types may
          restrict the effect of a lock, for example limiting the server MUST return a TimeOut allowable
          values of the Depth header):
          ·    A Depth header with a valid value.

            5.2.11    State-Token Header

            5.2.11.1  Problem Definition

            Program A, (defined in the namespace draft) may be used by User A, takes out a write lock
            on a
            resource. Program B, also run by User A, then proceeds LOCK method when the LOCK method is applied to
            perform a PUT to the locked
          collection
            resource. The PUT will succeed
            because locks are associated with a principal, not legal values for Depth on a
            program, LOCK are 0, 1, and thus program B, because it is acting with
            principal A’s credential, will be allowed
            Infinity. A Depth of 0 instructs the resource to perform just lock the
            PUT. In reality program B had no knowledge
            container. As previously mentioned, depending on the type of
            lock, the lock and
            had it had such knowledge, would not have overwritten affects the
            resource. Hence, a mechanism is needed ability to prevent different
            programs from accidentally ignoring locks taken out by other
            programs with add or remove members of
            the same authorization.

            5.2.11.2  Solution Requirement

            The solution must not require principals to perform
            discovery in order to prevent accidental overwrites as this
            could cause race conditions.

            The solution must not require container.
          ·    A Depth of 1 means that clients guess what sorts the container is locked and a LOCK
            is executed on the container’s propagate members with a Depth
          of locks might be used
            0 and use if-state-match If-Range, If-Modified-Since, If-Unmodified-Since, If-
          Match
            and If-None-Match headers with
            wildcards to prevent collisions. The problem with trying to
            “guess” which locks are being used is that new lock types
            might be introduced, and dropped. However, the program would not know to
            “guess them”. So, for example, a client might put effects of
            the LOCK MUST be atomic in an if-
            state-match header with a wildcard specifying that if any
            write either the container and all of
            its members are locked or no lock is outstanding then the operation should fail.
            However a new read/write lock could be introduced which the
            client would not know to put in the header.

            5.2.11.3  State-Token Header granted. The State-Token header is returned in result of a successful response
            to the LOCK method or
            Depth 1 lock is used as a request header with the
            UNLOCK method.

            The State-Token header containing a single lock token owned by the
            request principal is used by which represents the principal lock
          on arbitrary
            method to indicate that
            the principal is aware container and all of the
            specified lock. If the State-Token header with the
            appropriate its members. This lock token is not included the request MUST may be
            rejected, even though the requesting principal has
            authorization to make modifications specified by
          used
            in an If-State-Match or If-Not-State-Match header against any
          of
            the lock
            type. This injunction does not apply to methods that are not
            affected resources covered by the principal’s lock.

            For example, Program A, used by user A, takes out a write Since the lock on a resource. Program A then makes token
            represents a number of PUT
            requests lock on the locked resource, all the requests contain a
            State-Token header which includes resources, an UNLOCK using that
            token will remove the write lock state
            token. Program B, also run by User A, then proceeds to
            perform a PUT to from all included resources, not

          just
            the locked resource. However program B resource the UNLOCK was
            not aware executed on.
          ·    A Depth of infinity means that the existence LOCK is recursively
          executed, with a Depth of infinity, on the lock collection and so does not
            include the appropriate state-token header. The method is
            rejected even though principal A is authorized to perform
            the PUT. Program B can, if it so chooses, now perform lock
            discovery all of
          its propagate members and obtain all of their propagate members. As with
          a Depth of 1, the lock token. Note that program A and
            B can perform GETs without using LOCK must be granted in total or not at all.
          Otherwise the state-token header
            because lock operates in the ability to perform a GET is not affected by same manner as a
            write Depth of 1
          lock.

            Note that having

          The default behavior when locking a lock state token provides no special
            access rights. Anyone can find out anyone else’s lock state
            token by performing lock discovery. Locks are to be enforced
            based upon whatever authentication mechanism container is used by the
            server, not based to act as if a
          "Depth: 0" header had been placed on the secrecy of the token values.

            5.3 Write Lock
            A write lock prevents method.

          5.2.3     Locking Replicated Resources

          Some servers automatically replicate resources across multiple
          URLs. In such a principal without circumstance the lock from
            successfully executing server MAY only accept a PUT, POST, DELETE, MKCOL,
            PROPPATCH, PATCH, ADDREF or DELREF lock on
          one of the locked resource.
            All URLs if the server can guarantee that the lock will be
          honored across all the URLs.

          5.2.4     Interaction with other Methods

          Only two methods, GET in particular, function independent
            of the lock.

            While those without MOVE and DELETE, have side effects which
          involve locks. When a write resource is moved, its lock SHOULD be moved
          with it. However this may not alter a property on
            a resource it is still always be possible for the values of live
            properties to change, even while locked, due to the
            requirements of their schemas. Only dead properties and live
            properties defined to respect locks are guaranteed to not
            change while locked.

            It there is possible
          currently no proposal to assert create a write header which would specify that
          the lock request should fail if the resource’s locks can not be
          maintained. A COPY MUST NOT copy any locks on a null the source resource in
            order
          over to lock the name. Please note, however, that locking destination resource. Deleting a
            null resource effectively makes MUST remove
          all locks on the resource non-null as resource.

          5.2.5     Lock Compatibility Table

          The table below describes the
            resource now has behavior that occurs when a lock related properties defined
          request is made on it.

            Write locking a container also prevents adding or removing
            members of the container. This means that attempts to
            PUT/POST a resource into the immediate name space of the
            write locked container resource.

          Current lock state/      Shared Lock       Exclusive Lock
          Lock request
          None                     True              True
          Shared Lock              True              False
          Exclusive Lock           False             False*

          Legend: True = lock MAY be granted.  False = lock MUST fail if NOT be
          granted.  *=if the principal requesting the action does not have the write lock on is the container. In
            order to keep owner of
          the behavior lock, the lock MAY be regranted.

          The current lock state of locking containers consistent
            all locks on containers MUST contain a Depth header equal to
            infinity, any other value is illegal.

            5.4 Lock Tokens

            5.4.1     Problem Description

            It resource is possible that once a lock has been granted it may be
            removed without given in the leftmost
          column, and lock owner’s knowledge. This can cause
            serialization problems if the lock owner executes methods
            thinking their lock is still requests are listed in effect. Thus a mechanism is
            needed for a principal to predicate the successful execution
            of a message upon the continuing existence of a lock.

            5.4.2     Proposed Solution first row.  The proposed solution is to provide
          intersection of a lock token in row and column gives the
            response result of a lock
          request. The  For example, if a shared lock token is held on a type of
            state token resource,
          and describes a particular lock. The same an exclusive lock is requested, the table entry is "false",
          indicating the lock
            token must never not be repeated on a particular resource. This
            prevents problems with long held outstanding granted.

          If an exclusive lock tokens
            being confused with newer tokens. This uniqueness
            requirement is re-requested by the same as for e-tags. This requirement also
            allows for tokens to principal who owns
          the lock, the lock MAY be submitted across resources and
            servers without fear of confusion.

            5.4.3     Lock Token Definition

            The regranted. If the lock token is returned in the State-Token header in regranted,
          the
            response to a LOCK method. The same lock token can also that was previously issued MUST be
            discovered through lock discovery returned.

          5.2.6     Status Codes

          412 "Precondition Failed" - The included state-token was not
          enforceable on a this resource.

            Lock-Token-URL = “StateToken:” Type “:” Resources “:” State-
            Info
            Type = “Type” “=” “^DAV:/LOCK/DAVLOCK^”

            Resources = “Res” “=” 1*(“^” Caret-Encoded-URI “^”)
            Caret-Encoded-URI = <This is a URI which has all “^”s %
            encoded.>
            State-Info = DAVLockScope “:” DAVLockType “:” ServerID  ;
            DAVLockScope, DAVLockType defined in Lock-Info header
            ServerID = “ServerID” “=” *(uchar | reserved)

          416 "Locked" - The ServerID resource is a field for use by locked so the server. Its most
            basic purpose is to put in a unique identifier to guarantee
            that a server will never confuse an old lock token with a
            newer one. However the server is free to use the field to
            record whatever information it deems fit. The field is
            opaque to clients.

            5.5 UNLOCK Method

            5.5.1     Problem Definition

            The UNLOCK method removes the lock identified by the lock
            token in the State-Token header from the Request-URI.

            5.5.2 has been
          rejected.

          5.2.7     Example

            UNLOCK

          LOCK /workspace/webdav/proposal.doc HTTP/1.1
          Host: webdav.sb.aol.com
            State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http:/
            /www.ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Wri
            te:LockScope=Exclusive:ServerID=12382349AdfFFF
          Lock-Info: LockType=Write LockScope=Exclusive
          Owner: <http://www.ics.uci.edu/~ejw/contact.html>

          HTTP/1.1 200 OK

            In this example,
          State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http://www.
          ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Write:LockSco
          pe=Exclusive:ServerID=12382349AdfFFF
          Time-Out: ClockType=Activity TimeType=second;604800
          This example shows the successful creation of an exclusive write
          lock from example on resource
          http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The
          resource http://www.ics.uci.edu/~ejw/contact.html contains
          contact information for the owner of Section 2.9 is
            removed from the resource at
            http://webdav.sb.aol.com/workspace/webdav/proposal.doc

            5.6 Discovery Mechanisms

            5.6.1     Lock Type Discovery

            5.6.1.1   Problem Definition

            Since lock. The server has an
          activity-based timeout policy in place on this resource, which
          causes the lock support is optional, a client trying to
            lock a resource on automatically be removed after 1 week (604800
          seconds). The response has a server can either try Lock-Token header that gives the lock and hope
          state token URL for the best or can perform some form of discovery to
            determine what lock types token generated by this lock
          request.

          5.2.8     Lock-Info Request Header

          The Lock-Info header specifies the server actually supports, then
            formulate scope and type of a supported lock for a
          LOCK method request.  This The syntax specification below is known as lock type
            discovery. Lock
          extensible, allowing new type discovery is not the same as
            discovering what access control types are supported, as
            there may and scope identifiers to be access control types without corresponding lock
            types.

            5.6.1.2   SupportedLock Property

            Name: http://www.ietf.org/standards/dav/lock/supportedlock

            Purpose: To provide a listing of the lock types supported by added.
          LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope CRLF
          DAVLockType = "LockType" "=" DAVLockTypeValue
          DAVLockTypeValue = ("Write" | *(uchar | reserved))
          DAVLockScope = "LockScope" "=" DAVLockScopeValue
          DAVLockScopeValue = ("Exclusive" |"Shared" | *(uchar | reserved))

          5.2.9     Owner Request Header

          5.2.9.1   Problem Description

          When discovering the resource.

            Schema: http://www.ietf.org/standards/dav/

            Values: An XML document containing zero or more LockEntry
            XML elements.

            Description: The SupportedLock property list of owners of locks on a resource

            returns resource, a listing of the combinations of scope and access
            types which
          principal may want to be specified in a able to contact the owner directly. For
          this to be possible the lock request on discovery mechanism must provide
          enough information for the
            resource. Note lock owner to be contacted.

          5.2.9.2   Solution Requirements

          Not all systems have authentication procedures that the actual contents are themselves
            controlled by access controls so provide
          sufficient information to identify a server particular user in a way
          that is meaningful to a human. In addition, many systems that do
          have sufficient information, such as a name and e-mail address,
          do not required have the ability to
            provide associate this information with the client
          lock discovery mechanism. Therefore a means is not authorized needed to see. If
            SupportedLock is available on “*” then it MUST define the
            set of locks allowed on all resources on that server.

            5.6.1.3   LOCKENTRY XML Element

            Name: http://www.ietf.org/standards/dav/lockentry

            Purpose: Defines allow
          principals to provide authentication in a DAVLockType/LockScope pair manner which may will be
            legally used with
          meaningful to a LOCK on the specified resource.

            Schema: HYPERLINK http://www.ietf.org/standards/dav/

            Parent: A SupportedLock entry

            Values: LockType LockScope

            5.6.1.4   LOCKTYPE XML Element

            Name: http://www.ietf.org/standards/dav/locktype

            Purpose: Lists a DAVLockType

            Schema: http://www.ietf.org/standards/dav/

            Parent: LOCKENTRY

            Values: DAVLockTypeValue

            5.6.1.5   LOCKSCOPE XML Element

            Name: http://www.ietf.org/standards/dav/lockscope

            Purpose: Lists a DAVLockScope

            Schema: http://www.ietf.org/standards/dav/

            Parent: LOCKENTRY

            Values: DAVLockScopeValue

            5.6.2     Active Lock Discovery

            5.6.2.1   Problem Definition

            If another principal locks a resource that a principal
            wishes to access, it human.

          The From header (defined in RFC 2068), which contains only an
          email mailbox, is useful not sufficient for the second principal to
            be able purposes of quick

          identification. When desperately looking for someone to find out who the first principal is.

            5.6.2.2   Solution Requirements

            The lock discovery mechanism should provide remove a list of who
            has
          lock, e-mail is often not sufficient. A telephone number (cell
          number, pager number, etc.) would be better. Furthermore, the resource locked, what locks they have, and what
            their lock tokens are. The lock tokens are useful in shared
            lock situations where two principals
          email address in particular the From field may or may want
            to guarantee that they do not overwrite each other. The lock
            tokens are also useful for administrative purposes so support including
          the owners name and that
            an administrator can remove a lock by referring name is often set to its
            token.

            5.6.2.3   LOCKDISCOVERY Property

            Name: http://www.ietf.org/standards/dav/lockdiscovery

            Purpose: To discover what locks are active on an alias anyway.
          Therefore a resource

            Schema: http://www.ietf.org/standards/dav/

            Values= An XML document containing zero or header more ActiveLock
            XML elements.

            Description: flexible than From is required.

          5.2.9.3   Syntax

          Owner = "Owner" ":" (("<" URI ">")  | quoted-string)
          The LOCKDISCOVERY property returns URI SHOULD provide a listing of
            who has means for either directly contacting the
          principal (such as a lock, what type telephone number or e-mail URI), or for
          discovering the principal (such as  the URL of lock they have, a homepage).  The
          quoted string SHOULD provide a means for directly contacting the time
          principal, such as a name and telephone number.

          5.2.10    Time-Out Header

          5.2.10.1  Problem Description

          In a perfect world principals take out
            type locks, use the resource as
          needed, and then remove the time remaining on lock when it is no longer needed.
          However, this scenario is frequently not completed, leaving
          active but unused locks. Reasons for this include client programs
          crashing and loosing information about locks, users leaving their
          systems for the time out, day and forgetting to remove their locks, etc. As
          a result of this behavior, servers need to establish a policy by
          which they can remove a lock without input from the
            associated lock token. The server owner.
          Once such a policy is free instituted, the server also needs a
          mechanism to withhold any or
            all inform the principal of this information if the requesting policy.

          5.2.10.2  Solution Requirements

          There are two basic lock removal policies, administrator and time
          based remove. In the first case a principal does not
            have other than the lock
          owner has sufficient access rights to see order the requested data.

            5.6.2.4   ACTIVELOCK XML Element

            Name: http://www.ietf.org/standards/dav/activelock

            Purpose: A multivalued XML element lock removed,
          even though they did not take it out. User-agents MUST assume
          that describes such a
            particular active lock on mechanism is available and thus locks may arbitrarily
          disappear at any time. If their actions require confirmation of
          the existence of a resource

            Schema: http://www.ietf.org/standards/dav/

            Parent: A LOCKDISCOVERY entry

            Values= LOCKTYPE LOCKSCOPE OWNER TIMEOUT LOCKTOKEN

            5.6.2.5   OWNER XML Element

            Name: http://www.ietf.org/standards/dav/lock/owner

            Purpose: Returns owner information

            Schema: http://www.ietf.org/standards/dav/

            Parent: ACTIVELOCK

            Values= XML:REF | {any valid XML string}

            5.6.2.6   TIMEOUT XML Element

            Name: http://www.ietf.org/standards/dav/timeout

            Purpose: Returns information about lock then the timeout associated
            with If-State headers are available.

          The second solution, is the time based removal policy. Activity
          based systems set a timer as soon as the lock

            Schema: http://www.ietf.org/standards/dav/

            Parent: ACTIVELOCK

            Values= CLOCKTYPE TIMETYPE TIMEOUTVAL

            5.6.2.7   CLOCKTYPE XML Element

            Name: http://www.ietf.org/standards/dav/clocktype

            Purpose: Returns is taken out. Every
          time a method is executed on the resource, the timer is reset. If
          the timer runs out, the clock type used with this lock

            Schema: http://www.ietf.org/standards/dav/

            Parent: TIMEOUT

            Values=  ClockTypeValue

            5.6.2.8   TIMETYPE XML Element

            Name: http://www.ietf.org/standards/dav/clocktype

            Purpose: Returns is removed.

          Finally, some systems only allow locks to exist for the duration
          of a session, where a session is defined as the time type when the
          HTTP connection that was used with this to take out the lock

            Schema: http://www.ietf.org/standards/dav/

            Parent: TIMEOUT

            Values= remains
          connected. This mechanism is used to allow programs which are
          likely to be improperly exited, such as JAVA programs running in
          a browser, to take out locks without leaving a lot of ownerless
          locks around when they are improperly exited.

          5.2.10.3  Syntax

          TimeOut = "Time-Out" ":" ((TimeOutType SP Session) | TimeOutVal |
                    Session) CRLF
          TimeOutType = ClockType SP TimeType
          ClockType = "ClockType" "=" ClockTypeValue

          ClockTypeValue = "Activity"
          TimeType = "TimeType" "=" TimeTypeValue

            5.6.2.9   TIMEOUTVAL XML Element

            Name: http://www.ietf.org/standards/dav/timeoutval

            Purpose: Returns
          TimeTypeValue = "Second" ";" DAVTimeOutVal
          DAVTimeOutVal = 1*digit
          Session = "Session" "=" ("Yes" | "No")

          The "Second" TimeType specifies the amount number of time left on seconds that may
          elapse before the lock

            Schema: http://www.ietf.org/standards/dav/

            Parent: TIMEOUT

            Values= is automatically removed. A server MUST
          not generate a time out value for "second" greater than 2^32-1.

          If no time based system is in use then a Time-Out header MUST NOT
          be returned. The Time-Out header MUST only be returned in a
          response to a LOCK request.When session is set to yes then
          whatever clocktype and timetype is being used, their effects are
          scoped within that particular session. So an absolute lock with a
          ten day expiration period will only remain active so long as the
          session remains active. A DAVTimeOutVal

            5.6.2.10  LOCKTOKEN XML Element

            Name: http://www.ietf.org/standards/dav/statetoken

            Purpose: Returns value must be greater
          than zero.

          Clients MAY include TimeOut headers in their LOCK requests.
          However the server is not required to honor or even consider the
          request. The primary purpose in allowing clients to submit a
          TimeOut header is to inform the server if the client is
          requesting a session based lock. If a timeout is associated with
          the lock, the server MUST return a TimeOut header with a valid
          value.

          5.2.11    State-Token Header

          5.2.11.1  Problem Definition

          Program A, used by User A, takes out a write lock token

            Schema: http://www.ietf.org/standards/dav/

            Parent: ACTIVELOCK

            Values= XML:REF

            Description: on a resource.
          Program B, also run by User A, then proceeds to perform a PUT to
          the locked resource. The REF contains PUT will succeed because locks are
          associated with a Lock-Token-URL.

            6  Version Control
            [TBD]

            7  Internationalization Support
            [TBD]

            8  Security Considerations
            [TBD]

            9  Acknowledgements
            Roy Fielding, Richard Taylor, Larry Masinter, Henry Sanders,
            Judith Slein, Dan Connolly, David Durand, Henrik Nielsen,
            Paul Leach. Kenji Ota, Kenji Takahashi. Jim Cunningham.
            Others, TBD.

            10 References
            [Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
            Unpublished white paper, January 1997.
            http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.

            [Bray, 1997] T. Bray, C. M. Sperberg-McQueen, “Extensible
            Markup Language (XML): Part I. Syntax”, WD-xml-lang.html,
            http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.

            [Connolly, 1997] D. Connolly, R. Khare, H.F. Nielsen, “PEP -
            an Extension Mechanism for HTTP”, Internet draft, work-in-
            progress. draft-ietf-http-pep-03.txt,
            ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-
            03.txt.

            [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
            Bibliographic Records," RFC 1807. Stanford, Myricom. June,
            1995.

            [Maloney, 1996] M. Maloney, "Hypertext Links in HTML."
            Internet draft (expired), work-in-progress, January, 1996.

            [MARC, 1994] Network Development principal, not a program, and MARC Standards, Office,
            ed. 1994. "USMARC Format for Bibliographic Data", 1994.
            Washington, DC: Cataloging Distribution Service, Library thus program B,
          because it is acting with principal A’s credential, will be
          allowed to perform the PUT. In reality program B had no knowledge
          of
            Congress.

            [Miller et.al., 1996] J. Miller, T. Krauskopf, P. Resnick,
            W. Treese, "PICS Label Distribution Label Syntax the lock and
            Communication Protocols" Version 1.1, W3C Recommendation
            REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-
            PICS-labels-961031.html.

            [WebDAV, 1997] WEBDAV Design Team. “A Proposal for Web
            Metadata Operations.” Unpublished manuscript.
            http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.htm
            l

            [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R.
            Daniel, "OCLC/NCSA Metadata Workshop Report."
            http://purl.oclc.org/metadata/dublin_core_report.

            [Yergeau, 1997] F. Yergeau, “UTF-8, had it had such knowledge, would not have
          overwritten the resource. Hence, a transformation format mechanism is needed to prevent
          different programs from accidentally ignoring locks taken out by
          other programs with the same authorization.

          5.2.11.2  Solution Requirement

          The solution must not require principals to perform discovery in
          order to prevent accidental overwrites as this could cause race
          conditions.

          The solution must not require that clients guess what sorts of Unicode
          locks might be used and ISO 10646”, Internet Draft, work-in-progress,
            draft-yergeau-utf8-rev-00.txt,
            http://www.internic.net/internet-drafts/draft-yergeau-utf8-
            rev-00.txt.

            11 Authors' Addresses
            Yaron Y. Goland
            Microsoft Corporation
            One Microsoft Way
            Redmond, WA 98052-6399
            Email yarong@microsoft.com

            E. J. Whitehead, Jr.
            Dept. Of Information use if-state-match headers with wildcards
          to prevent collisions. The problem with trying to "guess" which
          locks are being used is that new lock types might be introduced,
          and Computer Science
            University the program would not know to "guess them". So, for example,
          a client might put in an if-state-match header with a wildcard
          specifying that if any write lock is outstanding then the
          operation should fail. However a new read/write lock could be
          introduced which the client would not know to put in the header.

          5.2.11.3  State-Token Header

          The State-Token header is returned in a successful response to

          the LOCK method or is used as a request header with the UNLOCK
          method.

          The State-Token header containing a lock token owned by the
          request principal is used by the principal on arbitrary method to
          indicate that the principal is aware of California, Irvine
            Irvine, CA 92697-3425
            Email: ejw@ics.uci.edu

            Asad Faizi
            Netscape
            685 East Middlefield Road
            Mountain View, CA 94043
            Email: asad@netscape.com

            Stephen R Carter
            Novell
            1555 N. Technology Way
            M/S ORM F111
            Orem, UT 84097-2399
            Fax (801) 228 5176
            Email srcarter@novell.com

            Del Jensen
            Novell
            1555 N. Technology Way
            M/S ORM F111
            Orem, UT 84097-2399
            Fax (801) 228 5176
            Email dcjensen@novell.com

            Appendix 1 - Content Type Application/XML the specified lock. If
          the State-Token header with the appropriate lock token is not
          included the request MUST be rejected, even though the requesting
          principal has authorization to make modifications specified by
          the lock type. This injunction does not apply to methods that are
          not affected by the principal’s lock.

          For example, Program A, used by user A, takes out a write lock on
          a resource. Program A then makes a number of PUT requests on the
          locked resource, all the requests contain a State-Token header
          which includes the write lock state token. Program B, also run by
          User A, then proceeds to perform a PUT to the locked resource.
          However program B was not aware of the existence of the lock and
          so does not include the appropriate state-token header. The
          method is rejected even though principal A is authorized to
          perform the PUT. Program B can, if it so chooses, now perform
          lock discovery and obtain the lock token. Note that program A and
          B can perform GETs without using the state-token header because
          the ability to perform a GET is not affected by a write lock.

          Note that having a lock state token provides no special access
          rights. Anyone can find out anyone else’s lock state token by
          performing lock discovery. Locks are to be enforced based upon
          whatever authentication mechanism is used by the server, not
          based on the secrecy of the token values.

          5.3  Write Lock

          A write lock prevents a principal without the lock from
          successfully executing a digest PUT, POST, DELETE, MKCOL, PROPPATCH,
          PATCH, ADDREF or DELREF on the locked resource. All other
          methods, GET in particular, function independent of the XML data specification available at
            http://www.w3.org/TR/WD-xml-lang.html

            Syntax
            The application/XML content type contains an XML document.
            Its syntax lock.

          While those without a write lock may not alter a property on a
          resource it is as defined below.

            XML = XMLStart *XMLEntity Close

            XMLStart = “<” “XML” “>”

            XMLEntity= Open *(XMLText | XMLEntity) Close

            Close = “</>” | “<”“/”Entity-Name Markup“>”

            Open = “<” Entity-Name *Attribute “>”

            Attribute = Entity-Name “=” Quoted-String

            XMLText = <An Octet Stream which uses XML encoding still possible for “<” the values of live properties
          to change, even while locked, due to the requirements of their
          schemas. Only dead properties and “>”>

            Entity-Name = ([As-Tag “:”] Name) | (As-Tag “:”)

            As-Tag = 1*Alpha

            Name = (alpha | “_”) *(alpha | digit | “.” | “-“ | “_” |
            other)

            Other = <Other characters must be encoded>

            XML element
            An XML element, as live properties defined to
          respect locks are guaranteed to not change while locked.

          It is possible to assert a write lock on a null resource in order
          to lock the BNF, is an open tag with
            content followed by name. Please note, however, that locking a close tag. null
          resource effectively makes the resource non-null as the resource
          now has lock related properties defined on it.

          Write locking a container also prevents adding or removing
          members of the container. This means that attempts to PUT/POST a
          resource into the immediate name space of the write locked
          container MUST fail if the principal requesting the action does
          not have the write lock on the container. In order to prevent
            confusion with the term entity as used in HTTP, keep the term XML
            element will be used.

            The first XML element
          behavior of a XML document locking containers consistent all locks on containers
          MUST be the <XML>
            XML element. This XML element tells the parser that it contain a Depth header equal to infinity, any other value is
            dealing with an XML document. So long as this XML element
          illegal.

          5.4  Lock Tokens

          5.4.1     Problem Description

          It is
            present the parser can be sure possible that it can parse the
            document, even if XML once a lock has been extended. If XML is ever
            altered in a manner that is not backwards compatible with
            this specification then the content-type and the outer most
            XML element MUST be changed.

            Entity-Name
            All XML element names must map to URIs. However due to
            historical restrictions on what characters granted it may appear in an
            XML element name, URIs cannot be expressed in an XML element
            name. This issue is dealt with in more detail in section 10.

            Entity-Names

          removed without [AS] are relative URIs whose base is the enclosing Entity-Name. If lock owner’s knowledge. This can cause
          serialization problems if the enclosing Entity-Name lock owner executes methods
          thinking their lock is
            <XML> then the Entity-Name MUST use an [AS].

            Close
            The close production marks the end of a XML element.

            XML Encoding
            In different contexts certain characters are reserved, for
            example “/” can not be used in an XML element name and
            “>”/”<” can not be used still in effect. Thus a value. As such these values
            must be encoded as follows:

            Encoding = Decimal | Hex4

            Decimal = “&” Non-Zero *(“0” | Non-Zero)

            Hex4 = “&u-“ 4(Hex)

            Non-Zero = “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” |
            “9”

            Hex = “0” | Non-Zero | “A” | “B” | “C” | “D” | “E” | “F”

            The numbers MUST map mechanism is
          needed for a principal to predicate the UTF8 character encodings. Please
            note that the “&” character must always be encoded.

            Markup Modifier
            The markup modifier, (“-”, after the end successful execution of an XML element)
            instructs a
          message upon the principal how continuing existence of a lock.

          5.4.2     Proposed Solution

          The proposed solution is to treat provide a XML element with an
            unknown name. If lock token in the modifier response
          of a lock request. The lock token is used a type of state token and the XML element
          describes a particular lock. The same lock token must never be
          repeated on a particular resource. This prevents problems with
          long held outstanding lock tokens being confused with newer
          tokens. This uniqueness requirement is
            not recognized then the XML element name MUST same as for e-tags.
          This requirement also allows for tokens to be stripped submitted across
          resources and the XML element’s contents promoted one level servers without fear of confusion.

          5.4.3     Lock Token Definition

          The lock token is returned in the
            parse tree. If State-Token header in the modifier
          response to a LOCK method. The lock token can also be discovered
          through lock discovery on a resource.
          Lock-Token-URL = "StateToken:" Type ":" Resources ":" State-Info
          Type = "Type" "=" "^DAV:/LOCK/DAVLOCK^"
          Resources = "Res" "=" 1*("^" Caret-Encoded-URI "^")
          Caret-Encoded-URI = <This is not used and a URI which has all "^"s % encoded.>
          State-Info = DAVLockScope ":" DAVLockType ":" ServerID  ;
          DAVLockScope, DAVLockType defined in Lock-Info header
          ServerID = "ServerID" "=" *(uchar | reserved)

          The ServerID is a field for use by the XML element
            name server. Its most basic
          purpose is unknown then to put in a unique identifier to guarantee that a
          server will never confuse an old lock token with a newer one.
          However the XML element and its contents MUST
            be ignored.

            XML Syntax Shorthand server is free to use the field to record whatever
          information it deems fit. The following template field is recommended for efficiently
            providing a description of an XML element.

            Name: opaque to clients.

          5.5  UNLOCK Method

          5.5.1     Problem Definition

          The name of UNLOCK method removes the XML element

            Purpose: A one line description of lock identified by the XML element’s
            purpose.

            Schema: The schema, if any, that lock token
          in the XML element belongs to

            Parent: XML elements that this XML element may be a child
            of.

            Values: A description, usually a BNF, of State-Token header from the simple and
            compound values that Request-URI.

          5.5.2     Example

          UNLOCK /workspace/webdav/proposal.doc HTTP/1.1
          Host: webdav.sb.aol.com
          State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http://www.
          ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Write:LockSco
          pe=Exclusive:ServerID=12382349AdfFFF

          HTTP/1.1 200 OK

          In this example, the XML element supports.

            Description: Further information.

            Example: An lock from example of Section 2.9 is removed
          from the XML element’s use.

            Appendix 2 - Parameter Syntax for Content-Type
            Application/XML
            HTTP 1.1 provides for resource at
          http://webdav.sb.aol.com/workspace/webdav/proposal.doc

          5.6  Discovery Mechanisms

          5.6.1     Lock Type Discovery

          5.6.1.1   Problem Definition

          Since server lock support is optional, a mechanism client trying to include lock a parameter
            with
          resource on a content type. In order to prevent namespace
            collisions server can either try the parameters lock and hope for application/XML must use the
            following syntax:

            Parameter = #(<”>URI<”>  [“=” (token | Quoted-String)])

            Schema Content-Type Parameter
            Parameter = <”> http://www.w3.org/standards/xml/content-
            type/schema <”> “=” <”> #URI <”>

            The http://www.w3.org/standards/xml/content-type/schema/ URL
            is used as a parameter to an application/xml content type.
            The URL indicates that its value lists
          best or can perform some subset form of discovery to determine what lock
          types the
            schemas defined in NameSpace parameters within server actually supports, then formulate a supported
          request.  This is known as lock type discovery. Lock type
          discovery is not the enclosed
            document. The URI can also same as discovering what access control
          types are supported, as there may be used in requests to indicate
            schemas that should appear in access control types without
          corresponding lock types.

          5.6.1.2   SupportedLock Property

          Name: http://www.ietf.org/standards/dav/lock/supportedlock
          Purpose: To provide a listing of the result. lock types supported by the
          resource.
          Schema: http://www.ietf.org/standards/dav/
          Values: An example XML document containing zero or more LockEntry XML
          elements.
          Description: The SupportedLock property of a resource returns a
          listing of the use combinations of this parameter is to include it scope and access types which may
          be specified in
            an accept-type header on a lock request to indicate that on the
            response should contain resource. Note that the specified namespace. Thus
          actual contents are themselves controlled by access controls so a
          server is not required to provide information the client is able not
          authorized to inform see. If SupportedLock is available on "*" then it
          MUST define the server of its support for a
            particular set of namespaces. The server is not required to
            return locks allowed on all resources on that
          server.

          5.6.1.3   LOCKENTRY XML Element

          Name: http://www.ietf.org/standards/dav/lockentry
          Purpose: Defines a result DAVLockType/LockScope pair which may be
          legally used with a LOCK on the specified namespaces.

            Appendix 3 – URI Path Encoding resource.
          Schema: HYPERLINK http://www.ietf.org/standards/dav/
          Parent: A SupportedLock entry
          Values: LockType LockScope

          5.6.1.4   LOCKTYPE XML Element

          Name: http://www.ietf.org/standards/dav/locktype
          Purpose: Lists a DAVLockType
          Schema: http://www.ietf.org/standards/dav/
          Parent: LOCKENTRY
          Values: DAVLockTypeValue

          5.6.1.5   LOCKSCOPE XML Element

          Name: http://www.ietf.org/standards/dav/lockscope
          Purpose: Lists a DAVLockScope
          Schema: http://www.ietf.org/standards/dav/
          Parent: LOCKENTRY
          Values: DAVLockScopeValue

          5.6.2     Active Lock Discovery

          5.6.2.1   Problem Definition
            A mechanism

          If another principal locks a resource that a principal wishes to
          access, it is needed useful for the second principal to refer be able to specific DAV properties find
          out who the first principal is.

          5.6.2.2   Solution Requirements

          The lock discovery mechanism should provide a list of who has the
          resource locked, what locks they have, and what their lock tokens
          are. The lock tokens are useful in
            a manner shared lock situations where
          two principals in particular may want to guarantee that can handle simple, composite, and multivalued
            DAV properties.

            Solution Requirement they do
          not overwrite each other. The reference mechanism must use the standard URL syntax lock tokens are also useful for
          administrative purposes so
            it can be used with both currently existing and future URLs.
            For example, the syntax could be appended to that an HTTP URL to
            specify administrator can remove a HTTP property
          lock by referring to its token.

          5.6.2.3   LOCKDISCOVERY Property

          Name: http://www.ietf.org/standards/dav/lockdiscovery
          Purpose: To discover what locks are active on that URL.

            Path Component
            URIPath = “/” [segment]

            Segment = (“(“ Abs-URI “)” | Rel-URI)[Index]*( “;” param)

            Index = [“(“ [“-“]*digit “)”]

            Abs-URI = < a resource
          Schema: http://www.ietf.org/standards/dav/
          Values= An absolute XML document containing zero or relative URI which more ActiveLock XML
          elements.
          Description: The LOCKDISCOVERY property returns a listing of who
          has been URI-
            Path encoded >

            Rel-URI = < A relative URI for which URI-Encoding(Rel-URI)
            == Rel-URI >

            URI-Path encoding consists a lock, what type of lock they have, the following algorithm:

            URL encode all “!” characters

            Map all “/” characters to “!” characters

            Please note that all relative URIs are relative to the URI
            in the path segment preceding them. Hence the URI in the
            first path segment MUST be an absolute URI.

            The purpose of time out type and
          the encoding is to allow URLs to be used as
            segments without having to use % encoding time remaining on all the “/”
            which produces a URL form which is extremely difficult for
            humans to deal with, time out, and which changes the semantics of the
            URL.

            Appendix 4 - XML URI associated lock
          token. The “XML” scheme server is free to be registered with IANA as a reserved
            namespace that will be owned by withhold any or all of this
          information if the XML group through requesting principal does not have sufficient
          access rights to see the
            W3C.

            The new URI is defined as:

            XML = “XML” “:” XML-Path

            Appendix 5 - XML elements

            Ref requested data.

          5.6.2.4   ACTIVELOCK XML element Element

          Name: XML:Ref http://www.ietf.org/standards/dav/activelock
          Purpose: A multivalued XML element that indicates that its contents are describes a URI. particular
          active lock on a resource
          Schema: XML http://www.ietf.org/standards/dav/
          Parent: Any

            Value = URI

            Namespace

            Namespace A LOCKDISCOVERY entry
          Values= LOCKTYPE LOCKSCOPE OWNER TIMEOUT LOCKTOKEN

          5.6.2.5   OWNER XML element Element

          Name: XML:Namespace http://www.ietf.org/standards/dav/lock/owner
          Purpose: To inform the parser that a particular schema is in
            use and to provide a shorthand name for referring to XML
            elements related to that schema. Returns owner information
          Schema: XML http://www.ietf.org/standards/dav/
          Parent: Any

            Value = (Ref [AS])

            Description: This XML element contains two XML elements, Ref
            and AS. The purpose of the XML element is to inform the
            parser that a schema, identified by the value of the Ref XML
            element, is in use and, when appropriate, to provide a
            shorthand name to refer XML elements derived from that
            schema using the AS XML element. The AS mechanism is needed
            for efficiency reasons and because a URI can not be fully
            specified in an XML open tag. The Namespace ACTIVELOCK
          Values= XML:REF | {any valid XML element’s
            scope is all siblings and their children.

            AS string}

          5.6.2.6   TIMEOUT XML element Element

          Name: XML:AS http://www.ietf.org/standards/dav/timeout
          Purpose: To provide a short name for the URI of Returns information about the schema
            provided in timeout associated with
          the Ref XML entity of a namespace XML entity. lock
          Schema: XML http://www.ietf.org/standards/dav/
          Parent: XML:Namespace

            Value = 1*Alpha

            Description: The AS XML entity is used to provide a
            shorthand reference for the URI in the Ref XML entity of a
            Namespace ACTIVELOCK
          Values= CLOCKTYPE TIMETYPE TIMEOUTVAL

          5.6.2.7   CLOCKTYPE XML entity. The value contained in Element

          Name: http://www.ietf.org/standards/dav/clocktype
          Purpose: Returns the AS clock type used with this lock
          Schema: http://www.ietf.org/standards/dav/
          Parent: TIMEOUT
          Values=  ClockTypeValue

          5.6.2.8   TIMETYPE XML
            entity is generated at Element

          Name: http://www.ietf.org/standards/dav/clocktype
          Purpose: Returns the time type used with this lock
          Schema: http://www.ietf.org/standards/dav/
          Parent: TIMEOUT
          Values= TimeTypeValue

          5.6.2.9   TIMEOUTVAL XML producer’s discretion, the
            only requirement is that all AS values MUST be unique within
            the contents of Element

          Name: http://www.ietf.org/standards/dav/timeoutval
          Purpose: Returns the parent amount of time left on the namespace element.

            All lock
          Schema: http://www.ietf.org/standards/dav/
          Parent: TIMEOUT
          Values= DAVTimeOutVal

          5.6.2.10  LOCKTOKEN XML entity open tags contain a name of Element
          Name: http://www.ietf.org/standards/dav/statetoken
          Purpose: Returns the form As-
            Tag:Name. lock token
          Schema: http://www.ietf.org/standards/dav/
          Parent: ACTIVELOCK
          Values= XML:REF
          Description: The As-Tag is the value defined in an AS XML
            entity inside of a Namespace. To resolve the As-Tag:Name
            into a properly formatted URI replace “As-Tag:” with the URI
            provided in the Ref that the AS was defined with. Also note
            that AS value also applies to any URIs defined in REF contains a Ref
            inside Lock-Token-URL.

          6    Version Control
          [TBD]

          7    Internationalization Support
          [TBD]

          8    Security Considerations
          [TBD]

          9    Acknowledgements

          Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell,
          Bernard Chester, Dan Connolly, Jim Cunningham, Ron Daniel, Jr.,
          Keith Dawson, Mark Day, Martin Duerst, David Durand, Lee Farrell,
          Chuck Fay, Roy Fielding, Mark Fisher, Alan Freier, George
          Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton,
          Steve Henning, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul
          Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry
          Masinter, Michael Mealling, Keith Moore, Henrik Nielsen, Kenji
          Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry
          Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar
          Stefferud, Ralph Swick, Kenji Takahashi, Robert Thau, Sankar
          Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, Lauren Wood

          10   References

          [Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."

          Unpublished white paper, January 1997.
          http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.

          [Bray, Sperberg-McQueen, 1997] T. Bray, C. M. Sperberg-McQueen,
          "Extensible Markup Language (XML): Part I. Syntax", WD-xml-
          lang.html, http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.

          [Connolly et al, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP
          - an Extension Mechanism for HTTP", Internet draft, work-in-
          progress. draft-ietf-http-pep-04.txt,
          ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-04.txt.

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

          [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
          Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.

          [Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet
          draft (expired), work-in-progress, January, 1996.

          [MARC, 1994] Network Development and MARC Standards, Office, ed.
          1994. "USMARC Format for Bibliographic Data", 1994. Washington,
          DC: Cataloging Distribution Service, Library of Namespace.

            For example,

                 <XML>
                      <XML:Namespace><Ref>http://blah;DAV/</><AS>B</></>
                      <XML:Namespace><Ref>B:(B:)/</><AS>C</></>
                      <C:Moo></>
                 </>
            So B:(B:) translates to http://blah;DAV/(http:!!blah;DAV!)/ Congress.

          [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
          Treese, "PICS Label Distribution Label Syntax and C:Moo translates to
            http://blah;DAV/(http:!!blah;DAV!)/Moo.

            Required XML element

            Name: XML:Required

            Purpose: To indicate that the read MUST understand the
            associated Namespace in order to successfully process the
            XML document.

            Schema: XML

            Parent: XML:Namespace

            Value: None

            The XML URI Communication
          Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-
          961031. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.

          [Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead,
          Jr., D. Durand, "Requirements for Distributed Authoring and Namespace

            In order to prevent a logical loop the XML namespace is said
            to be declared, with
          Versioning on the AS value of “XML” as World Wide Web." Internet-draft, work-in-
          progress, draft-ietf-webdav-requirements-02.txt,
          ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-
          requirements-02.txt.

          [WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
          Operations." Unpublished manuscript.
          http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html

          [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
          "OCLC/NCSA Metadata Workshop Report."
          http://purl.oclc.org/metadata/dublin_core_report.

          [Yergeau, 1997] F. Yergeau, "UTF-8, a consequence transformation format of the <XML> enclosing property.
          Unicode and ISO 10646", Internet Draft, work-in-progress, draft-
          yergeau-utf8-rev-00.txt, http://www.internic.net/internet-
          drafts/draft-yergeau-utf8-rev-00.txt.

          11   Authors' Addresses

          Y. Y. Goland
          Microsoft Corporation
          One Microsoft Way
          Redmond, WA 98052-6399
          Email yarong@microsoft.com

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

          A. Faizi
          Netscape
          685 East Middlefield Road
          Mountain View, CA 94043
          Email: asad@netscape.com

          S. R Carter
          Novell
          1555 N. Technology Way
          M/S ORM F111
          Orem, UT 84097-2399
          Email srcarter@novell.com

          D. Jensen
          Novell
          1555 N. Technology Way
          M/S ORM F111
          Orem, UT 84097-2399
          Email dcjensen@novell.com