WEBDAV Working Group                     Y. Y.                            Y.Y. Goland, Microsoft
          INTERNET-DRAFT                 E. J.

INTERNET DRAFT                          E.J. Whitehead, Jr., U.C. UC Irvine
          <draft-ietf-webdav-protocol-04>
<draft-ietf-webdav-protocol-05>                     A. Faizi, Netscape
                                                       S. R
                                                   S.R. Carter, Novell
                                                     D. Jensen, Novell
Expires April 20, April, 1998                          October 12,                                  November 19, 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>. <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 document specifies a set of methods methods, headers, and content-types
   ancillary to HTTP/1.1 for the management of resource properties,
          simple name space
   creation and management of resource collections, namespace
   manipulation, simple resource locking (collision avoidance) avoidance), and efficient
   transmission of resource version control.

                                  Table changes.

Changes

1.1. Changes since draft-ietf-webdav-protocol-04.txt

   [Editor's note: This section will not appear in the final form of Contents
          Abstract
          1    Terminology
          2    Data Model and Methods
   this document.  Its purpose is to provide a concise list of changes
   from the previous revision of the draft for DAV Properties
               2.1  Introduction
                    2.1.1   The DAV Property
                    2.1.2   Existing Metadata Proposals
                    2.1.3   Properties and HTTP Headers
               2.2  A Property Model use by reviewers.]

   Added this change section.

   Removed scoping for HTTP Resources
                    2.2.1   Overview
                    2.2.2   Property Namespace
               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.4.1 namespaces so the namespace for
   every element is explicitly stated.

   Changed the syntax from <?XML:Namespace.../> to <?namespace...?>.

   Removed propfindresult, this was left over from the old search
   format.

   Changed all the DAV Property
                    2.4.2   Level XML Element
                    2.4.3   Prop XML element
                    2.4.4   PropLoc XML Attribute
                    2.4.5   Example
               2.5  Property Identifiers
                    2.5.1   Problem Definition
               2.6  Link XML Element
                    2.6.1   Problem Description
                    2.6.2   Solution Requirements
                    2.6.3   Link XML Element
                    2.6.4   Src XML Element
                    2.6.5   Dst XML Element
                    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 names to lower case.

   Changed the property format to use Name and Methods
                    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 Namespace rather than
   name and Name Space
               Operations
               3.1  Observations schema.

   Removed proploc attribute and removed section on GETting, DELETEing,
   and PUTing properties since we do not provide a mechanism for
   getting a URI for properties.  Also removed the requirement that
   properties be URI addressable.

   Removed quoted string choice from owner header, it is just XML.

   Made all the HTTP Object Model
                    3.1.1   Collection Resources
                    3.1.2   Creation and Retrieval error codes use the same format.

   Changed the name of Collection
                            Resources
                    3.1.3   Source Resources and Output Resources
               3.2  MKCOL Method
                    3.2.1   Problem Description
                    3.2.2   Solution Requirements
                    3.2.3   Request
                    3.2.4   Response
                    3.2.5   Example
               3.3  Standard DAV Properties
                    3.3.1   IsCollection Property
                    3.3.2   DisplayName Property
                    3.3.3   CreationDate Property
                    3.3.4   GETentity Property
                    3.3.5   INDEXentity Property
                    3.3.6   Content-Type XML Element
                    3.3.7   Content-Length XML Element
                    3.3.8   Content-Language XML Element
                    3.3.9   Last-Modified XML Element
                    3.3.10  Etag XML Element
               3.4  INDEX Method
                    3.4.1   Problem Description
                    3.4.2   Solution Requirements
                    3.4.3   The Request
                    3.4.4   The Response
                    3.4.5   ResInfo XML Element
                    3.4.6   Members XML Element
                    3.4.7   Href XML Element
                    3.4.8   Example
               3.5  Behavior of RFC 2068 Methods on Collections
                    3.5.1   GET, HEAD for Collections
                    3.5.2   POST for Collections
                    3.5.3   PUT for Collections
                    3.5.4   DELETE for Collections

                    3.5.5   DELETE Method for Non-Collection
                            Resources
               3.6  COPY Method
                    3.6.1   Problem Description
                    3.6.2   Solution Requirements
                    3.6.3   The Request
                    3.6.4   The Response
                    3.6.5   Examples
               3.7  MOVE Method
                    3.7.1   Problem Description
                    3.7.2   Solution Requirements
                    3.7.3   The Request
                    3.7.4   The Response
                    3.7.5   Examples
               3.8  ADDREF Method
                    3.8.1   Problem Definition
                    3.8.2   Solution Requirements
                    3.8.3   The Request
                    3.8.4   Example
               3.9  DELREF Method
                    3.9.1   Problem Definition
                    3.9.2   Solution Requirements
                    3.9.3   The Request
                    3.9.4   Example
               3.10 PATCH Method
                    3.10.1  Problem Definition
                    3.10.2  Solution Requirements
                    3.10.3  The Request
                    3.10.4  text/xml elements for PATCH
                    3.10.5  The Response
                    3.10.6  Examples
               3.11 Headers
                    3.11.1  Destination Header
                    3.11.2  Enforce-Live-Properties Header
                    3.11.3  Overwrite Header
                    3.11.4  Destroy Header
                    3.11.5  Collection-Member Header
               3.12 Links
                    3.12.1  Source Link Property Type
          4    State Tokens
               4.1  Overview
                    4.1.1   Problem Description
                    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.4  State Token Header
               4.5  E-Tag
          5    Locking
               5.1  Locking: Introduction
                    5.1.1   Exclusive Vs. Shared Locks
                    5.1.2   Required Support
               5.2  LOCK Method
                    5.2.1   Operation
                    5.2.2   The Effect of Locks on Properties and
                            Containers
                    5.2.3   Locking Replicated Resources
                    5.2.4   Locking Multiple Resources
                    5.2.5   Interaction with other Methods
                    5.2.6   Lock Compatibility Table
                    5.2.7   Status Codes
                    5.2.8   Lock-Info Request Header
                    5.2.9   Owner Request Header
                    5.2.10  Time-Out Header
                    5.2.11  Lock Response

                    5.2.12  Example - Simple Lock Request
                    5.2.13  Example - Multi-Resource Lock Request
               5.3  Write Lock
                    5.3.1   Methods Restricted by Write Locks
                    5.3.2   Write Locks and Properties
                    5.3.3   Write Locks and Null Resources
                    5.3.4   Write Locks and Collections
                    5.3.5   Write Locks and COPY/MOVE
                    5.3.6   Re-issuing Write Locks
                    5.3.7   Write Locks and The State-Token Header
               5.4  Lock Tokens
                    5.4.1   Problem Description
                    5.4.2   Lock Token Introduction
                    5.4.3   Generic Lock Tokens
                    5.4.4   OpaqueLockToken Lock Token
               5.5  UNLOCK Method
                    5.5.1   Problem Definition
                    5.5.2   Example
               5.6  Discovery Mechanisms
                    5.6.1   Lock Capability Discovery
                    5.6.2   Active Lock Discovery
          6    Version Control
          7    Internationalization Support
          8    Security Considerations
          9    Copyright
          10   Acknowledgements
          11   References
          12   Authors' Addresses

          1    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 - A set of name/value pairs that contain descriptive
          information about a resource.

          Live Properties - Properties whose semantics and syntax are
          enforced by the server. For example, a live "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" 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.

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

          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" and "attribute".

          Properties are used within distributed authoring environments to
          provide for efficient discovery and management of resources. For
          example, a 'subject' property might allow for the indexing of all
          resources by their subject, and an '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 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 doubles. The name
          of a property identifies the property's syntax and semantics, and
          provides an address with which to refer to a property. The name
          and value of a property is expressed as a well-formed XML
          element, where the name of the property is the name of the XML
          element, and the value of the property MUST be 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.  It must be possible to associate a
          URL with the property name.

          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 ubiquitous.
          ·    The majority of databases use a fixed schema 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 will not restrict RDBS from taking
          full advantage of their search facilities.

          However, it seems that future trends might be toward hierarchical
          properties. 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 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 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 B but not a property A/B, where A is also a property
          defined on the resource.

          Finally, it is not possible to define the same property twice as
          this would cause a collision in the resource's property
          namespace.

          2.3  Schemas

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

          Schema discovery is used to determine if a system supports 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.

          A resource declares its support for a schema by defining a
          property whose name is the same as the schema's. The property
          SHOULD contain the PropSchema XML element.

          2.3.1     PropSchema XML Element

          Name:     http://www.ietf.org/standards/dav/PropSchema
          Purpose:  To provide information about properties
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   [DTD] [DefinedProps]
          Description:This property contains the definition of the schema.
          This definition consists of two parts. A DTD element that
          contains a DTD that declares all XML elements and DefinedProps
          that defines any properties associated with the schema. As with
          all XML it is possible to add extra XML elements. Therefore
          schemas may define extra XML elements which are to be included
          with their values.

          2.3.2     DTD XML Element

          Name:          http://www.ietf.org/standards/dav/DTD
          Purpose:  To contain the DTD for XML elements associated with the
          schema.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values:   XML Declaration statements

          2.3.3     DefinedProps XML Element

          Name:          http://www.ietf.org/standards/dav/DefinedProps
          Purpose:  To contain a list of properties defined by the schema.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   1*PropEntries

          2.3.4     PropEntries XML Element

          Name:          http://www.ietf.org/standards/dav/PropEntries
          Purpose:  To contain the name of a defined property, the DTD of
          its value, and its live/dead status.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   DefinedProps
          Values=   Prop [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

          Name:          http://www.ietf.org/standards/dav/Live
          Purpose:  If present this indicates the server MUST enforce the
          syntax and semantics of the property.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   PropEntries

          2.4  DAV Schema

          The DAV Schema is specified as
          http://www.ietf.org/standards/dav/. This schema is used to
          indicate support for
          ·    properties that may be defined on a resource and
          ·    XML elements that may be returned in responses.

          2.4.1     DAV Property

          Name:          http://www.ietf.org/standards/dav
          Purpose:  Defines support for the DAV schema and protocol.
          Schema:   http://www.ietf.org/standards/dav/
          Values=   PropSchema Level
          Description:This property indicates that the resource supports the DAV schema and protocol create element in PROPPATCH to set, 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 indicate new
   name seems to cause less confusion.

   Moved all headers in the level of DAV compliance draft to a single section.

   Deleted the resource
          meets.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   DAV
          Values=   "1" | "2" | "3"
          Description:A value state token section of 1 for level indicates that the resource
          supports the property draft and namespace sections of the DAV
          specification. Level 2 indicates that moved the resource supports level
          1 and state
   token headers to the lock header section of the specification, with a minimum
          locking capability of draft.  Removed the write lock. Level 3 indicates support
          for levels 1 and 2 as well as support for state
   token header.

   Changed the versioning write lock section
          of the DAV specification.

          2.4.3     Prop XML element

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

          Purpose:  Contains properties related to state that a resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values:   XML Elements
          Description:The Prop XML element is Lock-Token request
   header, not a generic container for
          properties defined on resources. All elements inside Prop MUST
          define properties related state-token request header, is to the resource. No other elements may be used inside of submitted on
   request for write locked resources.

   Created a Prop element.

          2.4.4     PropLoc "generic" XML element section for XML Attribute

          Name:          http://www.ietf.org/standards/dav/PropLoc
          Purpose:  To specify the location of the 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 specify the URL of the property on the
          associated resource. The PropLoc attribute MUST NOT be used in
          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 previous specifies that get
   repeatedly re-used throughout the property author exists on some
          unspecified resource spec.  I moved LINK XML element to
   this section.

   Made multistatus and that the property can be directly
          referenced at http://www.foo.com/resource/props/Author. The
          resource upon which Schema discovery their own level one sections.

   Collected all the property is defined must be determined
          from context.

          2.5  Property Identifiers

          2.5.1     Problem Definition

          DAV properties are resources and thus may have a URI where together.

   Removed all references to the
          value of an instance possibility of properties have their
   own URIs.  This includes removing the property may be retrieved.  This URI
          is identifier section.

   Separated the section on web collections and namespaces into two
   separate from sections.

   Collected all the URI new response codes together into their own
   section.

   Changed the XML multiresponse element name to multistatus.

   Added a stand alone section on levels of the DAV compliance. I also went
   method by method, property by property, which identifies to specify compliance
   requirements.

   Added an introduction.

   Changed all the syntax "True" and semantics of the property, but which does not give
          information on how "False" to access "T" and "F".

   Altered the value of an instance first two paragraphs of the
          property.

          A server is free to assign whatever URI it chooses to identify an
          instance of a property defined on a resource. In fact, a server
          is free not Property Names section to reveal
   make the URI of an instance of relationship between a particular
          resource property's name and instead require that the client access its schema a
   little clearer.  I also added some text in the same section defining
   a property
          through PROPFIND name as a namespace and PROPPATCH.  However, many servers will want element.

   Added a second paragraph to allow clients property model for http resources -
   overview.  This paragraph clarifies why XML was chosen.

   Added a 409 Conflict error to directly manipulate properties. On these
          servers, move to cover attempts to move a client can discover
   collection with members.

   Changed the URI of an instance of collection requirement to read the collections SHOULD
   end with "/".  Also added a SHOULD about returning a location header
   if the client submits a URL for a collection without a trailing "/".

   Moved the owner header into the body due to size concerns.

   Replaced the iscollection xml element with resourcetype.

   Moved the DAV property by performing a PROPFIND and examining to the PropLoc
          attribute, if returned, of each property.

          2.6  Link XML Element

          2.6.1     Problem Description

          A mechanism DAV header that is needed to associate resources returned with other
          resources. These associations, known
   OPTIONS.

   Folded the tree draft into this draft.  Changed the DELETE, COPY,
   and MOVE sections to include their effect on collections as links, consist of three
          values, taken
   from the tree draft.  Created a type describing Depth header section and put in the nature of
   general rules that were in the association, introduction to the
          source of tree draft.  I
   also added the link, 102 response and response-status header.

   Removed the destination of the link. In the case
          of annotation, neither versioning section.

   Put all the source nor methods into a single section.

   Replaced the destination of PROPFIND request body with a link
          need be propfind header. Now the resource upon
   response can be cached just using vary.

   Nuked resinfo for INDEX and combined it with multistatus which the link is recorded.

          2.6.2     Solution Requirements

          The association mechanism MUST make use of the DAV property
          mechanism in order to make
   now used for both INDEX and PROPFIND.  Stripped down INDEX as
   agreed.

   Removed the existence of problem definition and proposed solution sections. We
   can always cut and paste them together from the associations
          searchable.

          2.6.3     Link XML Element

          Name:          http://www.ietf.org/standards/dav/link
          Purpose:  To identify a property as older version if we
   feel we need them but this draft is supposed to be a link dry run for
   last call and to contain last call documents do not have problem
   definition/proposed solution sections.

   Killed the
          source and destination of that link.
          Schema:   http://www.ietf.org/standards/dav/
          Values=   1*Src 1*Dst
          Description:Link section on schema discovery, it is controversial and we
   aren't going to be able to require it.  We should specify it in a
   different spec.

   Added a section on notational conventions used within the document.

   Moved the terminology section to provide the sources and destinations
          of a link. The type end of the property containing document to provide
   better flow from the Link XML
          element provides high-level introduction to the specific
   introduction sections.

   Increased the type numeric value of the link. Link is a multi-valued
          element, so multiple Links may be used together 4xx status codes introduced in
   this specification to indicate
          multiple links avoid conflicts with the same type.

          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.6.5     Dst XML Element

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

          2.6.6     Example

          <?XML:Namespace
               href = "http://www.ietf.org/standards/dav/" AS = "D"/>
          <?XML:Namespace
               href = "http://www.foocorp.com/Project/" AS = "F"/>
          <D:Prop>
               <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
   HTTP/1.1 specification, which contains three links. Each link contains
          three elements, introduces two of which, src new 4xx status codes.

   Wrote internationalization concerns section.

   Added XML version number to all examples.

Contents

STATUS OF THIS MEMO...................................................1
ABSTRACT..............................................................1
CHANGES...............................................................1

1.1. Changes since draft-ietf-webdav-protocol-04.txt..................1
CONTENTS..............................................................5
2. INTRODUCTION.......................................................8
3. DATA MODEL FOR RESOURCE PROPERTIES.................................9
3.1. The Resource Property Model......................................9
3.2. Existing Metadata Proposals.....................................10
3.3. Properties and dst, are part HTTP Headers.....................................10
3.4. Property Values.................................................10

3.5. Property Names..................................................11
4. COLLECTIONS OF WEB RESOURCES......................................11
4.1. Collection Resources............................................11
4.2. Creation and Retrieval of the DAV
          schema defined in this document, Collection Resources..................12
4.3. HTTP URL Namespace Model........................................13
4.4. Source Resources and one which is defined Output Resources...........................13
5. LOCKING...........................................................14

5.1. Exclusive Vs. Shared Locks......................................14
5.2. Required Support................................................15
5.3. Lock Tokens.....................................................16
5.4. opaquelocktoken Lock Token URI Scheme...........................16
5.5. Lock Capability Discovery.......................................16
5.6. Active Lock Discovery...........................................17
6. WRITE LOCK........................................................17
6.1. Methods Restricted by the
          schema http://www.foocorp.com/project/ (Source, Library, Write Locks...............................17

6.2. Write Locks and
          Makefile). A client which only implements the elements in the Properties......................................17
6.3. Write Locks and Null Resources..................................17
6.4. Write Locks and Collections.....................................18
6.5. Write Locks and COPY/MOVE.......................................18
6.6. Re-issuing Write Locks..........................................18
6.7. Write Locks and The Lock-Token Request Header...................18
7. NOTATIONAL CONVENTIONS............................................19

8. HTTP METHODS FOR DISTRIBUTED AUTHORING............................19
8.1. PROPFIND........................................................19
8.2. PROPPATCH.......................................................23
8.3. MKCOL Method....................................................25
8.4. INDEX Method....................................................26
8.5. DELREF Method...................................................28
8.6. ADDREF Method...................................................28
8.7. GET, HEAD for Collections.......................................29

8.8. POST for Collections............................................29
8.9. DELETE..........................................................29
8.10. PUT............................................................31

8.11. COPY Method....................................................31
8.12. MOVE Method....................................................35
8.13. LOCK Method....................................................38

8.14. UNLOCK Method..................................................42
8.15. PATCH Method...................................................43
9. DAV
          spec will not understand HEADERS.......................................................47
9.1. Collection-Member Header........................................47
9.2. DAV Header......................................................47
9.3. Depth Header....................................................47
9.4. Destination Header..............................................48
9.5. Destroy Header..................................................48

9.6. Enforce-Live-Properties Header..................................49
9.7. If-None-State-Match.............................................49
9.8. If-State-Match..................................................50
9.9. Lock-Info Request Header........................................50
9.10. Lock-Token Request Header......................................51
9.11. Lock-Token Response Header.....................................51
9.12. Overwrite Header...............................................52

9.13. Propfind Request Header........................................52
9.14. Status-URI Response Header.....................................52
9.15. Timeout Header.................................................52
10. RESPONSE CODE EXTENSIONS TO RFC 2068.............................54
10.1. 102 Processing.................................................54
10.2. 207 Multi-Status...............................................54
10.3. 418 Unprocessable Entity.......................................54
10.4. 419 Insufficient Space on Resource.............................54

10.5. 420 Method Failure.............................................54
11. MULTI-STATUS RESPONSE............................................54
11.1. multistatus XML Element........................................55
11.2. response XML Element...........................................55
11.3. status XML Element.............................................55
11.4. responsedescription XML Element................................55
12. GENERIC DAV XML ELEMENTS.........................................55

12.1. href XML Element...............................................56
12.2. link XML Element...............................................56
12.3. prop XML element...............................................57
13. DAV PROPERTIES...................................................57
13.1. creationdate Property..........................................57
13.2. displayname Property...........................................57
13.3. get-content-language Property..................................58
13.4. get-content-length Property....................................58

13.5. get-content-type Property......................................58
13.6. get-etag Property..............................................58
13.7. get-last-modified Property.....................................59
13.8. index-content-language Property................................59

13.9. index-content-length Property..................................59
13.10. index-content-type Property...................................59
13.11. index-etag Property...........................................59

13.12. index-last-modified Property..................................60
13.13. lockdiscovery Property........................................60
13.14. resourcetype Property.........................................62
13.15. Source Link Property Type.....................................62
13.16. supportedlock Property........................................63
14. DAV COMPLIANCE LEVELS............................................64
14.1. Level 1........................................................64
14.2. Level 2........................................................64

15. INTERNATIONALIZATION SUPPORT.....................................65
16. SECURITY CONSIDERATIONS..........................................66
17. TERMINOLOGY......................................................66
18. COPYRIGHT........................................................66
19. ACKNOWLEDGEMENTS.................................................67
20. REFERENCES.......................................................69
21. AUTHORS' ADDRESSES...............................................71

2. Introduction

   This document describes an extension to the foocorp elements HTTP/1.1 protocol that
   allows clients to perform remote web content authoring operations.
   This extension provides a coherent set of methods, headers, request
   entity body formats, and will ignore
          them, thus seeing the expected source response entity body formats that provide
   operations for:

   Properties: The ability to create, remove, and destination links. An
          enhanced client may know query information
   about Web pages, such as its author, creation date, etc. Also, the foocorp elements
   ability to link pages of any media type to related pages.

   Collections: The ability to create sets of related documents, and be able to present the user with additional information about the links.

          2.7  Multi-Status Response

          2.7.1     Problem Definition

          Some methods effect
   receive a listing of pages at a particular hierarchy level (like a
   directory listing in a file system).

   Locking: The ability to keep more than one resource. The effect of the
          method person from working on each of a
   document at the scoped resources may be different, same time. This prevents the "lost update problem"
   in which modifications are lost as such
          a return format that can specify first one author, then another
   writes their changes without merging the effect other author's changes

   Namespace Operations: The ability to copy and move Web resources

   Efficient Update: The ability to send changes which are proportional
   to the size of the method on each
          resource is needed.

          2.7.2     Solution Requirements

          The solution must:
          - communicate change rather than retransmitting the status code entire
   resource.

   Requirements and reason
          - give rationale for these operations are described in a
   companion document, "Requirements for a Distributed Authoring and
   Versioning Protocol for the URI World Wide Web" [Slein et al., 1997].

   The sections below provide a detailed introduction to resource
   properties (Section 3), collections of resources (Section 4), and
   locking operations (Section 5).  These sections introduce the resource on which
   abstractions manipulated by the WebDAV-specific HTTP methods
   described in Section 8, "HTTP Methods for Distributed Authoring".

   In HTTP/1.1, method parameter information was invoked
          - be consistent with other return body formats

          2.7.3     Multi-Status Response

          The default multi-status response body is an text/xml exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter
   information either in an Extensible Markup Language (XML) [Bray,
   Sperberg-McQueen, 1997] request entity
          that contains a single XML element called multiresponse, which
          contains a set body, or in an HTTP header.
   The use of XML to encode method parameters was motivated by the
   ability to add extra XML elements called response, one for each 200,
          300, 400, to existing structures, providing
   extensibility, and 500 series status code generated during the method
          invocation.  100 series status codes MUST NOT be recorded by XML's ability to encode information in ISO
   10646 character sets, providing internationalization support. As a
          response
   rule of thumb, parameters are encoded in 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 entity bodies when they
   have unbounded length, or when they may be shown to a human user and
   hence require encoding in an ISO 10646 character set.  Otherwise,
   parameters are encoded within an HTTP header.  Section 9 describes
   the top level new HTTP headers used with WebDAV methods.

   In addition to encoding method parameters, XML is used in WebDAV to
          provide a general message describing
   encode the over arching nature of responses from methods, providing the response. If this value is available an application MAY use
          it instead extensibility and
   internationalization advantages of presenting XML for method output, as well as
   input. XML elements used in this specification are defined in
   Section 12.

   While the individual response descriptions
          contain within codes provided by HTTP/1.1 are sufficient to
   describe the responses.

          2.7.3.2   Response

          Name: http://www.ietf.org/standards/dav/response
          Purpose:  Holds a 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 preponderance of error conditions encountered by WebDAV
   methods, there are some errors that do not fall neatly into the name of properties. Multiple properties
   existing categories.  New status codes developed for the WebDAV
   methods are defined in Section 10.  Since some WebDAV methods may be
          included if
   operate over many resources, the same response applies multiresponse status type has been
   introduced to them all. If HREF return status information for multiple resources.
   Multiresponse status is
          used then the response refers described in Section 11.

   The properties mechanism is employed by WebDAV to a problem with store information
   about the referenced
          resource, not current state of the resource.  For example, when a property.

          2.7.3.3   Status

          Name: http://www.ietf.org/standards/dav/status
          Purpose:  Holds lock
   is taken out on a 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 resource, a message that can be displayed to the user
          explaining lock information property describes
   the nature current state of the response.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Multiresponse and/or Response
          Value:    Any
          Description:   This XML element provides information suitable lock. Section 13 defines the properties
   used within the WebDAV specification.

   Finishing off the specification are sections on what it means to be presented to a user.

          2.8  Properties
   compliant with this specification (Section 14), on
   internationalization support (Section 15), and Methods

          2.8.1     DELETE

          As properties on security (Section
   16).

3. Data Model for Resource Properties

3.1. The Resource Property Model

   Properties are resources, the deletion of a property causes
          the same result as the deletion pieces of any resource. It is worth
          pointing out data that describe the deletion state of a property effects both direct
          manipulation, that is by the property's URL, as well as indirect resource.
   Properties are data about data.

   Properties are used in distributed authoring environments to provide
   for efficient discovery and manipulation, that is PROPPATCH and PROPFIND.

          2.8.2     GET

          A GET with a Request-URI that identifies management of resources.  For example, a
   'subject' property returns might allow for the
          name and value indexing of that property.  Accept types may be used to
          specify all resources by
   their subject, and an 'author' property might allow for the format
   discovery of the return value, but all what authors have written which documents.

   The DAV compliant
          servers MUST at minimum support a return type property model consists of text/xml. If
          text/xml is used as the response format then it MUST return the name/value pairs.  The name and value of the a
   property using the Prop XML element.

          2.8.2.1   Example

          The following example assumes that identifies the property's URL, originally
          generated by the server, was discovered by examining the proploc
          XML attribute returned on a 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 PROPPATCH method processes instructions specified in the
          request body to create and/or remove properties defined on the
          resource identified syntax and semantics, and
   provides an address by Request-URI.

          All DAV compliant servers MUST process instructions which are
          specified using the PropertyUpdate, Create, to refer to that syntax and Remove XML
          elements of the DAV schema.  The request message body MUST
          contain at least one PropertyUpdate XML element.  Instruction
          processing MUST occur in the order instructions semantics.

   There are received
          (i.e., from top to bottom), two categories of properties: "live" and MUST be performed atomically.

          2.8.3.1   PropertyUpdate XML element

          Name:          http://www.ietf.org/standards/dav/PropertyUpdate
          Purpose:  To contain a request to alter the properties on a
          resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   *(Create | Remove)
          Description:This XML element is a container for the information
          required to modify the properties on "non-live".  A
   live property has its syntax and semantics enforced by the resource. server.
   This XML
          element is multi-valued.

          2.8.3.2   Create XML element

          Name:          http://www.ietf.org/standards/dav/create
          Purpose:  To create represents the DAV properties specified inside two cases of a) 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 MUST contain only value of a Prop XML
          element. The elements contained property is read-
   only, maintained by Prop specify the name server, and b) the value of properties that are created on Request-URI. If a the property already exists then its value is replaced. The Prop XML
          element MUST NOT contain a PropLoc XML attribute.

          2.8.3.3   Remove XML element

          Name:          http://www.ietf.org/standards/dav/remove
          Purpose:  To remove
   maintained by the DAV properties specified inside client, but server performs syntax checking on
   submitted values. A non-live property has its syntax and semantics
   enforced by the
          Remove XML element.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   http://www.ietf.org/standards/dav/PropertyUpdate
          Values=   Prop
          Description:Remove specifies that client; the properties specified in
          Prop should be removed. Specifying server merely records the removal value of a the
   property that
          does not exist is not verbatim.

3.2. Existing Metadata Proposals

   Properties have long played an error. All the elements essential role in Prop MUST be
          empty, as only the names maintenance of
   large document repositories, and many current proposals contain some
   notion of properties to be removed are
          required.

          2.8.3.4   Response

          The response MUST have a response body that contains a
          multiresponse identifying property, or discuss web metadata more generally.  These
   include PICS [Miller et al., 1996], PICS-NG, the results for each property.

          2.8.3.5   Response Codes

          200 OK - The command succeeded. As there can be 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 mixture position paper on Web
   metadata architecture [Berners-Lee, 1997].  Work on PICS-NG and Web
   Collections has been subsumed by the Resource Definition Framework
   (RDF) metadata activity of the World Wide Web Consortium, which
   consists of
          Create and Removes in a body, network-based data model and an XML representation of
   that model.

   Some proposals come from a 201 Create seems inappropriate.
          403 Forbidden - The client, for reasons digital library perspective.  These
   include the server chooses not to
          specify, can not alter one of Dublin Core [Weibel et al., 1995] metadata set and the properties.
          405 Conflict - The client has provided
   Warwick Framework [Lagoze, 1996], a value whose semantics
          are not appropriate container architecture for the property. This
   different metadata schemas.  The literature includes trying to set
          read only properties.
          413 Request Entity Too Long - If many examples
   of metadata, including MARC [MARC, 1994], a particular property is too
          long to be recorded then bibliographic metadata
   format, and RFC 1807 [Lasher, Cohen, 1995], a composite XML error will be returned
          indicating the offending property.
          417 Insufficient Space on Resource - The resource does not have
          sufficient space to record technical report
   bibliographic format employed by the state of Dienst system. Additionally,
   the resource after proceedings from the
          execution of this method.
          418 Atomicity Failure - The command was not executed because first IEEE Metadata conference describe
   many community-specific metadata sets.

   Participants of
          an atomicity failure elsewhere the caused 1996 Metadata II Workshop in Warwick, UK
   [Lagoze, 1996], noted that, "new metadata sets will develop as the 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
   networked infrastructure matures" and "different communities will
   propose, design, and be responsible for different types of
   metadata." These observations 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 PUT corroborated by noting that
   many community-specific sets of metadata already exist, and there is specified
   significant motivation for the development of new forms of metadata
   as many communities increasingly make their data available in order
   digital form, requiring a metadata format to control what is returned by assist data location
   and cataloging.

3.3. Properties and HTTP Headers

   Properties already exist, in a GET.
          However limited sense, in HTTP message
   headers.  However, in distributed authoring environments a GET on
   relatively large number of properties are needed to describe the
   state of a property always returns resource, and setting/returning them all through HTTP
   headers is inefficient.  Thus a predefined property
          containment format. Therefore PUT can not be used if the Request-
          URI refers mechanism is needed which allows a
   principal to identify a property.

          2.8.5     PROPFIND

          The PROPFIND method retrieves set of properties defined on Request-URI. in which the principal is
   interested and to then set or retrieve just those properties.

3.4. Property Values

   The request message body value of a property is an expressed as a well-formed XML document that MUST contain
          only one PropFind document.

   XML element, which specifies the type has been chosen because it is a flexible, self-describing,
   structured data format that supports rich schema definitions, and
   because of
          property find action its support for multiple character sets.  XML's self-
   describing nature allows any property's value to be performed.  The XML element contained extended by PropFind specifies
   adding new elements.  Older clients will not break because they will
   still have the type of action data specified in the original schema and will ignore
   elements they do not understand.  XML's support for multiple
   character sets allows human-readable properties to be performed:
          retrieve all property names and values (AllProp), retrieve only
          specified property names encoded and values (Prop), or retrieve only
   read in a
          list of all character set familiar to the user.

3.5. Property Names

   A property names (Propname).  When name is a Prop XML element universally unique identifier that is present, it specifies
   associated with a list of schema that provides information about the names of properties whose
          name syntax
   and value are to be returned.  The Prop element, when used
          within semantics of the property.

   Because a FINDPROP request body MUST be empty.

          The response property's name is universally unique, clients can depend
   upon consistent behavior for a text/xml message body particular property across multiple
   resources, so long as that contains a
          MultiResponse property is "live" on the resources in
   question.

   The XML element namespace mechanism, which describes the results of the
          attempts is based on URIs, is used to retrieve the various properties. If name
   properties because it provides a mechanism to prevent namespace
   collisions and for varying degrees of administrative control.

   The property was
          successfully retrieved then its value MUST be returned in the
          prop XML element. In the case namespace is flat; that is, no hierarchy of Allprop and Findprop, properties
   is explicitly recognized.  Thus, if a
          principal does not have the right to know if property A and a particular property exists, an error MUST NOT be returned. The results A/B
   exist on a resource, there is no recognition of
          this method SHOULD NOT any relationship
   between the two properties.  It is expected that a separate
   specification will eventually be cached.

          2.8.5.1   Propfind XML element

          Name:          http://www.ietf.org/standards/dav/Propfind
          Purpose:  To specify produced which will address issues
   relating to hierarchical properties.

   Finally, it is not possible to define the same property twice on a
   single resource, as this would cause a collision in the set resource's
   property namespace.

4. Collections of matching properties
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Values=   (Prop | Allprop | Propname)
          Description: Propfind is Web Resources

   This section provides a container element for description of a new type of Web resource,
   the exact
          specification collection, and discusses its interactions with the HTTP URL
   namespace. The purpose of a PROPFIND request.

          2.8.5.2   Allprop

          Name:          http://www.ietf.org/standards/dav/Allprop
          Purpose:  To specify that all properties are collection resource is to be returned
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Propfind
          Description: Its presence in model
   collection-like objects (e.g., filesystem directories) within a PROPFIND request specifies
   server's namespace.

   All DAV compliant resources MUST support the
          name HTTP URL namespace
   model specified herein.

4.1. Collection Resources

   A collection is a resource whose state consists of an unordered list
   of internal members, an unordered list of external members, and value a
   set of all properties defined on the properties.  An internal member resource MUST be
          returned.

          2.8.5.3   Propname

          Name:          http://www.ietf.org/standards/dav/Propname
          Purpose:  To specify have a URI that
   is immediately relative to the names base URI of all properties defined on the resource are to be returned.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Propfind
          Description: Its presence collection, that is,
   a relative URI in which "../" is illegal, which MUST begin with "./"
   and which SHOULD contain a PROPFIND request specifies "/" at the
          name end of all properties defined on the resource MUST be returned.

          2.8.5.4   PropFindResult XML element

          Name: http://www.ietf.org/standards/dav/PropFindResult
          Purpose: To contain URI if the 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 Multi-Response
          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 internal
   member resource is itself a collection.

   An external member resource MUST be 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 user does absolute URI that is not have access an
   internal URI.  Any given internal or external URI MUST only belong
   to the DingALink property. </ResponseDescription>
               </Response>
          </D:MultiResponse>

          The result will return all collection once, i.e., it is illegal to have multiple
   instances of the same URI in a collection.  Properties defined on
   collections behave exactly as do properties on non-collection
   resources.

   There is a standing convention that when a collection is referred to
   by its name without a trailing slash, the container. trailing slash is
   automatically appended.  Due to this, a resource MAY accept a URI
   without a trailing "/" to point to a collection. In this case only two properties were found. The principal did not have
          sufficient access rights it
   SHOULD return a location header in the response pointing to see the third and fourth properties
          so an error was returned.

          2.8.5.6   Example 2 - Allprop

          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>
               <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 particular client only had URL
   ending with the right to see two properties,
          BoxType and Author. No error is returned for "/".  For example, if a client performs an INDEX on
   http://foo.bar/blah (no trailing slash), the remaining
          properties, resource
   http://foo.bar/blah/ (trailing slash) MAY respond as if the client does not even have sufficient rights
   operation were invoked on it, and SHOULD return a location header
   with http://foo.bar/blah/ in it.

4.2. Creation and Retrieval of Collection Resources

   This document specifies the MKCOL method to
          know they exist. If create new collection
   resources, rather than using the existing HTTP/1.1 PUT or POST
   method, for the client did have following reasons

   In HTTP/1.1, the right PUT method is defined to know they
          existed but did not have store the right to see their value, request body at
   the location specified by the Request-URI.  While a 207
          multi-response description
   format for a collection can readily be constructed for use with PUT,
   the implications of sending such a multiresponse, as used in description to the previous server are
   undesirable.  For 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 only two if a description of a collection that
   omitted some existing resources were PUT to a 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 properties have direct URLs
          available, while semantics of PUT, and makes it difficult to control
   DELETE functionality with an access control scheme based on methods.

   While the other two properties can only POST method is sufficiently open-ended that a _create a
   collection_ POST command could be referenced
          via PROPFIND and PROPPATCH.

          3    A Proposal constructed, this is undesirable
   because it would be difficult to separate access control for Collections
   collection creation from other uses of POST.

   This document specifies the INDEX method for listing the contents of
   a collection, rather than relying on the existing HTTP/1.1 GET
   method.  This is to avoid conflict with the de-facto standard
   practice of redirecting a GET request on a directory to its
   index.html resource.

   The exact definition of Web Resources the behavior of GET and Name Space
             Operations

          3.1  Observations PUT on the collections
   is defined later in this document.

4.3. HTTP Object URL Namespace Model

          This section provides a description of

   The HTTP URL Namespace is a new type of Web
          resource, hierarchical namespace where the collection, and discusses its interactions
   hierarchy is delimited with the "/" character.  DAV compliant
   resources MUST maintain the consistency of the HTTP URL namespace.  This discussion is
   Any attempt to create a prerequisite for resource (excepting the
          specification root member of methods a
   namespace) that operate on collections, given later
          in this document.

          3.1.1     Collection Resources

          A would not be the internal member of a collection is
   MUST fail. For example, if the collection http://www.foo.bar.org/a/
   exists, but http://www.foo.bar.org/a/b/does not exist, an attempt to
   create http://www.foo.bar.org/a/b/c must fail.

4.4. Source Resources and Output Resources

   For many resources, the entity returned by a resource whose GET method exactly
   matches the persistent state consists of the resource, for example, a list of
          internal members, GIF
   file stored on a list of external members, and disk.  For this simple case, the URL at which a set
   resource is accessed is identical to the URL at which the source
   (the persistent state) of
          properties.  An internal member the resource MUST have a URI is accessed.  This is also
   the case for HTML source files that are not processed by the server
   prior to transmission.

   However, the server can sometimes process HTML resources before they
   are transmitted as a return entity body.  For example, server-side-
   include directives within an HTML file instruct a server to replace
   the directive with another value, such as the current date.  In this
   case, what is returned by GET (HTML plus date) differs from the
   persistent state of the resource (HTML plus directive).  Typically
   there is
          immediately relative no way to access the base URI of HTML resource containing the collection, that is,
          a relative URI in which "../"
   unprocessed directive.

   Sometimes the entity returned by GET is illegal, which must begin with
          "./" and which MAY contain only one other "/" at the end output of the
          URI. An external member resource MUST be an absolute URI a data-
   producing process that is
          not an internal URI.  Any given internal described by one or external URI MUST
          only belong to more source resources
   (that may not even have a location in the collection once, i.e., multiple instances URL namespace).  A single
   data-producing process may dynamically generate the state of
          URIs in a collection are illegal.  Properties defined on
          collections have no special distinction, and behave exactly as do
          properties on non-collection
   potentially large number of output resources.

          The purpose  An example of a collection resource this is to model collection-like
          objects (e.g., a filesystem directory) within a server's
          namespace.  Once these objects have been modeled with
          collections, a client may perform an INDEX, add and remove

          external members using ADDREF and DELREF, and perform recursive
          operations, such as
   a full hierarchy copy.

          To support methods which operate on collections, a server SHOULD
          model its collection-like objects with collection resources.  For
          example, CGI script that describes a server which is implemented on top "finger" gateway process that maps
   part of a filesystem
          SHOULD treat all filesystem directories exposed by the namespace of a server into finger requests, such as
          collection resources.

          3.1.2     Creation and Retrieval of Collection Resources

          This document specifies
   http://www.foo.bar.org/finger_gateway/user@host.

   In the MKCOL method absence of distributed authoring capabilities, it is
   acceptable to create new collection
          resources, and the INDEX method have no mapping of source resource(s) to list their contents. the URI
   namespace. In HTTP/1.1, fact, preventing access to the PUT method source resource(s) has
   desirable security benefits.  However, if remote editing of the
   source resource(s) is defined to store desired, the request body
          at source resource(s) should be
   given a location in the URI namespace.  This source location specified by Request-URI.  While a description
          format for a collection can readily be constructed that could should
   not be
          used with PUT, the implications one of sending such a description to the locations at which the generated output is
   retrievable, since in general it is impossible for the server are undesirable.  For example, if to
   differentiate requests for source resources from requests for
   process output resources.  There is often a description of many-to-many
   relationship between source resources and output resources.

   On WebDAV compliant servers, for all output resources which have a
          collection
   single source resource (and that omitted some existing resources were PUT to source resource has a
          server, this might URI), the URI
   of the source resource SHOULD be interpreted as stored in a command to remove those
          members.  This would extend PUT to perform DELETE functionality,
          which is undesirable since it changes link on the semantics of PUT, and
          makes it difficult to control DELETE functionality output
   resource with an access
          control scheme based type http://www.ietf.org/standards/dav/source.  Note
   that by storing the source URIs in links on methods.

          While the POST method output resources,
   the burden of discovering the source is sufficiently open-ended placed on the authoring
   client.

5. Locking

   The ability to lock a resource provides a mechanism for serializing
   access to that resource.  Using a lock, an authoring client can
   provide a "create reasonable guarantee that another principal will not
   modify a
          collection" POST command could be constructed, this is
          undesirable because resource while it would be difficult to separate access
          control for collection creation from other uses of POST if they
          both use is being edited.  In this way, a client
   can prevent the same method.

          While it might seem desirable "lost update" problem.

   This specification allows locks to have GET return a listing vary over two client-specified
   parameters, the number of principals involved (exclusive vs. shared)
   and the
          members type of a collection, access to be granted.  Furthermore, this is foiled by document
   only provides the existence definition of locking for one lock access type,
   the
          "index.html" de-facto standard namespace redirection, in which a
          GET request on a collection write lock.  However, the syntax is automatically redirected to extensible, and permits the
          index.html resource.

          The exact definition
   eventual specification of the behavior other access types.

5.1. Exclusive Vs. Shared Locks

   The most basic form of GET and PUT on
          collections lock is defined later an exclusive lock.  This is a lock
   where the access right in this document.

          3.1.2.1   Example

          The structured resource http://foo/bar question is created with only granted to a PUT. Bar single
   principal.  The need for this arbitration results from a desire to
   avoid having to constantly merge results.

   However, there are times when the goal of a lock is not to exclude
   others from exercising an access right but rather to provide a multipart/related file
   mechanism for principals to indicate that they intend to exercise
   their access right.  Shared locks are provided for this case.  A
   shared lock allows multiple principals to receive a lock.  Hence any
   principal with appropriate access can get the lock.

   With shared locks there are two members http://foo/bar/a and
          http://foo/bar/b. If bar were deleted then both trust sets that affect a and b would
          also be deleted since they resource.
   The first trust set is created by access permissions.  Principals
   who are all really just one trusted, for example, may have permission to write the
   resource. If
          http://foo/bar/a/c was PUT then  Those who are not, don't.  Among those who have access
   permission to write the resource, the set of principals who have
   taken out a DELETE on http://foo/bar/a
          would shared lock also delete http://foo/bar/a/c as c was created with a PUT
          not must trust each other, creating a MKCOL.

          If http://foo/bar/b/d is created
   (typically) smaller trust set within the access permission write
   set.

   Starting with a MKCOL and
          http://foo/bar/b/d/e was created then a DELETE every possible principal on d would fail
          because d is a collection with an internal member. However the
          existence of Internet, in most
   situations the collection d is something vast majority of an illusion. If a
          DELETE was executed on http://foo/bar then everything would be
          deleted, even though http://foo/bar/b/d was created with these principals will not have write
   access to a MKCOL.

          Thus given resource.  Of the effect of a MKCOL within a composite resource’s
          namespace is felt on its children, small number who do have write
   access, some principals may decide to guarantee their edits are free
   from overwrite conflicts by using exclusive write locks.  Others may
   decide they trust their collaborators will not its ancestors. The
          children overwrite their work
   (the potential set of d MUST be treated as members collaborators being the set of a collection when a
          method is executed on d. But a method executed on b or a is
          treated as if there only existed a non-collection resource.

          3.1.3     Source Resources principals who
   have write permission) and Output Resources

          For many resources, the entity returned by GET exactly matches use a shared lock, which informs their
   collaborators that a principal is potentially working on the persistent state
   resource.

   The WebDAV extensions to HTTP do not need to provide all of the resource,
   communications paths necessary for example, a GIF file
          stored principals to coordinate their
   activities.  When using shared locks, principals may use any out of
   band communication channel to coordinate their work (e.g., face-to-
   face interaction, written notes, post-it notes on a disk.  For this simple case, the URL at which screen,
   telephone conversation, Email, etc.)  The intent of a
          resource shared lock is accessed
   to let collaborators know who else is identical potentially working on a
   resource.

   Shared locks are included because experience from web distributed
   authoring systems has indicated that exclusive write locks are often
   too rigid.  An exclusive write lock is used to enforce a particular
   editing process: take out exclusive write lock, read the URL at which resource,
   perform edits, write the source
          (the persistent state) of resource, release the resource is accessed. lock.  This is also editing
   process has the case for HTML source files problem that locks are not processed by the
          server prior to transmission.

          However, the server can sometimes process HTML resources before
          they are transmitted as always properly released,
   for example when a return entity body. For example,
          server-side-include directives within an HTML file instruct program crashes, or when a
          server lock owner leaves
   without unlocking a resource.  While both timeouts and
   administrative action can be used to replace the directive with another value, such as remove an offending lock,
   neither mechanism may be available when needed; the
          current date.  In this case, what is returned by GET (HTML plus
          date) differs from timeout may be
   long or the persistent state administrator may not be available.

   Despite their potential problems, exclusive write locks are
   extremely useful, since often a guarantee of the resource (HTML
          plus directive). Typically there freedom from overwrite
   conflicts is no way to access the HTML
          resource containing the unprocessed directive.

          Sometimes the entity returned by GET what is needed. This specification provides both
   exclusive write locks and the output less strict mechanism of a data-
          producing process that shared locks.

5.2. Required Support

   A WebDAV compliant server is described by one or more source
          resources (that may not even have a location required to support locking in any
   form.  If the URL
          namespace).  A single data-producing process may dynamically
          generate the state of a potentially large number of output
          resources. An example server does support locking it MAY choose to support
   any combination of exclusive and shared locks for any access types.

   The reason for this flexibility is a CGI script that describes a
          "finger" gateway process that maps part of locking policy strikes to
   the namespace very heart of a
          server into finger requests, such as
          http://www.foo.bar.org/finger_gateway/user@host.

          In the absence resource management and versioning systems
   employed by various storage repositories.  These repositories
   require control over what sort of distributed authoring capability, it locking will be made available.
   For example, some repositories only support shared write locks while
   others only provide support for exclusive write locks while yet
   others use no locking at all.  As each system is
          acceptable sufficiently
   different to have no mapping merit exclusion of source resource(s) to certain locking features, this
   specification leaves locking as the URI
          namespace, and in fact has desirable security benefits. However,
          if remote editing sole axis of the source resource(s) negotiation within
   WebDAV.

5.3. Lock Tokens

   A lock token is desired, the
          source resource(s) should be given a location in the URI
          namespace. This source location should not be one of the
          locations at which the generated output that identifies a particular lock.  A lock
   token is retrievable, since returned by every successful LOCK operation in
          general it is impossible for the server lock-
   token response header, and can also be discovered through lock
   discovery on a resource.

   Lock token URIs are required to differentiate requests
          for source be unique across all resources from requests for process output resources.
          There is often a many-to-many relationship between source
   all time. This uniqueness constraint allows lock tokens to be
   submitted across resources and output resources.

          For DAV compliant servers all output resources which have without fear of confusion.

   This specification provides a
          single source resource (and lock token URI scheme called
   opaquelocktoken that source resource has a URI), meets the uniqueness requirements.  However
   resources are free to return any URI of scheme so long as it meets the source resource SHOULD
   uniqueness requirements.

5.4. opaquelocktoken Lock Token URI Scheme

   The opaquelocktoken URI scheme is designed to be stored unique across all
   resources for all time.  Due to this uniqueness quality, a client
   MAY submit an opaque lock token in a single link Lock-Token request header and
   an if-state[-not]-match header on
          the output a resource with type
          http://www.ietf.org/standards/dav/source. Note other than the one that
   returned it.

   All resources MUST recognize the opaquelocktoken scheme and, at
   minimum, recognize that the lock token was not generated by storing the source URI
   resource.  Note, however, that resources are not required to
   generate opaquelocktokens in links on LOCK method responses.

   In order to guarantee uniqueness across all resources for all time
   the output resources, opaquelocktoken requires the burden use of
          discovering the source is placed on the authoring client.

          3.2  MKCOL Method

          3.2.1     Problem Description

          A client must be able to GUID mechanism.

   Opaquelocktoken generators, however, have a choice of how they
   create these tokens.  They can either generate a collection.

          3.2.2     Solution Requirements

          The solution must ensure that new GUID for every
   lock token they create, which is potentially very expensive, or they
   can create a collection has been made (i.e. single GUID and then add extension characters.  If the
   second method is selected then the program generating the extensions
   MUST guarantee that it responds to the INDEX method) as opposed to a non-

          collection resource. If a collection could not same extension will never be made, it must
          indicate this failure to used twice with
   the user-agent.

          3.2.3     Request

          MKCOL creates associated GUID.

   Opaque-Lock-Token = "opaquelocktoken" ":" GUID [Extension]
   GUID = ; As defined in [Leach, Salz, 1997]
   Extension = *urlc   ;urlc is defined in [Berners-Lee et al., 1997]
   (draft-fielding-url-syntax-07.txt)

5.5. Lock Capability Discovery

   Since server lock support is optional, a client trying to lock a new collection
   resource at on a server can either try the location specified
          by lock and hope for the Request-URI. If best,
   or perform some form of discovery to determine what lock
   capabilities the Request-URI exists, then MKCOL must
          fail. During MKCOL processing, a server MUST make the Request-URI
          a member supports.  This is known as lock capability
   discovery.  Lock capability discovery differs from discovery of its parent collection. If no such an ancestor exists,
   supported access control types, since there may be access control
   types without corresponding lock types.  A client can determine what
   lock types the method MUST fail. When server supports by retrieving the MKCOL operation creates a new
          collection resource, all ancestors MUST already exist, or supportedlock
   property.

   Any DAV compliant resource that supports the LOCK method MUST fail with
   support the supportedlock property.

5.6. Active Lock Discovery

   If another principal locks a 409 Conflict status code.  For example,
          if resource that a request principal wishes to create collection /a/b/c/d/ is made, and neither
          /a/b/ nor /a/b/c/ exist, the request MUST fail.

          3.2.3.1   MKCOL Without Request Body

          When MKCOL
   access, it is invoked without a request body, the newly created
          collection 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 useful for the body is present is limited second principal to
          creating collections, members of a collection, bodies of members
          and properties on be able to find out
   who the collections or members. If first principal is.  For this purpose the server
          receives a MKCOL request entity type it does not support or
          understand it MUST respond with a 415 (Unsupported Media Type)
          status code.  The exact behavior of MKCOL for various request
          media types lockdiscovery
   property is undefined in this document, provided.  This property lists all outstanding locks,
   describes their type, and will be specified
          in separate documents.

          3.2.4     Response

          Responses from a MKCOL request are not cacheable, since MKCOL has
          non-idempotent semantics.
          201 (Created) - The collection or structured provides their lock token.

   Any DAV compliant resource was created
          in its entirety.
          403 (Forbidden) - that supports the LOCK method MUST
   support the lockdiscovery property.

6. Write Lock

   This indicates at least one of two conditions:
          1) The server does not allow section describes the creation semantics specific to the write access
   type for locks.  The write lock is a specific instance of collections at a lock
   type, and is the
          given location only lock type described in its namespace, and 2) The parent collection of this specification.  A
   DAV compliant resource MAY support the Request-URI exists but cannot accept members.
          409 (Conflict) - write lock.

6.1. Methods Restricted by Write Locks

   A collection cannot be made at write lock prevents a principal without the Request-URI
          until one lock from successfully
   executing a PUT, POST, PATCH, PROPPATCH, MOVE, DELETE, MKCOL, ADDREF
   or more intermediate collections have been created.
          415 (Unsupported Media Type)- The server does not support DELREF on the
          request type locked resource.  All other current methods, GET in
   particular, function independent of the body.
          417 (Insufficient Space lock.

   Note, however, that as new methods are created it will be necessary
   to specify how they interact with a write lock.

6.2. Write Locks and Properties

   While those without a write lock may not alter a property on Resource) - The a
   resource does not have
          sufficient space to record it is still possible for the state values of live properties to
   change, even while locked, due to the resource after the
          execution requirements of this method.

          3.2.5     Example

          This example creates their schemas.
   Only dead properties and live properties defined to respect locks
   are guaranteed not to change while write locked.

6.3. Write Locks and Null Resources

   It is possible to assert a container collection called
          /webdisc/xfiles/ write lock on a null resource in order to
   lock the server www.server.org.
               MKCOL /webdisc/xfiles/ HTTP/1.1
               Host: www.server.org

               HTTP/1.1 201 Created

          3.3  Standard DAV Properties

          The following name.  Please note, however, that locking a null resource
   effectively makes the resource non-null, as the resource now has
   lock related properties are defined on DAV compliant resources.
          All enclosed properties are part it.

6.4. Write Locks and Collections

   A write lock on a collection prevents the addition or removal of
   members of the DAV Schema.

          3.3.1     IsCollection Property

          Name:     http://www.ietf.org/standards/dav/iscollection
          Purpose:  This property contains collection.  As a Boolean value that is set consequence, when a principal
   issues a request to
          "true" if the resource is create a new internal member of a collection
          Schema:   http://www.ietf.org/standards/dav/
          Value:    ("true" | "false")
          Description: This property
   using PUT or POST, or to remove an existing internal member of a
   collection using DELETE, this request MUST be defined fail if the principal
   does not have a write lock on all DAV compliant
          resources.

          3.3.2     DisplayName Property

          Name: http://www.ietf.org/standards/dav/displayname
          Purpose:  A name for the resource that collection.

   However, if a write lock request is suitable for
          presentation issued to a user.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    Any valid XML character data (as defined collection
   containing internal member resources that are currently locked in [Bray,
          Sperberg-McQueen, 1997])
          Description: This property SHOULD be defined on all DAV compliant
          resources. If present, a
   manner which conflicts with the property contains write lock, the request MUST fail
   with a description 409 Conflict status code.

6.5. Write Locks and COPY/MOVE

   The owner of the a write lock MUST NOT execute a MOVE method on a
   resource that he has locked.  This specification intentionally does not
   define what happens if a MOVE method request is suitable for presentation to made on a user.

          3.3.3     CreationDate Property

          Name: http://www.ietf.org/standards/dav/creationdate
          Purpose:  The time and date the locked
   resource was created.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    The time and date by the lock's owner.

   A COPY method invocation MUST be given in ISO 8601 format
          [ISO8601]
          Description: This property SHOULD be defined NOT duplicate any write locks active
   on all DAV compliant
          resources. the source.

6.6. Re-issuing Write Locks

   If present, it contains a timestamp of the moment when
          the resource was created (i.e., the moment it had non-null
          state).

          3.3.4     GETentity Property

          Name: http://www.ietf.org/standards/dav/GETentity
          Purpose:  Contains principal already owns a write lock on a resource, any future
   requests for the value same type of headers that are returned by a
          GET without Accept headers.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    Content-Type Content-Length Content-Language Last-
          Modified Etag Creation-Date
          Description: This property MUST be defined write lock, on all DAV compliant
          resources unless GET the same resource,
   while the principal's previous write lock is not supported, in which case this
          property MUST NOT be defined. This property effect, MUST contain at most
          one instance of each element result
   in its Value, if they are defined.

          3.3.5     INDEXentity Property

          Name: http://www.ietf.org/standards/dav/INDEXentity
          Purpose:  Contains a successful response with the value of headers that same lock token as provided for
   the currently existing lock.  Two lock requests are returned by an
          INDEX.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    Content-Type Content-Length Content-Language Last-
          Modified Etag Creation-Date

          Description: This property MUST be defined on all DAV compliant
          resources unless INDEX is not supported, in which case this
          property MUST NOT to be defined. This property MUST contain at most
          one instance of each element in its Value,
   identical if they their Lock-Info headers are defined.

          3.3.6     Content-Type XML Element

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

6.7. Write Locks and The content-type of Lock-Token Request Header

   If a user agent is not required to have knowledge about a lock when
   requesting an operation on a locked resource, the member following scenario
   might occur.  Program A, run by User A, takes out a write lock on a
   resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   GETentity or INDEXentity
          Value:    media-type   ; defined in Section 3.7  Program B, also run by User A, has no knowledge of [Fielding et
          al., 1997]
          Description: If the parent of
   lock taken out by Program A, yet performs a PUT to the locked
   resource.  In this element is GETentity, scenario, the
          value MUST be identical PUT succeeds because locks are
   associated with a principal, not a program, and thus program B,
   because it is acting with principal A's credential, is allowed to
   perform the content-type returned by a GET on PUT.  However, had program B known about the resource without Accept headers.  If lock, it
   would not have overwritten the parent is
          INDEXentity, resource, preferring instead to
   present a dialog box describing the value MUST be identical conflict to the content-type
          returned user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by an INDEX on other programs with
   the resource.  If no content-type same authorization.

   In order to prevent these collisions the lock token request header
   is
          available, introduced.  Please refer to the Lock Token Request Header
   section for details and requirements.

6.7.1. Write Lock Token Example

   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   Lock-Token: <opaquelocktoken:123AbcEfg1284h23h2>
   <opaquelocktoken:AAAASDFcalkjfdas12312>

   HTTP/1.1 200 OK

   In this element MUST NOT example, both the source and destination are locked so two
   lock tokens must be defined.

          3.3.7     Content-Length XML Element

          Name:          http://www.ietf.org/standards/dav/content-length
          Purpose:  Describes submitted.  If only one of the default content-length two resources was
   locked, then only one token would have to be submitted.

7. Notational Conventions

   Since this document describes a set of extensions to the resource.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    content-length ; see section 14.14 HTTP/1.1
   protocol, the augmented BNF used herein to describe protocol
   elements is exactly the same as described in Section 2.1 of RFC 2068
          Description: If
   2068, _Hypertext Transfer Protocol -- HTTP/1.1_ [Fielding et al.,
   1997].  Since this augmented BNF uses the parent basic production rules
   provided in Section 2.2 of RFC 2068, these rules apply to this element is GETentity,
   document as well.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
          element MUST have a value equal
   document are to be interpreted as described in RFC 2119 [Bradner,
   1997].

8. HTTP Methods for Distributed Authoring

8.1. PROPFIND

   The PROPFIND method retrieves properties defined on the content-length header
          returned by Request-URI,
   if it is a GET non-collection resource, or on the resource without Accept headers.  If Request-URI and
   potentially its member resources, if the
          parent resource is INDEXentity, a collection.
   All DAV compliant resources MUST support the PROPFIND method.

   A client MAY submit a Depth header with a PROPFIND on a collection
   with a value of "0", "1" or "infinity".  DAV compliant servers MUST be identical to
   support the
          content-length returned by an INDEX on "0", "1" and "infinity" behaviors. By default, the resource.  If no
          content-length is available, this element
   PROPFIND method on a collection without a Depth header MUST NOT be defined.

          3.3.8     Content-Language XML Element

          Name:          http://www.ietf.org/standards/dav/content-language
          Purpose:  Describes the default natural language of act as
   if a resource.
          Schema:   http://www.ietf.org/standards/dav/
          Value:    language-tag   ;language-tag Depth = infinity header was included.

   A client MUST submit a Propfind request header describing what
   information is defined in section
          14.13 being requested.  It is possible to request
   particular property values, all property values, or a list of RFC 2068
          Description: If the parent
   names of this element the resource's properties.

   The response is GETentity, this
          element MUST have a value equal to the content-language header
          returned by text/xml message body that contains a GET on multistatus
   XML element that describes the resource without Accept headers.  If results of the
          parent is INDEXentity, attempts to retrieve
   the various properties.  If a property was successfully retrieved
   then its value MUST be identical to the
          content-language header returned by an INDEX on the resource. in a prop XML element.  If
          no content-language header the scope
   of PROPFIND covers more than a single resource, as is available, this the case with
   Depth values of "1" and "infinity", each response XML element MUST NOT be
          defined.

          3.3.9     Last-Modified
   contain an href XML Element

          Name:     http://www.ietf.org/standards/dav/last-modified
          Purpose:  The date element which identifies the resource was last modified.
          Schema:        http://www.ietf.org/standards/dav/
          Parent:        GETentity or INDEXentity
          Value:    The date MUST be given in RFC 1123 format using on which
   the
          rfc-1123  production, defined properties in section 3.3.1 of [Fielding et al.,
          1997].
          Description: If the parent of this element is GETentity, this prop XML element MUST have a value equal to are defined. In the last-modified header
          returned by case of
   allprop and propname, if a GET on the resource without Accept headers.  If the
          parent is INDEXentity, principal does not have the value right to know
   if a particular property exists, an error MUST NOT be identical returned.  The
   results of this method SHOULD NOT be cached.

8.1.1. Example: Retrieving Named Properties

   PROPFIND  /files/ HTTP/1.1
   Host: www.foo.bar
   Depth: 0
   Propfind: <http://www.foo.bar/boxschema/bigbox> <http://www.foo.bar/
   boxschema/author> <http://www.foo.bar/boxschema/DingALing> <http://w
   ww.foo.bar/boxschema/Random>

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

   <?XML version="1.0">
   <?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
   <?namespace href = "http://www.foo.bar/boxschema" AS = R"?>
   <D:multistatus>
     <D:response>
          <D:prop>
               <R:bigbox>
                    <R:BoxType>Box type A</R:BoxType>
               </R:bigbox>
               <R:author>
                    <R:Name>J.J. Dingleheimerschmidt</R:Name>
               </R:author>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
     </D:response>
     <D:response>
          <D:prop><R:DingALing/><R:Random/></D:prop>
          <D:status>HTTP/1.1 403 Forbidden</D:status>
          <D:responsedescription> The user does not have access to the last-
          modified header returned by
   DingALing property.
          </D:responsedescription>
     </D:response>
     <D:responsedescription> There has been an INDEX access violation error.
     </D:responsedescription>
   </D:multistatus>

   In this example, PROPFIND is executed on the resource.  If no
          last-modified header is available, this element MUST NOT be defined.

          3.3.10    Etag XML Element

          Name: http://www.ietf.org/standards/dav/etag
          Purpose: collection
   http://www.foo.bar/files/.  The entity tag of specified depth is zero, hence the resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   GETentity or INDEXentity
          Value:    entity-tag  ; defined in Section 3.11
   PROPFIND applies only to the collection itself, and not to any of [Fielding et
          al., 1997]
          Description: If
   its members.  The Propfind header specifies the parent name of four
   properties whose values are being requested. In this element is GETentity, this
          element MUST case only two
   properties were returned, since the principal issuing the request
   did not have a value equal sufficient access rights to see the entity-tag header returned
          by a GET third and fourth
   properties.

8.1.2. Example: Using allprop to Retrieve All Properties

   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Depth: 1
   Propfind: allprop

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "S"?>
   <?namespace href = "http://www.foo.bar/boxschema/" AS = R"?>
   <S:multistatus>
     <S:response>
          <S:href>http://www.foo.bar/container/</S:href>
          <S:prop>
               <R:bigbox>
                    <R:BoxType>Box type A</R:BoxType>
               </R:bigbox>
               <R:author>
                    <R:Name>Hadrian</R:Name>
               </R:author>
          </S:prop>
          <S:status>HTTP 1.1 200 OK</S:status>
     </S:response>
     <S:response>
          <S:href>http://www.foo.bar/container/index.html</S:href>
          <S:prop>
               <R:bigbox>
                    <R:BoxType>Box type B</R:BoxType>
               </R:bigbox>
          </S:prop>
          <S:status>HTTP 1.1 200 OK</S:status>
     </S:response>
   </S:multistatus>
   In this example, PROPFIND was invoked on the resource without Accept headers.  If the parent
          is INDEXentity,
   http://www.foo.bar/container/ with a Depth header of 1, meaning the value MUST be identical
   request applies to the entity-tag resource and its children, and a Propfind
   header returned by an INDEX on of "allprop", meaning the request should return the name and
   value of all properties defined on each resource.  If no entity-tag
          header is available, this element MUST NOT be defined.

          3.4  INDEX Method

          3.4.1     Problem Description

          A mechanism is needed to discover if

   The resource http://www.foo.bar/container/ has two properties
   defined on it, named http://www.foo.bar/boxschema/bigbox, and
   http://www.foo.bar/boxschema/author, while resource
   http://www.foo.bar/container/index.html has only a single resource
   defined on it, named http://www.foo.bar/boxschema/bigbox, another
   instance of the "bigbox" property type.

8.1.3. Example: Using propname to Retrieve all Property Names

   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Propfind: propname

   HTTP/1.1 200 OK
   Content-Type: text/xml
   Content-Length: xxxx

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
   <?namespace href = "http://www.foo.bar/boxschema/" AS = "R"?>
   <D:multistatus>
     <D:response>
          <D:href>http://www.foo.bar/container/</D:href>
          <D:prop>
               <R:bigbox/>
               <R:author/>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
     <D:response>
          <D:href>http://www.foo.bar/container/index.html</D:href>
          <D:prop>
               <R:bigbox/>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
   </D:multistatus>

   In this example, PROPFIND is a invoked on the collection
          and if so, list its members.

          3.4.2     Solution Requirements

          The solution:
          - must allow resource
   http://www.foo.bar/container/, with a client Propfind header set to discover
   "propname", meaning the members name of a collection
          - must always provide a machine-readable description all properties should be returned.
   Since no depth header is present, it assumes its default value of
   "infinity", meaning the
            membership name of a the properties on the collection
          - must and
   all its progeny should be leveraged as a more general mechanism to provide a
            list of contents for any returned.

   Consistent with the previous example, resource which can profitably return a
            membership like listing.

          3.4.3     The Request
   http://www.foo.bar/container/ has two properties defined on it,
   http://www.foo.bar/boxschema/bigbox, and
   http://www.foo.bar/boxschema/author.  The INDEX method returns resource
   http://www.foo.bar/container/index.html, a machine-readable representation member of the
          membership of "container"
   collection, has only one property defined on it,
   http://www.foo.bar/boxschema/bigbox.

8.2. PROPPATCH

   The PROPPATCH method processes instructions specified in the resource at request
   body to set and/or remove properties defined on the resource
   identified by Request-URI.

          For a collection, INDEX MUST return a list of its members.

   All
          WebDAV DAV compliant resources MUST support the text/xml response
          entity described below.  The INDEX result for a collection MAY
          also return a list of the members of child collections, to any
          depth.

          Collections that respond to an INDEX PROPPATCH method with a text/xml
          entity and
   MUST contain only one ResInfo element.  This ResInfo
          element contains an Href element, which gives the identifier(s)
          of the resource, a Prop element, which gives selected properties
          of process instructions that are specified using the resource,
   propertyupdate, set, and a Members element, which contains a ResInfo
          element for each member remove XML elements of the collection.  The Prop element MUST

          contain at least the following properties, if they are defined
          and available: DisplayName, IsCollection, CreationDate,
          GETentity, and INDEXentity.

          The response from INDEX is cacheable, and SHOULD be accompanied
          by an ETag header (see section 13.3.4 DAV schema.
   Execution of RFC 2068). If GET and
          INDEX return different entities for the same resource state, they
          MUST return different entity tags.

          3.4.4     The Response

          200 (OK) - The server directives in this method is, of course, subject to
   access control constraints.  DAV compliant resources MUST send a machine readable response
          entity which describes support
   the membership setting of arbitrary dead properties.

   The request message body of the resource.

          3.4.5     ResInfo XML Element

          Name:     http://www.ietf.org/standards/dav/resinfo
          Purpose:  Describes a resource.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Value:    Href Prop Members
          Description: There PROPPATCH method MUST be contain at least
   one Href propertyupdate XML element.  Each Href
          element contains a URI for the resource, which  Instruction processing MUST be an
          absolute URI. There occur
   in the order instructions are received (i.e., from top to bottom),
   and MUST be a single Prop element that contains a
          series of properties defined on the resource.  If the resource is
          a collection, it MAY have at most one Members element, which
          describes the members of the collection.

          3.4.6     Members performed atomically.

8.2.1. propertyupdate XML Element element

   Name: http://www.ietf.org/standards/dav/members       propertyupdate
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:  Describes    To contain a request to alter the membership of properties on a collection
   resource.
          Schema:   http://www.ietf.org/standards/dav/
   Parent:   ResInfo
          Value:    ResInfo     None
   Values=     1*(set | remove)
   Description: Contains zero or more ResInfo elements, which
          describe members of the collection.

          3.4.7     Href This XML Element

          Name: http://www.ietf.org/standards/dav/href
          Purpose:  To identify that the content of the element is a URI.
          Schema:   http://www.ietf.org/standards/dav/
          Parent:   Any
          Value:    URI ; See section 3.2.1 of [Fielding et al., 1997]

          3.4.8     Example

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

          HTTP/1.1 200 OK
          Content-Type: text/xml
          Content-Length: xxx
          Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
          ETag: "fooyyybar"

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

          <D:ResInfo>
               <XML:Href>
                    http://www.microsoft.com/user/yarong/dav_drafts/
               </XML:Href>
               <Prop>
                  <DisplayName>
                    WebDAV working drafts directory
                  </DisplayName>
                  <IsCollection>true</IsCollection>
                  <CreationDate>19970418T070304Z</CreationDate>
                  <GETentity>
                    <Content-Type>text/html</Content-Type>
                    <Content-Length>2754</Content-Length>
                    <Content-Language>en</Content-Language>
                    <Last-Modified>
                         Fri, 22 Aug 1997 10:11:26 GMT
                    </Last-Modified>
                    <Etag>"8675309"</Etag>
                  </GETentity>
                  <INDEXentity>
                    <Content-Type>text/xml</Content-Type>
                    <Content-Length>xxx</Content-Length>
                    <Last-Modified>
                         Thu, 11 Sep 1997 23:45:12 GMT
                    </Last-Modified>
                    <Etag>"fooyyybar"</Etag>
                  </INDEXentity>
               </Prop>

               <Members>
                  <ResInfo>
                    <XML:Href>
                    http://www.microsoft.com/user/yarong/dav_drafts/base
                    </XML:Href>
                    <Prop>
                       <IsCollection
               D:PropLoc="http://www.microsoft.com/user/yarong/dav_drafts/b
               ase;props=IsCollection">
                         False
                       </IsCollection>
                       <DisplayName>
                         WebDAV Name Space Operations Draft
                       </DisplayName>
                       <Creation-Date>19970320T230525Z</Creation-Date>

                       <GETentity>
                         <Content-Type>application/msword</Content-Type>
                         <Content-Length>1400</Content-Length>
                         <Content-Language>en</Content-Language>
                         <Last-Modified>
                              Fri, 22 Aug 1997 18:22:56 GMT
                         </Last-Modified>
                         <Etag>"8675309"</Etag>
                       </GETentity>
                    </Prop>
                  </ResInfo>
               </Members>
          </D:ResInfo>

          This example shows the result of the INDEX method applied to container for the
          collection resource
          http://www.microsoft.com/user/yarong/dav_drafts/.  It returns a
          response body in XML format, which gives information about
   required to modify the
          container and its sole member,
          http://www.microsoft.com/user/yarong/dav_drafts/base. The entry properties on the collection confirms that resource.  This XML element
   is multi-valued.

8.2.2. set XML element

   Name:       set
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To set the resource DAV properties specified inside the INDEX was
          executed on is set XML
   element.
   Parent:     propertyupdate
   Values=     prop
   Description: This XML element MUST contain only a collection. prop XML element.
   The result also contains the URI of
          the IsCollection property on elements contained by prop specify the member resource.

          3.5  Behavior name and value of RFC 2068 Methods
   properties that are set on Collections

          With the introduction of the collection resource type to the HTTP
          object model, it Request-URI.  If a property already
   exists then its value is necessary to define replaced.

8.2.3. remove XML element

   Name:       remove
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To remove the behavior of DAV properties specified inside the
          existing methods (defined remove
   XML element.
   Parent:     propertyupdate
   Values=     prop
   Description: Remove specifies that the properties specified in RFC 2068) when invoked on 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.5.1     GET, HEAD for Collections

          The semantics prop
   should be removed.  Specifying the removal of GET are unchanged when applied to a collection,
          since GET property that does
   not exist is defined as, "retrieve whatever information (in the
          form of not an entity) is identified by error.  All the Request-URI" [Fielding et
          al., 1997]. GET when applied to a collection MAY return elements in prop MUST be empty,
   as only the
          contents names of an "index.html" resource, properties to be removed are required.

8.2.4. Response Codes

   200 OK - The command succeeded.  As there can be a human-readable view of
          the contents mixture of the collection, or something else altogether, sets
   and
          hence it is possible the result of removes in a GET on body, a collection will
          bear no correlation 201 Create seems inappropriate.

   403 Forbidden - The client, for reasons the server chooses not to the state
   specify, cannot alter one of the collection.

          Similarly, since the definition of HEAD is a GET without properties.

   405 Conflict - The client has provided a
          response message body, the value whose semantics of HEAD are unmodified when
          applied to collection resources.

          3.5.2     POST
   not appropriate for Collections

          Since by definition the actual function performed by POST is
          determined by the server and often depends on the particular
          resource, the behavior of POST when applied property.  This includes trying to collections cannot
          be meaningfully modified because it set read-
   only properties.

   413 Request Entity Too Long - If a particular property is largely undefined.  Thus
          the semantics of POST are unmodified when applied too long
   to be recorded then a
          collection.

          3.5.3     PUT for Collections

          As defined in composite XML error will be returned
   indicating the offending property.

8.2.5. Example

   PROPPATCH /bar.html HTTP/1.1 specification [Fielding et al., 1997],
   Host: www.foo.com
   Content-Type: text/xml
   Content-Length: xxxx

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
   <?namespace href = "http://www.w3.com/standards/z39.50/" AS = "Z"?>
   <D:propertyupdate>
     <D:set>
          <D:prop>
               <Z:authors>
                    <Z:Author>Jim Whitehead</Z:Author>
                    <Z:Author>Roy Fielding</Z:Author>
               </Z:authors>
          </D:prop>
     </D:set>
     <D:remove>
          <D:prop><Z:Copyright-Owner/></D:prop>
     </D:remove>
   </D:propertyupdate>
   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx

   <?XML version="1.0">
   <?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
   <?namespace href="http://www.w3.com/standards/z39.50/" AS = "Z"?>
   <D:multistatus>
     <D:response>
          <D:prop><Z:Authors/></D:prop>
          <D:status>HTTP/1.1 420 Method Failure</D:status>
     </D:response>
     <D:response>
          <D:prop><Z:Copyright-Owner/></D:prop>
          <D:status>HTTP/1.1 409 Conflict</D:status>
     </D:response>
     <D:responsedescription> Copyright Owner can not be deleted or
   altered.</D:responsedescription>
   </D:multistatus>

   In this example, the "PUT method client requests that the enclosed entity be stored under server to set the supplied Request-URI."  Since submission value of an entity
          representing a collection would implicitly encode creation
   the http://www.w3.com/standards/z39.50/Authors property, and
          deletion of resources, this specification intentionally does to
   remove the property http://www.w3.com/standards/z39.50/Copyright-
   Owner.  Since the Copyright-Owner property could not
          define a transmission format be removed, no
   property modifications occur.  The Method Failure response code for creating a collection using PUT.
          Instead,
   the Authors property indicates this action would have succeeded if
   it were not for the conflict with removing the Copyright-Owner
   property.

8.3. MKCOL Method

   The MKCOL method is defined used to create collections.  If a
          PUT is invoked on new collection. All DAV
   compliant resources MUST support the MKCOL method.

8.3.1. Request

   MKCOL creates a new collection resource it at the location specified by
   the Request-URI.  If the Request-URI exists, then MKCOL must fail.
   During MKCOL processing, a server MUST make the Request-URI a member
   of its parent collection.  If no such ancestor exists, the method
   MUST fail.  When the PUT MKCOL operation creates a new non-collection resource collection
   resource, all ancestors MUST already exist. exist, or the method MUST fail
   with a 409 Conflict status code.  For example, if a request to
   create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/
   exists, the request MUST fail.

   When MKCOL is invoked without a request body, the newly created
   collection has no members.

   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, members of a collection, bodies of members and
   properties on the collections or members.  If all ancestors do the server receives a
   MKCOL request entity type it does not support or understand it MUST
   respond with a 415 Unsupported Media Type status code.  The exact
   behavior of MKCOL for various request media types is undefined in
   this document, and will be specified in separate documents.

8.3.2. Response Codes

   Responses from a MKCOL request are not cacheable, since MKCOL has
   non-idempotent semantics.

   201 Created - The collection or structured resource was created in
   its entirety.

   403 Forbidden - This indicates at least one of two conditions: 1)
   The server does not exist, allow the
          method MUST fail with creation of collections at the given
   location in its namespace, and 2) The parent collection of the
   Request-URI exists but cannot accept members.

   405 Method Not Allowed - MKCOL can only be executed on a
   deleted/non-existent resource.

   409 Conflict status code.  For example,
          if resource /a/b/c/d.html is to - A collection cannot be created and /a/b/c/ made at the Request-URI until
   one or more intermediate collections have been created.

   415 Unsupported Media Type- The server does not
          exist, then support the request MUST fail.

          3.5.3.1   PUT for Non-Collection Resources

          A PUT performed
   type of the body.

   419 Insufficient Space on an existing Resource - The resource replaces does not have
   sufficient space to record the GET response
          entity state of the resource, but MUST NOT change resource after the value
   execution of any dead
          properties defined on the resource.  Live properties defined on

          the resource MAY be recomputed during PUT processing.

          3.5.4     DELETE for Collections

          When DELETE is applied to this method.

8.3.3. Example

   This example creates a collection without internal members called /webdisc/xfiles/ on the collection resource, along with its properties, and external
          members, MUST be deleted.  A DELETE
   server www.server.org.

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

   HTTP/1.1 201 Created

8.4. INDEX Method

   The INDEX method applied is used to enumerate the members of a
          collection resource containing internal member resource.
   All DAV compliant resources MUST
          fail with a 409 Conflict status code.

          3.5.5     DELETE Method for Non-Collection Resources

          If support the DELETE INDEX method is issued to a non-collection resource which
          is an internal member of if they
   have members.

8.4.1. The Request

   For a collection, then during DELETE
          processing a server MUST remove the Request-URI from its parent
          collection. A server MAY remove the URI of INDEX MUST return a deleted resource
          from any collections list of which its members.  All
   WebDAV compliant resources MUST support the resource is an external member.

          3.6  COPY Method

          3.6.1     Problem Description

          Currently, in order to create text/xml response entity
   described below.  The INDEX result for a copy of collection MAY also return
   a resource, list of the client
          must GET an entity and then PUT members of child collections, to any depth.

   Collections that entity respond to the desired
          destination. This requires (1) an INDEX method with a text/xml entity to be transmitted to and
          from
   MUST contain a single multistatus XML element which contains a
   response XML element for each member.

   A resource that supports INDEX MUST return the server and (2) resourcetype property
   for each member.

   Note that the resource be expressible prop XML element MAY contain additional properties.

8.4.2. Example

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

   HTTP/1.1 200 OK
   Content-Type: text/xml
   Content-Length: xxx
   Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
   ETag: _fooyyybar_

   <?XML version="1.0">
   <?namespace href = _http://www.ietf.org/standards/dav/_ as an
          entity with complete fidelity.

          This is problematic because of the network traffic involved in
          making a copy, and because there = _D_?>
   <D:multistatus>
     <D:response>
          <D:href>http://www.microsoft.com/user/yarong/dav_drafts/
          </D:href>
          <D:prop>
               <D:resourcetype>
                    <D:collection/>
               </D:resourcetype>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
     <D:response>
          <D:href>
          http://www.microsoft.com/user/yarong/dav_drafts/base
          </D:href>
          <D:prop>
               <D:resourcetype/>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
   </D:multistatus>

8.5. ADDREF Method

   The ADDREF method is often no way used to fully express
          a resource as an entity without a loss of fidelity.

          3.6.2     Solution Requirements

          The solution:
          - MUST allow a principal add external members to create a copy of a resource
            without having to transmit resource.
   All DAV compliant collection resources MUST support the resource to and from ADDREF
   method.  All other DAV compliant resources MAY support the server.

          3.6.3 ADDREF
   method as appropriate.

8.5.1. The Request

   The COPY ADDREF method creates a duplicate of the source resource, given
          by adds the Request-URI, URI specified in the destination resource, given Collection-Member
   header as an external member to the collection specified by the
          Destination header.
   Request-URI.  The Destination value in the Collection-Member header MUST be present.  The
          exact behavior of the COPY method depends on an
   absolute URI meeting the type requirements of the
          source resource.

          3.6.3.1   COPY for HTTP/1.1 resources

          When the source resource is not a collection, and an external member URI.

   It is not a
          property, an error if the body URI specified in the Collection-Member
   header already exists as an external member of the destination resource collection.
   However, after processing the ADDREF there MUST be octet-for-
          octet identical to the body only one instance
   of the source resource. Alterations
          to URI in the destination resource do not modify collection.  If the source resource.
          Alterations to URI specified in the source resource do not modify
   Collection-Member header already exists as an internal member of the destination
          resource. Thus, all copies are performed "by-value".

          All properties on
   collection, the source resource ADDREF method MUST be duplicated on fail with a 412 Precondition
   Failed status code.

8.5.2. Example

   ADDREF /~ejw/dav/ HTTP/1.1
   Host: www.ics.uci.edu
   Collection-Member: http://www.ietf.org/standards/dav/

   HTTP/1.1 200 OK

   This example adds the
          destination resource, subject to modifying headers, following URI http://www.ietf.org/standards/dav/ as an
   external member resource of the
          definition for copying properties.

          3.6.3.2   COPY for Properties collection
   http://www.ics.uci.edu/~ejw/dav/.

8.6. DELREF Method

   The following section defines how properties on a resource are
          handled during DELREF method is used to remove external members from a COPY operation.
          Live properties SHOULD be duplicated as identically behaving live
          properties at the destination
   resource. Since  All DAV compliant collection resources MUST support the
   DELREF method.  All other DAV compliant resources MUST support the
   DELREF method only if they are live
          properties, support the server determines ADDREF method.

8.6.1. The Request

   The DELREF method removes the syntax and semantics (hence
          value) of these properties.  Properties named by URI specified in the Enforce-
          Live-
          Properties Collection-Member
   header MUST be live on from the destination resource, or collection specified by the method MUST fail.  If Request-URI.

   DELREFing a property URI which is not named by Enforce-
          Live-
          Properties and cannot be copied live, then its value MUST be
          duplicated, octet-for-octet, in an identically named, dead
          resource on the destination resource.

          If a property on the source already exists on the resource and member of the overwrite header collection is set to TRUE then the property at the
          destination not an
   error.  DELREFing an internal member MUST be overwritten fail with a 412
   Precondition Failed status code.

8.6.2. Example

   DELREF /~ejw/dav/ HTTP/1.1
   Host: www.ics.udi.edu
   Collection-Member: http://www.ietf.org/standards/dav/

   HTTP/1.1 200 OK

   This example removes the property URI http://www.ietf.org/standards/dav/, an
   external member resource, from the
          source. If collection
   http://www.ics.uci.edu/~ejw/dav/.

8.7. GET, HEAD for Collections

   The semantics of GET are unchanged when applied to a collection,
   since GET is defined as, _retrieve whatever information (in the overwrite header form
   of an entity) is false and identified by the previous
          situation exists then Request-URI_ [Fielding et al.,
   1997].  GET when applied to a collection MAY return the COPY MUST fail with contents of
   an _index.html_ resource, a 409 Conflict.

          3.6.3.3   COPY for Collections

          A COPY on human-readable view of the contents of
   the collection, or something else altogether, and hence it is
   possible the result of a collection causes GET on a new, empty collection resource will bear no
   correlation to
          be created at the destination with state of the same properties as collection.

   Similarly, since the definition of HEAD is a GET without a response
   message body, the semantics of HEAD are unmodified when applied to
   collection resources.

8.8. POST for Collections

   Since by definition the actual function performed by POST is
   determined by the
          source resource.  All properties server and often depends on the source collection MUST be
          duplicated on particular
   resource, the destination collection, subject behavior of POST when applied to modifying
          headers, following collections cannot be
   meaningfully modified because it is largely undefined.  Thus the definition
   semantics of POST are unmodified when applied to a collection.

8.9. DELETE

8.9.1. DELETE Method for copying properties.  The
          new collection MUST NOT contain any members, internal or
          external.

          3.6.3.4   Type Interactions Non-Collection Resources

   If the destination resource identifies DELETE method is issued to a property and the source non-collection resource which is not
   an internal member of a property, collection, then during DELETE processing a
   server MUST remove the copy SHOULD fail.

          If Request-URI from its parent collection.  A
   server MAY remove the destination URI of a deleted resource identifies from any collections
   of which the resource is an external member.

8.9.2. DELETE for Collections
   The DELETE method on a collection and the
          Overwrite MUST act as if a Depth = Infinity
   header is "true," prior to performing the copy, the
          server was used on it.  A client MUST perform NOT submit a Depth header on a
   DELETE operation on the collection.

          3.6.4     The Response

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

          201 (Created) The source resource was successfully copied.  The
          copy operation resulted collection with any value but Infinity.

   DELETE instructs that the collection specified in the creation of a new resource.

          412 (Precondition Failed) This status code MUST be returned if request-URI,
   the server was unable records of its external member resources, and all its internal
   member resources, are to maintain the liveness be deleted.

   If any member cannot be deleted then all of the properties
          listed in the Enforce-Live-Properties header, or if member's progeny
   MUST NOT be deleted, so as to maintain the Overwrite namespace.

   Any headers included with DELETE MUST be applied in processing every
   resource to be deleted.  In this case, a header of special interest
   is false, and the state of Destroy header, which specifies the destination resource is
          non-null.

          417 (Insufficient Space on Resource) - The destination resource
          does not have sufficient space method to record be used to
   delete all resources in the state scope of the
          resource after DELETE.

   When the execution of this method.

          500 (Server Error) The resource was in such a state that DELETE method has completed processing it could
          not MUST return a
   consistent namespace.

   The response SHOULD be copied. This may occur if the Destination header specifies a resource Multi-Status response that is outside the namespace the resource is able to
          interact with.

          3.6.5     Examples

          3.6.5.1   Overwrite Example

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

          COPY /~fielding/index.html DELETE on each affected resource.

8.9.2.1. Example

   DELETE  /container/ HTTP/1.1
   Host: www.ics.uci.edu
          Destination: http://www.ics.uci.edu/users/f/fielding/index.html www.foo.bar
   Destroy: NoUndelete

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
   <d:multistatus>
     <d:response>
          <d:href>http://www.foo.bar/container/resource1</d:href>
          <d:href>http://www.foo.bar/container/resource2</d:href>
          <d:status>HTTP/1.1 200 OK

          3.6.5.2   No Overwrite Example

          The following OK</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/</d:href>
          <d:status>HTTP/1.1 420 Method Failure</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/resource3</d:href>
          <d:status>HTTP/1.1 412 Precondition Failed</d:status>
     </d:response>
   </d:multistatus>
   In this example shows the same copy operation being
          performed, except with attempt to delete
   http://www.foo.bar/container/resource3 failed because the Overwrite header set server was
   unable to "false."  A
          response guarantee that resource3 would not be able to be
   undeleted.  Consequently, the attempt to delete
   http://www.foo.bar/container/ also failed, but resource1 and
   resource2 were deleted. Even though a Depth header has not been
   included, a depth of 412, Precondition Failed, infinity is returned assumed because the
          destination resource has method is on 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
          Overwrite: "false"

          HTTP/1.1 412 Precondition Failed

          3.7  MOVE Method

          3.7.1     Problem Description

          The move operation
   collection. As this example illustrates, DELETE processing need not
   be atomic.

8.10. PUT

8.10.1. PUT for Non-Collection Resources

   A PUT performed on a an existing resource is replaces the logical equivalent GET response
   entity of the resource.  Properties defined on the resource MAY be
   recomputed during PUT processing.  For example, if a
          copy followed by a delete, where server
   recognizes the actions are performed
          atomically.  Using RFC 2068 methods only, this procedure content type of the request body, it may be able to
   automatically extract information that could be
          performed profitably exposed
   as properties.

   A PUT that would result in several steps. First, the client could issue a GET
          to retrieve a representation creation of a resource, issue a DELETE to
          remove the resource from the server, then use PUT to place the resource on the server without an
   appropriately scoped parent collection MUST fail with a new URI. 405 Method
   Not Allowed.

8.10.2. PUT for Collections

   As is defined in the case for COPY -
          because of HTTP/1.1 specification [Fielding et al., 1997],
   the network traffic involved in making a move, and
          because there is often no way to fully express a resource as "PUT method requests that the enclosed entity be stored under
   the supplied Request-URI."  Since submission of an entity without
   representing a loss collection would implicitly encode creation and
   deletion of fidelity - server move functionality is
          preferable.

          With a WEBDAV server, a principal may accomplish resources, this task by
          issuing specification intentionally does not
   define a COPY and then DELETE. Network load decreases, but the
          server load may still be significant because transmission format for creating a collection using PUT.
   Instead, the server must MKCOL method is defined to create collections.  If a duplicate resource. Were
   PUT is invoked on a server to know beforehand
          that collection resource it MUST fail.

   When the PUT operation creates a new non-collection resource all
   ancestors MUST already exist.  If all ancestors do not exist, the
   method MUST fail with a principal intended 409 Conflict status code.  For example, if
   resource /a/b/c/d.html is to perform COPY be created and DELETE operations
          in succession, it could avoid /a/b/c/ does not exist,
   then the creation of request must fail.

8.11. COPY Method

   The COPY method creates a duplicate
          resource.

          3.7.2     Solution Requirements

          The solution:
          - Must prevent the unneeded transfer of entity bodies from and
            to the server.
          - Must prevent specified resource.  All
   DAV compliant resources MUST support the unneeded creation of copies by COPY method.

   Support for the server.

          3.7.3     The Request

          The move operation on a resource is COPY method does not guarantee the logical equivalent of a ability to copy followed by a delete, where
   resource. For example, separate programs may control resources on
   the actions are performed
          atomically. If same server.  As a resource exists at the destination, the
          destination resource will result, it may not even be DELETEd as possible to copy a side effect of the MOVE
          operation, subject
   resource to a location that appears to be on the restrictions of the overwrite header.

          3.7.4 same server.

8.11.1. The Response

          200 (OK) - Request

   The resource was moved. A successful response must
          contain COPY method creates a duplicate of the Content-Location header, set equal to source resource, 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
          the MOVE method to properly clear their caches.

          412 (Precondition Failed) This status code MUST be returned if present.  The
   exact behavior of the server was unable to maintain COPY method depends on the liveness type of the properties
          listed in the Enforce-Live-Properties header, or if source
   resource.

8.11.1.1. COPY for HTTP/1.1 resources

   When the Overwrite
          header source resource is false, and not a collection the state body of the
   destination resource is
          non-null.

          501 (Not Implemented) - This may occur if MUST be octet-for-octet identical to the Destination header
          specifies a resource which is outside its domain body
   of control
          (e.g., stored on another server) resource and the server either
          refuses or is incapable of moving to an external source resource.

          502 (Bad Gateway) - This may occur when moving  Alterations to external
          resources and the destination server refused to accept resource do
   not modify the source resource.

          3.7.5     Examples

          3.7.5.1   Overwrite Example

          This example shows resource
          http://www.ics.uci.edu/~fielding/index.html being moved  Alterations to the
          location http://www.ics.uci.edu/users/f/fielding/index.html.  The
          contents of source resource
   do not modify the destination resource.  Thus, all copies are
   performed _by-value_.

   All properties on the source 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

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

          3.8  ADDREF Method

          3.8.1     Problem Definition

          There needs to MUST be a way to add an external member duplicated on the
   destination resource, subject to a
          collection.

          3.8.2     Solution Requirements modifying headers, following the
   definition for copying properties.

8.11.1.2. COPY for Properties

   The solution must:
          -    allow access control
          -    allow referencing to URIs of external members
          -    not require following section defines how properties on a body

          3.8.3     The Request

          The ADDREF method adds resource are
   handled during a COPY operation.

   Live properties SHOULD be duplicated as identically behaving live
   properties at the URI specified in destination resource.  Since they are live
   properties, the Collection-Member
          header as an external member to server determines the collection specified syntax and semantics of these
   properties.  Properties named by the
          Request-URI. The value in the Collection-Member Enforce-Live-Properties header
   MUST be an
          absolute URI meeting live on the requirements of an external member URI.

          It destination resource, or the method MUST fail.
   If a property is not named by Enforce-Live-Properties and cannot be
   copied live, then its value MUST be duplicated, octet-for-octet, in
   an error if identically named, dead property on the URI specified in destination resource.

   If a property on the Collection-Member
          header source already exists as an external member of on the collection,
          however, after processing ADDREF there destination
   resource and the Overwrite header is set to "T" then the property at
   the destination MUST be only one instance
          of overwritten with the URI in property from the collection.
   source.  If the URI specified in the
          Collection-Member Overwrite header already exists as an internal member of is "F" and the collection, previous situation
   exists, then the ADDREF method COPY MUST fail with a 412
          Precondition Failed status code.

          3.8.4     Example

          ADDREF /~whitehead/dav/ HTTP/1.1
          HOST: www.ics.udi.edu
          Collection-Member: http://www.ietf.org/standards/dav/

          HTTP/1.1 200 OK

          3.9  DELREF Method

          3.9.1     Problem Definition

          There needs to be 409 Conflict.

8.11.1.3. COPY for Collections

   The COPY method on a way to remove an external member from collection without a
          collection.

          3.9.2     Solution Requirements

          The solution must:
          - allow access control
          - allow referencing to URIs of external members
          - not require Depth header MUST act as
   if a body

          3.9.3     The Request

          The DELREF method removes the URI specified in the Collection-
          Member Depth = infinity header from the collection specified by the Request-URI.

          DELREFing was included.  A client MAY submit a URI which is not
   Depth header on a member COPY on a collection with a value of "0" or
   "infinity".  DAV compliant servers MUST support the "0" and
   "infinity" behaviors.

   A COPY of depth infinity instructs that the collection is not an
          error. DELREFing an specified in
   the Request-URI, the records of its external member resources, and
   all its internal member MUST fail with a 412
          Precondition Failed status code.

          3.9.4     Example

          DELREF /~whitehead/dav/ HTTP/1.1
          Host: www.ics.udi.edu
          Collection-Member: http://www.ietf.org/standards/dav/

          HTTP/1.1 200 OK

          3.10 PATCH Method

          3.10.1    Problem Definition

          At present, if a principal wishes resources, are to be copied to modify a resource, they must
          issue a GET against location
   relative to the resource, modify their local copy Destination header.

   A COPY of depth "0" only instructs that the
          resource, collection, the
   properties, and then issue its external members, not its internal members, are
   to be copied.

   Any headers included with a PUT COPY are to place the modified be applied in processing
   every resource on to be copied.

   The exception to this rule is the server. Destination header. This procedure is inefficient because header
   only specifies the entire
          entity destination for a resource must be transmitted to and from the server
          in order to make even small changes.  Ideally, the update entity
          transmitted Request-URI.  When applied to
   members of the server should be proportional collection specified in size to the
          modifications.

          3.10.2    Solution Requirements

          The solution must:
          -    allow partial modification request-URI the value of a resource without having
   Destination is to
               transmit the entire modified resource
          -    allow byte-range patching
          -    allows extensions so that patches can be done beyond simple
               byte-range patching
          -    allow ranges modified to be deleted, inserted, and replaced

          3.10.3    The Request

          The request entity of reflect the PATCH method contains a list of
          differences between current location in the resource identified by
   hierarchy.  So, if the Request-URI request-URI is "a" and the desired content destination is "b"
   then when a/c/d is processed it MUST use a destination of b/c/d.

   When the resource after the PATCH action COPY method has been applied.  The list of differences is in completed processing it MUST have created a format defined
          by
   consistent namespace at the media type of destination.  Thus if it is not possible
   to COPY a collection with internal members, the entity (e.g., "application/diff") and
          must include sufficient information internal members may
   still be copied but a collection will have to allow be created at the server
   destination to
          convert contain them.

   The response is a Multi-Status response that describes the original version result of
   the COPY on each affected resource.  The response is given for the
   resource that was to the desired
          version.  Processing performed by PATCH is atomic, hence all
          changes MUST be successfully executed or the method fails. PATCH
          MUST fail if executed on a non-existent resource; i.e. PATCH does copied, not create a the resource that was created as
   a side effect.

          If result of the request appears (at least initially) to be acceptable, copy.  In other words, each entry indicates whether
   the
          server MUST transmit an interim 100 response message after
          receiving copy on the empty line terminating resource specified in the request headers href succeeded or failed
   and
          continue processing the request.  Since the semantics of PATCH
          are non-idempotent, responses why.

   The exception to this method are not cacheable.

          While server support for PATCH rule is optional, for errors that occurred on the
   destination.  For example, if a server does
          support PATCH, it MUST support at least the text/xml diff format
          defined below.  Support for destination was locked the VTML difference format [VTML] is
          recommended, but not required.

          3.10.4    text/xml elements for PATCH

          The resourceupdate XML element contains
   response would indicate the destination URL and a set of XML sub-entities
          that describe modification operations.  The name 421 Destination
   Locked error.

8.11.1.4. Type Interactions

   If the destination resource identifies a collection and meaning of
          these XML elements the
   Overwrite header is given below. Processing of these directives
          MUST be performed in _T_, prior to performing the order encountered within copy the XML
          document.  A directive operates server
   MUST perform a DELETE operation on the resource as modified by
          all previous directives (executed in sequential order). The
          length of the resource MAY be extended or reduced by a PATCH. collection.

8.11.2. Response Codes

   200 OK - The changes specified by the resourceupdate XML element MUST be
          executed atomically.

          3.10.4.1  ResourceUpdate

          Name:     http://www.ietf.org/standards/dav/patch/resourceupdate
          Purpose:       Contains an ordered set of changes source resource was successfully copied to a non-
          collection, non-property pre-
   existing destination resource.
          Schema:        http://www.ietf.org/standards/dav/patch/
          Parent:        Any
          Value:         *(Insert | Delete | Replace)

          3.10.4.2  Insert

          Name:     http://www.ietf.org/standards/dav/patch/insert
          Purpose:       Insert the XML element’s contents starting at the
          specified octet.
          Schema:        http://www.ietf.org/standards/dav/patch/
          Parent:        ResourceUpdate
          Value:

   201 Created - The insert XML element MUST contain an Octet-Range
          XML element that specifies an octet position within source resource was successfully copied.  The copy
   operation resulted in the body creation of a new resource.  A value of "end" specifies

   412 Precondition Failed - This status code MUST be returned if the end of
   server was unable to maintain the resource.
          The body liveness of the insert XML element contains the octets to be
          inserted.

          Please note that properties listed
   in order to protect the white Enforce-Live-Properties header, or if the Overwrite header is
   "F", and the state of the destination resource is non-null.

   419 Insufficient Space on Resource - The destination resource does
   not have sufficient space contained in
          this XML element to record the following attribute/value MUST be included
          in state of the element: XML-SPACE = "PRESERVE".

          3.10.4.3  Delete

          Name:     http://www.ietf.org/standards/dav/patch/delete
          Purpose:       Removes resource after
   the specified range execution of octets.
          Schema:        http://www.ietf.org/standards/dav/patch/
          Parent:        ResourceUpdate
          Value:         The Delete XML element MUST contain an octet-range
          XML element.

          Discussion: this method.

   421 Destination Locked _ The octets that are deleted are removed, which means
          the destination resource is collapsed was locked and
   either a valid Lock-Token header was not submitted, or the length of Lock-
   Token header identifies a lock held by another principal.

   500 Server Error - The resource was in such a state that it could
   not be copied.  This may occur if the Destination header specifies a
   resource that is
          decremented by outside the size of namespace the octet range.  It resource is not
          appropriate able to
   interact with.

8.11.3. Overwrite Example

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being copied to replace deleted octets 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 of octets with the
   location http://www.ics.uci.edu/users/f/fielding/index.html.  The
   contents of the XML element.  If the number of octets in the XML

          element is different from the number of octets specified, 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. 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

   HTTP/1.1 200 OK

8.11.4. No Overwrite Example

   The contents of following example shows the entity are same copy operation being performed,
   except with the replacement
          octets.

          Please note that in order Overwrite header set to protect the white space contained in
          this XML element the following attribute/value MUST be included
          in the element: XML-SPACE = "PRESERVE".

          3.10.4.5  Octet-Range Attribute

          Name:          http://www.ietf.org/standards/dav/patch/octet-
          range
          Purpose:  Specifies a range _F._  A response of octets that 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 412
   Precondition Failed is returned because the octet contains destination resource has
   a single number then the operation 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
   Overwrite: _F_

   HTTP/1.1 412 Precondition Failed

8.11.5. Collection Example

   COPY /container/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Enforce-Live-Properties: *
   Depth: Infinity
   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
   <d:multistatus>
     <d:response>
          <d:href>http://www.foo.bar/othercontainer/resource1</d:href>
          <d:href>http://www.foo.bar/othercontainer/resource2</d:href>
          <d:href>http://www.foo.bar/othercontainer/</d:href>
          <d:href>http://www.foo.bar/othercontainer/R2/D2</d:href>
          <d:status>HTTP/1.1 201 Created</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
          <d:status>HTTP/1.1 412 Precondition Failed</d:status>
     </d:response>
   </d:multistatus>

   The Depth header is to begin at that octet and
          to continue for a length specified by the operation. In unnecessary as the case default behavior of COPY on a delete, this would mean
   collection is to delete act as if a single octet. "Depth: Infinity" header had been
   submitted.  In the
          case of an insert this would mean to begin the insertion at the
          specified octet and to continue for the length example most of the included
          value, extending the resource if necessary. In the case of
          replace, resources, along with the replace begins at
   collection, were copied successfully. However the specified octet and overwrites
          all that follow collection R2
   failed, most likely due to the length of the included value.

          3.10.5    The Response

          200 (OK) - The request entity body a problem with enforcing live properties.
   R2's member D2 was processed without error,
          resulting in an update successfully copied.  As a result a collection
   was created at www.foo.bar/othercontainer/R2 to contain D2.

8.12. MOVE Method

   The move operation on a resource is the state logical equivalent of a copy
   followed by a delete, where the resource.

          409 (Conflict) - If actions are performed atomically.
   All DAV compliant resources MUST support the update information in MOVE method.

   However, support for the request message
          body MOVE method does not make sense given guarantee the current state ability
   to move a resource to a particular destination. For example,
   separate programs may actually control different sets of resources
   on the same server.  Therefore, it may not even be possible to move
   a resource
          (e.g., an instruction within a namespace that appears to delete belong to the same
   server.

8.12.1. The Request

   If a non-existent line), this status
          code MAY resource exists at the destination, the destination resource
   will be returned.

          415 (Unsupported Media Type) - The server does not support DELETEd as a side effect of the
          content type MOVE operation, subject to
   the restrictions of the update instructions Overwrite header.

8.12.2. MOVE for Collections

   MOVE instructs that the collection specified in the request message
          body.

          416 (Unprocessable Entity) - A new status code.  The server
          understands Request-URI, the content type
   records of the request entity, but was
          unable its external member resources, and all its internal
   member resources, are to be moved to a location relative to process the contained instructions.

          417 (Insufficient Space on Resource) -
   Destination header.

   The MOVE method on a collection MUST act as if a Depth "infinity"
   header was used on it.  A client MUST NOT submit a Depth header on a
   MOVE on a collection with any value but "infinity".

   Any headers included with MOVE are to be applied in processing every
   resource does not have
          sufficient space to record be moved.

   The exception to this rule is the state Destination header.  The behavior
   of this header is the resource after same as given for COPY on collections.

   When the
          execution of this method.

          3.10.6    Examples

          3.10.6.1  HTML file modification

          The following example shows MOVE method has completed processing it MUST have created a modification of
   consistent namespace on both the title source and
          contents of destination, creating
   collections at 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: text/xml
               Content-Length: xxx

                                             HTTP/1.1 100 Continue
               <?XML:Namespace href =
               Shttp://www.ietf.org/standards/dav/patch/" AS = "D"/>
               <D:ResourceUpdate>
                    <Replace XML-SPACE = "PRESERVE"><octet-range>14</octet-
               range>&003CTITLE&003ENew Title&003C/TITLE&003E</Replace>
                    <Delete><octet-range>38-50</Delete>
               <Insert XML-SPACE = "PRESERVE"><octet-range>86</>&
               003CP&003ENew paragraph&003C/P&003E</Insert>
               </D:ResourceUpdate>
                                             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    Destination Header

          The Destination header specifies a source or destination resource for
          methods such as COPY and necessary.

   As specified in the definition of MOVE, which take two URIs as parameters.
               Destination= "Destination" ":" URI

          3.11.2    Enforce-Live-Properties Header a MOVE of a collection over
   another collection causes the destination collection and all its
   members to be deleted.

   The Enforce-Live-Properties header specifies properties response is a Multi-Status response that MUST
          be "live" after they are copied (moved) to describes the destination
          resource result of a copy (or move). If
   the value "*" MOVE on each effected resource.  The response is given for the
          header, then it designates all live properties on
   resource that was to be moved, not the source
          resource.  If resource that was created as
   a result of the value is "Omit" then move.  In other words, each entry indicates whether
   the server MUST NOT
          duplicate move on the destination resource any properties specified in the href succeeded or failed
   and why.

   The exception to this rule is for errors that are
          defined occurred on the source resource. If
   destination.  For example, if the destination was locked the
   response would indicate the destination URL and a 421 Destination
   Locked error.

8.12.3. Response Codes

   200 OK - The move operation was successful.

   409 Conflict _ The MOVE was attempted on a collection with members.
   While the COPY part of this header is not included
          then operation could succeed the DELETE could
   not.  Therefore the MOVE MUST fail.

   412 Precondition Failed - This status code MUST be returned if the
   server is expected was unable to act as defined by maintain the default
          property handling behavior liveness of the associated method.

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

          3.11.3 properties listed
   in the Enforce-Live-Properties header, or if the Overwrite Header header is
   "F", and the state of the destination resource is non-null.

   421 Destination Locked - The Overwrite destination resource was locked and
   either a valid Lock-Token header specifies whether was not submitted, or the Lock-
   Token header identifies a lock held by another principal.

   502 Bad Gateway - This may occur when the destination is

                                                           o
                                                            n another
   server should
          overwrite and the state of a non-null destination resource during a
          COPY or MOVE.  A value of "false" states that the server MUST NOT
          perform refuses to accept the COPY or MOVE operation if resource

8.12.4. Overwrite Example

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

   MOVE /~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 200 OK

8.12.5. Collection Example

   MOVE /container/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Enforce-Live-Properties: *
   Overwrite: False
   Lock-Token: <OpaqueLockToken:xxxx> <OpaqueLockToken:xxxx>

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
   <d:multistatus>
     <d:response>
          <d:href>http://www.foo.bar/container/resource1</d:href>
          <d:href>http://www.foo.bar/container/resource2</d:href>
          <d:href>http://www.foo.bar/container/</d:href>
          <d:href>http://www.foo.bar/container/C2/R2</d:href>
          <d:status>HTTP/1.1 201 Created</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/C2</d:href>
          <d:status>HTTP/1.1 420 Method Failure</d:status>
     <d:response>
          <d:href>http://www.foo.bar/othercontainer/C2</d:href>
          <d:status>HTTP/1.1 409 Conflict</d:status>
     </d:response>
   </d:multistatus>

   In this example the value of
          Overwrite is "true," and a client MAY omit this header from has submitted a
          request when its value is "true." While number of lock tokens
   with the Overwrite header
          appears request.  A lock token will need to duplicate be submitted for every
   resource, both source and destination, anywhere in the functionality scope of the If-Match: * header
   method, that is locked.  In this case the proper lock token was not
   submitted for the destination http://www.foo.bar/othercontainer/C2.
   This means that the resource continer/c2 could not be moved,
   although its child container/C2/R2 could be moved.

8.13. LOCK Method

   The following sections describe the LOCK method, which is used to
   take out a lock of HTTP/1.1, If-Match applies any access type.  These sections on the LOCK
   method describe only those semantics that are specific to the Request-URI, LOCK
   method and not to are independent of the Destination access type of a COPY or MOVE.

               Overwrite = "Overwrite" ":" ("true" | "false")

          If there is a conflict the lock being
   requested.  Once the general LOCK method has been described,
   subsequent sections describe the semantics of the "write" access
   type, and the Overwrite write lock.

8.13.1. Operation

   A LOCK method invocation creates the lock specified by the Lock-Info
   header equals "true", or
          is absent and thus defaults to "true", then on the Request-URI.  Lock method MUST fail
          with requests SHOULD have a 409 Conflict.

          3.11.4    Destroy Header

          When deleting XML
   request body which contains an Owner XML element for this lock
   request. The LOCK request MAY have a resource the client often wishes Timeout header.

   A successful response to specify
          exactly what sort a lock invocation MUST include Lock-Token
   and Timeout headers.  Clients MUST assume that locks may arbitrarily
   disappear at any time, regardless of delete is being enacted. The Destroy header,
          used with the Mandatory header, allows the client to specify value given in the
          end result they desire. Timeout
   header.  The Destroy Timeout header is specified as
          follows:

          The Undelete token requests that, only indicates the behavior of the
   server if possible, "extraordinary" circumstances do not occur.  For example,
   an administrator may remove a lock at any time or the resource
          should be left system may
   crash in a state such a way that it can be undeleted. The
          server is not required to honor this request.

          The NoUndelete token requests that loses the resource record of the lock's
   existence. The response MUST NOT be left also contain the value of the
   lockdiscovery property in a state such that it can be undeleted. prop XML element.

8.13.2. The VersionDestroy token includes Effect of Locks on Properties and Collections

   By default the functionality scope of a lock is the
          NoUndelete token entire state of the resource,
   including its body and extends it to include having associated properties.  As a result, a lock
   on a resource also locks the resource's properties, and a lock on a
   property may lock a property's resource or may restrict the server
          remove all versioning references ability
   to lock the resource that it has
          control over.

               DestroyHeader = "Destroy" ":" #Choices

          Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | token
          |"<" URI ">" ; property's resource.  Only a single lock token extension MUST NOT be
   used unless it is
          specified in a RFC16, otherwise when a URI MUST be used for
          extensions.

          3.11.5    Collection-Member Header

          The Collection-Member header specifies the URI of an external
          resource lock extends to be added/deleted to/from cover both a collection.

               CollectionMember = "Collection-Member" ":" URI

          3.12 Links

          3.12.1    Source Link Property Type

          Name:     http://www.ietf.org/standards/dav/link/source
          Purpose:       The destination of the source link identifies the resource and its
   properties.  Note that contains the unprocessed source of certain lock types MAY override this
   behavior.

   For collections, a lock also affects the link’s
          source.

          Schema:        http://www.ietf.org/standards/dav/link/
          Parent:        Any
          Value:         An XML document with zero ability to add or more link XML
          elements.

          Discussion: remove
   members.  The source nature of the link (src) is typically effect depends upon the URI type of access
   control involved.

8.13.3. Locking Replicated Resources

   Some servers automatically replicate resources across multiple URLs.
   In such a circumstance the output resource on which the link is defined, and there is
          typically server MAY only accept a lock on one destination (dst) of
   the link, which is the
          URI where URLs if the unprocessed source of server can guarantee that the resource may be accessed.
          When more than one link destination exists, this specification
          asserts no policy on ordering.

          4    State Tokens

          4.1  Overview

          4.1.1     Problem Description

          There are times when a principal lock will want to predicate
          successful execution of a method on be honored
   across all the current state of a
          resource.  While HTTP/1.1 provides a mechanism URLs.

8.13.4. Locking Multiple Resources

   The LOCK method supports locking multiple resources simultaneously
   by allowing for conditional
          execution the listing of methods using entity tags via several URIs in the "If-Match" and
          "If-None-Match" headers, LOCK request.
   These URIs, in addition to the mechanism is not sufficiently
          extensibleto express conditional statements involving more
          generic state indicators, such Request-URI, are then to be locked as lock tokens.
   a result of the LOCK method's invocation.  When multiple resources
   are specified the LOCK method only succeeds if all specified
   resources are successfully locked.

   The fundamental issue with entity tags is Lock-Tree option of the lock request specifies that they can only the resource
   and all its internal children (including internal collections, and
   their internal members) are to be
          generated locked.  This is another mechanism
   by which a resource. However there are times when request for a client
          will want to lock on multiple resources can be able
   specified.

   Currently existing locks can not be extended to share state tokens between cover more or less
   resources,
          potentially on different servers, as well as be able and any request to generate
          certain types expand or contract the number of
   resources in a lock tokens without first having to communicate MUST fail with a server.

          For example, a principal may wish to require that resource B have
          a certain state in order 409 Conflict status code. So,
   for a method to successfully execute on example, if resource A. If A is exclusively write locked and then the client submits an e-tag from resource B
   same principal asks to
          resource exclusively write lock resources A, then B, and C,
   the request will fail as A has no way of knowing is already locked and the lock can not be
   extended.

   A successful result will return a single lock token which represents
   all the resources that have been locked.  If an UNLOCK is executed
   on this token, all associated resources are unlocked.

   If the e-tag is meant lock cannot be granted to describe resource B.

          Another example occurs when all resources, a principal wishes to predicate the
          successful completion of 409 Conflict
   status code MUST be returned with a method on response entity body containing
   a multistatus XML element describing which resource(s) prevented the absence
   lock from being granted.

8.13.5. Interaction with other Methods

   The interaction of any locks on a resource. It LOCK with various methods is not sufficient to submit an "If-None-Match: *"
          as this refers to dependent upon the existence of an entity, not
   lock type.  However, independent of lock type, a lock.

          This draft defines the term "state token" as an identifier for a
          state successful DELETE
   of a resource. resource MUST cause all of its locks to be removed.

8.13.6. Lock Compatibility Table

   The sections table below define requirements for
          state tokens and provide a  state token syntax, along with two
          new headers which can accept describes 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 behavior that
          upon inspecting occurs when a state token it lock
   request 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 to accept tokens from
          other servers and potentially made on a resource.

   Current lock state/      Shared Lock       Exclusive
   Lock request                               Lock
   None                     True              True
   Shared Lock              True              False
   Exclusive Lock           False             False*
   Legend: True = lock MAY be able to coordinate state

          information cross resource and cross site through standardized
          protocols. For example, granted.  False = lock MUST NOT be
   granted.  *=if the execution principal requesting the lock is the owner of a request on resource A
          can the
   lock, the lock MAY be predicated on the regranted.

   The current lock state of a resource B, where A is given in the leftmost
   column, and B lock requests are
          potentially on different servers.

          Client Generable. The state token syntax must allow, when
          appropriate, for clients to generate a state token without having listed in the first communicated with a server.

          One drawback row.  The
   intersection of entity tags is that they are set by the server,
          and there is no interoperable algorithm for calculating an entity
          tag. Consequently, a client cannot generate an entity tag from a
          particular state row and column gives the result of a resource.  However, a state token which
          encodes an MD5 state hash could be calculated by lock request.
   For example, if a client based shared lock is held on a client-held state of a resource, and then submitted to a
          server in a conditional method invocation.

          Another potential use for client generable state tokens an
   exclusive lock is for a
          client to generate requested, the table entry is _false_, indicating
   the lock tokens with wild card fields, and hence
          be able to 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 not be applicable to all requests.
          Positive and Negative. Conditional expressions must allow for granted.

   If an exclusive or shared lock is re-requested by the
          expression of both positive and negative state requirements.

          4.2  State Token Syntax
          State tokens are URLs employing principal who
   owns the lock, the lock MUST be regranted.  If the lock is
   regranted, the same lock token that was previously issued MUST be
   returned.

8.13.7. Owner XML Element

   Name:       owner
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Provide information about the principal taking out a
   lock.
   Parent:     Any
   Values:          XML Elements
   Descripton: The Owner XML element provides information sufficient
   for either directly contacting a principal (such as a telephone
   number or Email URI), or for discovering 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 principal (such as the
   URL of RFC 2068

          This proposal has created a new URL scheme for state tokens
          because homepage) who owns a state token names lock.

8.13.8. Lock Response

   A successful lock response MUST contain a network resource using its normal
          name, which is typically state-invariant, along with additional
          information that specifies Lock-Token response
   header, a particular state of the resource.
          Encoding Timeout header and a prop XML element in the state information into response body
   which contains the native URL scheme value of the
          network lockdiscovery property.

8.13.9. Response Codes

   409 Conflict - The resource is locked, so the method has been
   rejected.

   412 Precondition Failed - The included Lock-Token was not felt to be safe, since freedom from name
          space collisions
   enforceable on this resource or the server could not be guaranteed. If this proposal is
          accepted, satisfy the StateToken URL scheme will need to be defined and
          registered with IANA.

          State Token URLs begin with
   request in the URL scheme name "StateToken"
          rather than Lock-Info header.

8.13.10. Example - Simple Lock Request

   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Lock-Info: LockType=Write LockScope=Exclusive
   Timeout: Infinite; Second-4100000000
   Content-Type: text/xml
   Content-Length: xyz

   <?XML version="1.0">
   <?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:owner>
      <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
   </D:owner>

   HTTP/1.1 200 OK
   Lock-Token: opaquelocktoken:xyz122393481230912asdfa09s8df09s7df
   Timeout: Second-604800
   Content-Type: text/xml
   Content-Length: xxxxx

   <?XML version="1.0">
   <?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:prop>
     <D:lockdiscovery>
          <D:activelock>
               <D:locktype>write</D:locktype>
               <D:lockscope>exclusive</D:lockscope>
               <D:addlocks/>
               <D:owner>
                    <D:href>
                    http://www.ics.uci.edu/~ejw/contact.html
                    </D:href>
               </D:owner>
               <D:timeout>Second-604800</D:timeout>
               <D:locktoken>
                    <D:href>
               opaquelocktoken:xyz122393481230912asdfa09s8df09s7df
                    </D:href>
               </D:locktoken>
          </D:activelock>
     </D:lockdiscovery>
   </D:prop>

   This example shows the name successful creation 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 the owner of the particular state lock.  The server has an activity-

   based timeout policy in place on this resource, which causes the
   lock to automatically be removed after 1 week (604800 seconds).  The
   response has a Lock-Token header that gives the lock token type they
          represent in order to make the URL self describing. Thus it is
          possible to examine that
   uniquely identifies the URL and know, at lock created by this lock request.

8.13.11. Example - Multi-Resource Lock Request

   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Lock-Info: LockType=Write LockScope=Exclusive
   Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/blah>
   Timeout: Infinite, Second-4100000000

   <?XML version="1.0">
   <?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:href>http://www.ics.uci.edu/~ejw/contact.html<D:href>

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
   <D:multistatus>
     <D:response>
          <D:href>
               http://webdav.sb.aol.com/workspace/webdav/proposal.doc
          </D:href>
          <D:href>
               http://webdav.sb.aol.com/workspace/webdav/
          </D:href>
          <D:status>HTTP/1.1 202 Accepted</D:status>
     </D:response>
     <D:response>
          <D:href>http://foo.bar/blah</D:href>
          <D:status>HTTP/1.1 403 Forbidden</D:status>
     </D:response>
   </D:multistatus>

   This example shows a minimum, request for an exclusive write lock on three
   resources, http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
   http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah.  In
   this request, the client has specified that it is desires an infinite
   length lock, if available, otherwise a
          state token.

          Labeled name/value pairs are used within the token to allow new
          fields to be added. Processors timeout of state tokens MUST be prepared
          to accept the fields in whatever order they are present and MUST
          ignore any fields they do not understand. 4.1 billion
   seconds, if available.  The "Type" Owner header field specifies the type of the state web
   address for contact information
          encoded in the state token. A URL is used in order to avoid
          namespace collisions.

          The "Res" field identifies the resource for which the state token

          specifies a particular state. Since commas and spaces are
          acceptable URL characters, a caret is used to delimit a URL.
          Since a caret is an acceptable URL character, any instances of it
          must be escaped using principal taking out the % escape convention.

          The State-Info production is expanded upon in descriptions of
          specific state token types, and is intended to contain
   lock.

   This lock request has failed, because the state
          description information server rejected the lock
   request for 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 http://foo.bar/blah.  The 409 Conflict status code
   indicates that the server was unable to satisfy the If-Match header defined in section 14.25 request because
   there is a conflict between the state of
          RFC 2068.

          If the AND keyword is used resources and all of the state tokens identify
   operation named in the state of request.  Within the resource, then multistatus, the server MAY perform 202
   Accepted status code indicates that the
          requested method. If lock method was accepted by
   the OR keyword is used resources, and any of the state
          tokens identifies would have been completed if all resources named
   in the current state of request were able to be locked.  The 403 Forbidden status
   code indicates that the resource, then server
          MAY perform does not allow lock requests on this
   resource.

8.14. UNLOCK Method
   The UNLOCK method removes the requested method.  If neither of lock identified by the keyword
          requirements is met, lock token in
   the server MUST NOT perform Lock-Token header from the requested
          method, Request-URI, and all other resources
   included in the lock.

   Any DAV compliant resource which supports the LOCK method 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 ">")
   support the UNLOCK method.

8.14.1. Example

   UNLOCK /workspace/webdav/info.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Lock-Token:opaquelocktoken:123AbcEfg1284h23h2

   HTTP/1.1 200 OK

   In this example, the lock identified by the lock token
   "opaquelocktoken:123AbcEfg1284h23h2" is successfully removed from
   the resource http://webdav.sb.aol.com/workspace/webdav/info.doc.  If
   this lock included more than just one resource, the lock was removed
   from those resources as well.

8.15. PATCH Method

   The If-None-State-Match header PATCH method is intended to have similar
          functionality used to modify parts of the If-None-Match header defined entity returned in section
          14.26
   the response to a GET method.  DAV compliant resources MAY support
   the PATCH method.

8.15.1. The Request

   The request entity of RFC 2068.

          If any the PATCH method contains a list of
   differences between the state tokens identifies resource identified by the current state Request-URI and
   the desired content of the
          resource, resource after the server MUST NOT perform PATCH action has been
   applied.  The list of differences is in a format defined by the requested method.
          Instead, if
   media type of the request method was GET, HEAD, INDEX, or GETMETA, entity (e.g., "application/diff") and must include
   sufficient information to allow the server SHOULD respond with a 304 (Not Modified) response,
          including to convert the cache-related entity-header fields (particularly
          ETag) original
   version of the current state of resource to the resource.  For desired version.  Processing
   performed by PATCH is atomic.  Hence all other
          request methods, changes MUST be
   successfully executed or the server method fails.  PATCH MUST respond with fail if
   executed on a status of 412
          (Precondition Failed). non-existent resource; i.e., PATCH does not create a
   resource as a side effect.

   If none of the state tokens identifies the current state of the
          resource, request appears (at least initially) to be acceptable, the
   server MAY perform MUST transmit an interim 100 response message after receiving
   the requested method.

          Note that empty line terminating the "AND" request headers and "OR" keywords specified with continue
   processing the If-
          State-Match header request.  Since the semantics of PATCH are non-
   idempotent, responses to this method are intentionally not cacheable.

   While server support for PATCH is optional, if a server does support
   PATCH, it MUST support at least the text/xml diff format defined
   below.  Support for If-None-
          State-Match, because this functionality the VTML difference format [VTML] is
   recommended, but 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
          to the etag header defined in section 14.20

8.15.2. text/xml elements for PATCH

   The resourceupdate XML element contains a set of RFC 2068. XML sub-entities
   that describe modification operations.  The
          purpose name and meaning of
   these XML elements are given below.  Processing of these directives
   MUST be performed in the tag is to return state tokens defined order encountered within the XML document.
   A directive operates on a the resource as modified by all previous
   directives (executed in a response. sequential order).  The contents length of the state-token are not
          guaranteed to
   resource MAY be exhaustive and are generally used to return extended or reduced by a
          new state token that has been defined as PATCH.

   The changes specified by the result of a method.
          For example, if a LOCK method were successfully resourceupdate XML element MUST be
   executed on a
          resource the response would include atomically.

8.15.2.1. resourceupdate XML Element

   Name:       resourceupdate
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Contains an ordered set of changes to a state token header with non-collection,
   non-property resource.
   Parent:     None
   Value=      *(insert | delete | replace)

8.15.2.2. insert XML Element

   Name:       insert
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Insert the
          lock state token included.

          4.5  E-Tags
          E-tags have already been deployed using XML element's contents starting at the 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 expressed using quoted strings and
   specified octet.
   Parent:     resourceupdate
   Value:      The insert XML element MUST contain an octet-range XML
   attribute that specifies an octet position within the If-Match and If-None-
          Match headers.

          5    Locking

          5.1  Locking: Introduction

          Locking is used to arbitrate access to body of a resource amongst
          principals that have equal access rights to that
   resource.

          This specification allows locks to vary over two parameters,  A value of _end_ specifies the
          number end of principals involved and the type resource.  The
   body of access the insert XML element contains the octets to be
          granted. Furthermore, inserted.

   Please note that in order to protect the white space contained in
   this document only provides XML element the definition
          of locking for one access type, write. However, following attribute/value MUST be included in
   the syntax element: XML-SPACE = "PRESERVE". This attribute is
          extensible, and allows defined in
   the XML specification [Bray, Sperberg-McQueen, 1997].

8.15.2.3. delete XML Element

   Name:       delete
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Removes the specified range of other access types.

          5.1.1     Exclusive Vs. Shared Locks octets.
   Parent:     resourceupdate
   Value:      The most basic form of lock is delete XML element MUST contain an exclusive lock. This is a lock
          where the access right in question is only granted to a single
          principal. octet-range XML
   attribute.

   Discussion: The need for this arbitration results from a desire to
          avoid having to constantly merge results. In fact, many users so
          dislike having to merge that they would rather serialize their
          access to a resource rather than have to constantly perform
          merges.

          However, there are times when the goal of a lock is not to
          exclude others from exercising an access right but rather to
          provide a mechanism for principals to indicate that they intend
          to exercise their access right.  Shared locks are provided for
          this case. A shared lock allows multiple principals to receive a
          lock, hence any principal with appropriate access can get the
          lock.

          With shared locks there are two trust sets octets that affect a
          resource.  The first trust set is created by access permissions.
          Principals who are trusted, for example, may have permission to
          write the resource, those who deleted are not, don't.  Among those who
          have access permission to write removed, which means the resource,
   resource is collapsed and the set length of
          principals who have taken out a shared lock also must trust each
          other, creating a (typically) smaller trust set within the access
          permission write set.

          Starting with every possible principal on the Internet, in most
          situations resource is decremented
   by the vast majority size of these principals will the octet range.  It is not have
          write access appropriate to replace
   deleted octets with zeroed-out octets, since zero is a given resource.  Of valid octet
   value.

8.15.2.4. replace XML Element

   Name:       replace
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Replaces the specified range of octets with the contents
   of the XML element.  If the small number who do
          have write access, some principals may decide to guarantee their
          edits are free of octets in the XML element is
   different from overwrite conflicts by using exclusive write
          locks. Others may decide they trust their collaborators (the
          potential set the number of collaborators being octets specified, the set update MUST be
   rejected.
   Parent:     resourceupdate
   Value:      The replace XML element MUST contain an octet-range XML
   attribute.  The contents of principals who
          have write permission) and use the entity are the replacement octets.

   Please note that in order to protect the white space contained in
   this XML element the following attribute/value MUST be included in
   the element: XML-SPACE = "PRESERVE"
                                     .

                                       This attribute is defined in the
   XML specification [Bray, Sperberg-McQueen, 1997].

8.15.2.5. octet-range Attribute

   Name:       octet-range
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Specifies a shared lock, which informs their

          collaborators range of octets that the enclosing property
   affects.
   Parent:     insert | delete | replace
   Value:      number [_-_ (number | _end_)]
               Number = 1*Digit

   Description: Octet numbering begins with 0.  If the octet contains a principal is potentially working on
   single number then the
          resource.

          The WebDAV extensions operation is to HTTP do not need begin at that octet and to provide all of the
          communications paths necessary
   continue for principals to coordinate their
          activities.  When using shared locks, principals may use any out
          of band communication channel to coordinate their work (e.g.,
          face-to-face interaction, written notes, post-it notes on a length specified by the
          screen, telephone conversation, email, etc.)  The intent operation.  In the case of a
          shared lock is
   delete, this would mean to let collaborators know who else is potentially
          working on delete a resource.

          Shared locks are included because experience from web distributed
          authoring systems has indicated that exclusive write locks are
          often too rigid.  An exclusive write lock is used single octet.  In the case of an
   insert this would mean to enforce a
          particular editing process: take out exclusive write lock, read begin the resource, perform edits, write insertion at the resource, release specified octet
   and to continue for the
          lock.  What happens if length of the lock isn't released?  While included value, extending the time-
          out mechanism provides one solution,
   resource if you need to force necessary.  In the
          release case of a lock immediately, it doesn't help much.  Granted, an
          administrator can release replace, the lock for you, but this could become
          a significant burden for large sites. In addition there is replace begins
   at the
          problem specified octet and overwrites all that an administrator may not be immediately available.

          Despite their potential problems, exclusive write locks are
          extremely useful, since often a guarantee follow to the length
   of freedom from
          overwrite conflicts is what is needed. the included value.

8.15.3. Response Codes

   200 OK - The tradeoff described request entity body was processed without error,
   resulting in
          this specification is to provide exclusive write locks, but also an update to provide a less strict mechanism in the form state of shared locks
          which can be used by a set the resource.

   409 Conflict - If the update information in the request message body
   does not make sense given the current state of people who trust each other and who
          have access the resource (e.g.,
   an instruction to delete a communications channel external to HTTP which
          can non-existent line), this status code MAY
   be used to negotiate writing to the resource.

          5.1.2     Required Support

          A WebDAV compliant returned.

   415 Unsupported Media Type - The server is does not required to support locking the content
   type of the update instructions in
          any form. If the server request message body.

   418 Unprocessable Entity - The entity body submitted with the PATCH
   was not understood by the resource.

   419 Insufficient Space on Resource - The resource does support locking it may choose not have
   sufficient space to
          support any combination record the state of exclusive and shared locks for any
          access types. the resource after the
   execution of this method.

8.15.4. HTML file modification Example

   The reason following example shows a modification of the title and contents
   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:

   PATCH hello.html HTTP/1.1
   Host: www.example.org
   Content-Type: text/xml
   Content-Length: xxx

                                        HTTP/1.1 100 Continue

   <?XML version="1.0">
   <?namespace href = _http://www.ietf.org/standards/dav/patch/_ AS =
   _D_?>
   <D:resourceupdate>
     <D:replace XML-SPACE = "PRESERVE">
          <D:octet-range>14</D:octet-range>&003CTITLE&003ENew
   Title&003C/TITLE&003E</D:replace>
     <D:delete><D:octet-range>38-50</D:octet-range></D:delete>
     <D:insert XML-SPACE = "PRESERVE"><D:octet-range>86</D:octet-
   range>&003CP&003ENew paragraph&003C/P&003E</D:insert>
   </D:resourceupdate>

                                        HTTP/1.1 200 OK

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

9. HTTP Headers for this flexibility Distributed Authoring

9.1. Collection-Member Header

   CollectionMember = "Collection-Member" ":" URI   ; URI is that server implementers have
          said that they are willing to accept minimum requirements on all
          services but locking. Locking policy strikes to defined in
   section 3.2.1 of [Fielding et al., 1997]

   The Collection-Member header specifies the very heart URI of
          their an external
   resource management and versioning systems and they require
          control over what sort of locking will to be made available. For
          example, some systems only support shared write locks while
          others only provide support for exclusive write locks while yet
          others use no locking at all. As each system is sufficiently
          different added/deleted to/from a collection.

9.2. DAV Header

   DAV = "DAV" ":" ("1" | "2" | extend)

   This header indicates that the resource supports the DAV schema and
   protocol to merit exclusion of certain locking features, the
          authors are proposing that locking be allowed as level indicated.  All DAV compliant resources MUST
   return the sole axis of
          negotiation within WebDAV.

          5.2  LOCK Method DAV header on all OPTIONS responses.

9.3. Depth Header

   Depth = "Depth" ":" ("0" | "1" | "infinity")

   The following sections describe the LOCK method, which Depth header is used to
          take out a lock of any access type.  These sections with methods executed on collections to
   indicate whether the LOCK method describe is to be applied only those semantics that are specific to the
          LOCK method and are independent of the access type of the lock
          being requested.  Once collection
   (Depth = 0), to the general LOCK method has been
          described, subsequent sections describe collection and its immediate children, (Depth =
   1), or the semantics of collection and all its progeny (Depth = infinity).  Note
   that Depth = 1 and Depth = infinity behavior only applies to
   internal member resources, and not to external member resources.

   The Depth header is only supported if a method's definition
   explicitly provides for such support.

   The following rules are the
          "write" access type, and default behavior for any method that
   supports the write lock.

          5.2.1     Operation depth header. A LOCK method invocation creates the lock specified MAY override these defaults by
   defining different behavior in its definition.

   Methods which support the Lock-
          Info depth header MAY choose not to support all
   of the header's values and MAY define, on a case by case basis, the
   behavior of the Request-URI. Lock method requests SHOULD NOT
          have on a request body. A user-agent SHOULD submit an Owner collection if a depth header
          field with is not
   present. For example, the MOVE method only supports Depth = infinity
   and if a lock request.

          A successful response to depth header is not present will act as if a lock invocation Depth =
   infinity header had been applied.

   Clients MUST include Lock-
          Token and Time-Out headers.

          5.2.2     The Effect NOT rely upon methods executing on members of Locks their
   hierarchies in any particular order or the execution being atomic.
   Note that methods MAY provide guarantees on Properties ordering and Containers

          By default the scope of atomicity.

   Upon execution, a lock is the entire state method with a depth header will perform as much of the
          resource, including
   its body assigned task as possible and associated properties. As then return a
          result, response specifying
   what it was able to accomplish and what it failed to do.

   So, for example, an attempt to COPY a lock hierarchy may result in some
   of the members being copied and some not.

   Any headers on a method with a depth header MUST be applied to all
   resources in the scope of the method. For example, an if-match
   header will have its value applied against every resource also locks in the resource's
          properties,
   method's scope and will cause the method to fail if the header fails
   to match.

   If a lock on a property may lock a property's
          resource resource, source or may restrict destination, within the ability to lock scope of the property's
          resource. Only method
   is locked in such a single way as to prevent the successful execution of
   the method, then the lock token for that resource MUST be used when a lock
          extends to cover both submitted
   with the request in the Lock-Token request header.

9.4. Destination Header

   Destination = "Destination" ":" URI

   The Destination header specifies a destination resource for methods
   such as COPY and its properties. Note MOVE, which take two URIs as parameters.

9.5. Destroy Header

   DestroyHeader = "Destroy" ":" #Choices

   Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | extend

   Extend = RFC-Reg | Coded-URL

   RFC-Req = Token ; This is a token value (defined in section 2.2 of
   [Fielding et al., 1997]) that
          certain lock types MAY override this behavior.

          For containers, has been published as an RFC.

   Coded-URL = "<" URI ">"

   When deleting a lock also affects resource the ability client often wishes to add or remove
          members. The nature specify exactly
   what sort of delete should be performed.  The Destroy header, used
   with the effect depends upon the type of access
          control involved.

          5.2.3     Locking Replicated Resources

          Some servers automatically replicate resources across multiple
          URLs. In such a circumstance Mandatory header, allows the server MAY only accept a lock on
          one of client to specify the URLs end
   result it desires.  The Destroy header is specified as follows:

   The Undelete token requests that, if possible, the server resource should
   be left in a state such that it can guarantee be undeleted.  The server is not
   required to honor this request.

   The NoUndelete token requests that the resource MUST NOT be left in
   a state such that the lock will it can be
          honored across all the URLs.

          5.2.4     Locking Multiple Resources undeleted.

   The LOCK method supports locking multiple resources
          simultaneously by allowing for VersionDestroy token includes the listing functionality of several URIs in the
          LOCK request. These URIs, in addition
   NoUndelete token and extends it to include having the Request-URI, are
          then server remove
   all versioning references to the resource that it has control over.

9.6. Enforce-Live-Properties Header

   EnforceLiveProperties = "Enforce-Live-Properties_ _:" (_*_ | "Omit"
   | 1*(Property-Name))

   Property-Name = Coded-URL

   The Enforce-Live-Properties header specifies properties that MUST be locked as a result
   _live_ after they are copied (moved) to the destination resource of
   a copy (or move).  If the LOCK method's invocation.
          When multiple resources are specified value _*_ is given for the LOCK method only
          succeeds if header, then it
   designates all specified resources are successfully locked.

          The Lock-Tree option of live properties on the lock request specifies that source resource.  If the value
   is "Omit" then the server MUST NOT duplicate on the destination
   resource and all its internal children (including internal
          collections, and their internal members) any properties that are to be locked. This
          is another mechanism by which a request for a lock defined on multiple
          resources can be specified.

          Currently existing locks can the source resource.  If
   this header is not be extended to cover more or
          less resources, and any request included then the server is expected to expand or contract act as

   defined by the number default property handling behavior of resources the associated
   method.

9.7. If-None-State-Match

   If-None-State-Match = "If-None-State-Match" ":" 1#Coded-URL

   The If-None-State-Match header is intended to have similar
   functionality to the If-None-Match header defined in a lock MUST fail section 14.26
   of RFC 2068.  However the if-none-state-match header is intended for
   use with any URI which represents state information about a 409 Conflict status code.
          So, for example, if resource A is exclusively write locked and
          then the same principal asked
   resource, referred to exclusively write lock resources
          A, B, and C, the request would fail as a state token.  A typical example is already locked and
          the lock can not be extended.

          A successful result will return a single lock token which
          represents all the resources that have been locked. If an UNLOCK
          is executed on this token, all associated resources are unlocked.
   token.

   If any of the lock can not be granted to all resources, a 406 Conflict
          status code state tokens identifies the current state of the
   resource, the server MUST be returned with a response entity body
          containing a multiresponse XML element describing which
          resource(s) prevented NOT perform the lock from being granted.

          5.2.5     Interaction requested method.
   Instead, if the request method was GET, HEAD, INDEX, or PROPFIND,
   the server SHOULD respond with other Methods

          The interaction of a LOCK with various methods is dependent upon 304 Not Modified response,
   including the lock type. However, independent of lock type, a successful
          DELETE cache-related entity-header fields (particularly ETag)
   of a resource MUST cause all the current state of its locks to be removed.

          5.2.6     Lock Compatibility Table

          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  For all other 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
   methods, the principal requesting server MUST respond with a status of 412 Precondition
   Failed.

   If none of the lock is state tokens identifies the owner current state of the lock,
   resource, the lock server MAY be regranted.

          The current lock state perform the requested method.

   If any of a resource the tokens is given in not recognized then the leftmost
          column, method MUST fail
   with a 412 Precondition Failed.

   Note that the "AND" and lock requests are listed in "OR" keywords specified with the first row. If-State-
   Match header are intentionally not defined for If-None-State-Match,
   because this functionality is not required.

9.8. If-State-Match

   If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#Coded-URL

   The
          intersection of a row and column gives If-State-Match header is intended to have similar functionality
   to the result If-Match header defined in section 14.25 of RFC 2068.
   However the If-State-Match header is intended for use with any URI
   which represents state information about a lock
          request.  For example, if a shared lock resource.  A typical
   example is held on a resource,
          and an exclusive lock is requested, token.

   If the table entry AND keyword is "false",
          indicating used and all of the lock must not be granted.

          If an exclusive or shared lock is re-requested by state tokens identify the principal
          who owns
   state of the lock, resource, then the lock MUST be regranted. server MAY perform the requested
   method.  If the lock OR keyword is
          regranted, used and any of the same lock token that was previously issued MUST be
          returned.

          5.2.7     Status Codes

          409 "Conflict" - The resource is locked, so state tokens
   identifies the method has been
          rejected.

          412 "Precondition Failed" - The included state-token was not
          enforceable on this resource or current state of the resource, then the server MAY
   perform the requested method.  If the request in keyword requirement for the lock-info
          header could
   the keyword used is not be satisfied by met, the server.

          5.2.8     Lock-Info Request Header

          The Lock-Info request header specifies server MUST NOT perform the scope
   requested method, and type of a
          lock for MUST return a LOCK method request. The syntax specification below 412 Precondition Failed
   response.

   If any of the tokens is
          extensible, allowing new type and scope identifiers to be added. not recognized then the method MUST fail
   with a 412 Precondition Failed.

9.9. Lock-Info Request Header

   LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope [SP
   AdditionalLocks] [SP Lock-Tree]
   DAVLockType = "LockType" "=" DAVLockTypeValue
   DAVLockTypeValue = ("Write" | *(uchar | reserved)) Extend)
   DAVLockScope = "LockScope" "=" DAVLockScopeValue
   DAVLockScopeValue = ("Exclusive" |"Shared" | *(uchar | reserved)) Extend)
   AdditionalLocks = "AddLocks" "=" 1*("<" URI ">")
   Lock-Tree = "Lock-Tree" "=" ("True" ("T" | "False") "F")

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

   The LockType field specifies the access type of the lock.  At
   present, this specification only defines one lock type, the "Write"
   lock.  The LockScope field specifies whether the lock is an
   exclusive lock, or a shared lock.  The AddLocks field specifies
   additional URIs, beyond the Request-URI, to which the lock request
   applies.  The LockTree field is used to specify recursive locks.  If
   the LockTree field is "true", the lock "T", the lock request applies to the hierarchy
   traversal of the internal member resources of the Request-URI, and
   the AddLocks URIs, inclusive of the Request-URI and the AddLocks
   URIs.  It is not an error if LockTree is "T", and the Request-URI or
   the AddLocks URIs have no internal member resources.  By default,
   the value of LockTree is "F", and this field MAY be omitted when its
   value is "F".

9.10. Lock-Token Request Header

   Lock-Token = "Lock-Token" ":" 1#Coded-URL

   The Lock-Token request header, containing a lock token owned by the
   requesting principal, is used by the principal to indicate that the
   principal is aware of the existence of the lock specified by the
   lock token.

   If the following conditions are met:

   1) The method is restricted by a lock type that requires the
   submission of a lock token, such as a write lock,
   2) The user-agent has authenticated itself as a principal,
   3) The user-agent is submitting a method request applies to a resource on
   which the hierarchy traversal of principal owns a write lock,

   Then:

   1) The method request MUST include a Lock-Token header with the internal
          members lock
      token, or,
   2) The method MUST fail with a 409 Conflict status code.

   If multiple resources of the Request-URI, and the AddLocks URIs,
          inclusive of the Request-URI and the AddLocks URIs. It is not an
          error if LockTree is true, and the Request-URI are involved with a method, such as a COPY or
   MOVE method, then the AddLocks
          URIs have no internal member resources. By default, the value of
          LockTree is "false", and this field MAY lock tokens, if any, for all involved
   resources, MUST be omitted when its value
          is false.

          5.2.9     Owner Request Header

          5.2.9.1   Problem Description

          When discovering included in the list of owners of locks Lock-Token request header.

   For example, Program A, used by user A, takes out a write lock on a resource,
   resource.  Program A then makes a
          principal may want to be able to contact number of PUT requests on the owner directly. For
          this to be possible
   locked resource.  All the lock discovery mechanism must provide
          enough information for requests contain a Lock-Token request
   header that includes the write lock owner to be contacted.
          Additionally, programs may wish state token.  Program B, also
   run by User A, then proceeds to be able perform a PUT to record structured
          information in the owner header locked
   resource.  However, program B was not aware of the existence of the
   lock and so that other programs may be
          able does not include the appropriate Lock-Token request
   header.  The method is rejected even though principal A is
   authorized to parse perform the PUT.  Program B can, if it later. Note, however, that these programs may
          not necessarily be coordinating so there need be no guarantee
          that chooses, now
   perform lock discovery and obtain the information can be parsed.

          5.2.9.2   Solution Requirements

          Not all systems have authentication procedures lock token.  Note that provide
          sufficient information
   programs A and B can perform GETs without using the Lock-Token
   header because the ability to identify a particular user in perform a way
          that GET is meaningful to not affected by a person. In addition, many systems that do
          have sufficient information, such as
   write lock.

   Having a name and e-mail address,
          do lock token provides no special access rights.  Anyone can
   find out anyone else's lock token by performing lock discovery.
   Locks are to be enforced based upon whatever authentication
   mechanism is used by the server, not have based on the ability to associate this information with secrecy of the
          lock discovery mechanism. Therefore
   token values.

9.11. Lock-Token Response Header
   Lock-Token = "Lock-Token" ":" Coded-URL

   If a means resource is needed to allow
          principals to provide authentication in successfully locked then a manner which Lock-Token header will
   be
          meaningful to a person. returned containing the lock token that represents the lock.

9.12. Overwrite Header

   Overwrite = "Overwrite" ":" ("T" | "F")

   The From Overwrite header (defined in RFC 2068), which contains only an
          email mailbox, is not sufficient for specifies whether the server should overwrite
   the purposes state of quick
          identification. When desperately looking for someone to remove a
          lock, e-mail is often not sufficient. non-null destination resource during a COPY or MOVE.
   A telephone number (cell
          number, pager number, etc.) would be better. Furthermore, value of _F_ states that the
          email address in server MUST NOT perform the From header only optionally includes COPY or
   MOVE operation if the
          owners name and that name state of the destination resource is non-null.
   By default, the value of Overwrite is often set to an alias anyway.
          Therefore _T,_ and a client MAY omit
   this header more flexible than From is required.

          The from a request when its value also needs is _T._ While the
   Overwrite header appears to be such that both man and machine can
          place values in it duplicate the functionality of the If-
   Match: * header of HTTP/1.1, If-Match applies only to the Request-
   URI, and later retrieve those values.

          5.2.9.3   Syntax

          Owner = "Owner" ":" (Coded-XML  | quoted-string)
          Coded-XML = field-content    ; XML where any character which is not legal in field-content (see section 4.2 of [Fielding et al.,
          1997]) is XML encoded

          The XML SHOULD provide information sufficient for either directly
          contacting to the principal (such as Destination of a telephone number COPY or e-mail
          URI), MOVE.

   If a COPY or for discovering the principal (such as MOVE is not performed due to the URL value of a
          homepage) who owns the lock. The quoted string SHOULD provide a
          means for directly contacting the principal who owns Overwrite
   header, the lock,

          such as method MUST fail with a name and telephone number.

          5.2.10    Time-Out 409 Conflict status code.

9.13. Propfind Request Header

          5.2.10.1  Problem Description

          In a perfect world principals take out locks, work on the
          resource, and then remove the lock when it is no longer needed.
          However, this process

   Propfind = "Propfind" ":" ("allprop" | "propname" | RFC-Reg |
   1*(Property-Name))

   The Propfind header is frequently not completed, leaving active
          but unused locks. Reasons for this include client programs
          crashing and losing information about locks, users leaving used to specify which properties are to be
   returned in a PROPFIND method.  The properties are identified by
   their
          systems URIs.  Two special tokens are defined for use with the day
   Propfind header, allprop and forgetting to remove their locks, etc. As
          a result of this behavior, servers need propname.  The allprop token specifies
   that all property names and values on the resource are to establish a policy by
          which they can remove be
   returned.  The propname token specifies that only a lock without input from list of property
   names on the lock owner.
          Once such a policy is instituted, resource are to be returned.

9.14. Status-URI Response Header

   The Status-URI response header MAY be used with the server also needs a
          mechanism 102 Processing
   response code to inform the principal of the policy.

          5.2.10.2  Solution Requirements

          There are two basic lock removal policies: administrator and time
          based removal. In client as to the case status of administrator based removal, a
          principal other than method.

   Status-URI = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status-
   Code is defined in 6.1.1 of [Fielding et al., 1997]

   The URIs listed in the lock owner has sufficient access rights
          to order header are source resources which have been
   affected by the lock removed, even though they did not take it out. outstanding method.  The second policy type is time based removal.  In this case, a
          timer is set as soon as status code indicates the
   resolution of the lock is created. Every time a method
          is executed on any resource covered by the lock, the timer identified resource.  So, for
   example, if a MOVE method on a collection is
          reset. If the timer runs out, the lock outstanding and a 102
   "Processing" response with a Status-URI response header is removed.

          User-agents MUST assume that locks may arbitrarily disappear at
          any time. If their actions require confirmation of returned,
   the existence
          of a lock then included URIs will indicate resources that have had move
   attempted on them and what the If-State headers are available.

          5.2.10.3  Syntax result was.

9.15. Timeout Header
   TimeOut = "Time-Out" "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Extend) Other)
   DAVTimeOutVal = 1*digit
          Extend
   Other = RFC-Reg | URL "-" Token ; The URL format is used for
          unregistered TimeTypes
          RFC-Req = Token Extend field-value   ; This is a TimeType that has been published as
          an See section 4.2 of RFC 2068

   Clients MAY include TimeOut Timeout headers in their LOCK requests.
          However
   However, the server is not required to honor or even consider the
          request. these
   requests.  Clients MUST NOT submit a Time-Out Timeout request header with any
   method other than a LOCK method.

   A Time-Out Timeout request header MUST contain at least one TimeType and MAY
   contain multiple TimeType entries. The purpose of listing multiple
   TimeType entries is to indicate multiple different values and value
   types that are acceptable to the client.  The client lists the
   TimeType entries in order of preference.

   The Time-Out Timeout response header MUST use a Second value, Infinite, or a
   TimeType the client has indicated familiarity with.  The server MAY
   assume a client is familiar with any TimeType submitted in a Time-Out Timeout
   header.

   The "Second" _Second_ TimeType specifies the number of seconds that MUST
   elapse between granting of the lock at the server, and the automatic
   removal of the lock.  A server MUST not generate a time
          out timeout value for "Second"
   _Second_ greater than 2^32-1.

   The time out timeout counter is restarted any time an owner of the client lock sends
   a method to any member of the lock, including unsupported methods,
   or methods which are unsuccessful.  It is recommended that the HEAD
   method be used when the goal is simply to restart the time
          out timeout
   counter.

   If the timeout expires then the lock is lost.  Specifically the
   server SHOULD act as if an UNLOCK method was executed by the server
   on the resource using the lock token of the timed-out lock,
   performed with its override authority. Thus logs,
          notifications, and other mechanisms that act as side effects to
          the granting and removal of a lock will logs should be properly informed as
          to updated
   with the disposition of the lock. lock, notifications should be sent,
   etc., just as they would be for an UNLOCK request.

   Servers are advised to pay close attention to the values submitted
   by clients, as they will be indicative of the type of
          activity the client intends to perform. For example, an applet
          running in a browser may need to lock a resource, but because of
          the instability of the environment within which the applet is
          running, the applet may be turned off without warning. As a
          result, the applet is likely to ask for a relatively small time-
          out value so that if the applet dies, the lock can be quickly
          harvested. However a document management system is likely to ask
          for an extremely long time-out because its user may be planning
          on going off-line.

          5.2.11    Lock Response

          A successful lock response MUST contain a Lock-Token response
          header, a Time-Out header and a PROP element in the response body
          which contains the value of the LockDiscovery property.

          5.2.11.1  Lock-Token Response Header

          If a resource is successfully locked then a lock-token header
          will be returned containing the lock token that represents the
          lock.

          Lock-Token = "Lock-Token" ":" URI

          5.2.12    Example - Simple Lock Request

          LOCK /workspace/webdav/proposal.doc HTTP/1.1
          Host: webdav.sb.aol.com
          Lock-Info: LockType=Write LockScope=Exclusive
          Time-Out: Infinite; Second-4100000000
          Owner: <?XML:Namespace href="http://www.ietf.org/standards/dav/"
          AS =
          "D"/><D:HREF>http://www.ics.uci.edu/~ejw/contact.html</D:HREF>

          HTTP/1.1 200 OK
          Lock-Token: OpaqueLockToken:xyz122393481230912asdfa09s8df09s7df08
          sd0f98a098sda
          Time-Out: Second-604800
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace

               href ="http://www.ietf.org/standards/dav/" AS = "D"/>
          <D:Prop>
               <lockdiscovery>
                    <activelock>
                         <locktype>write</locktype>
                         <lockscope>exclusive</lockscope>
                         <addlocks/>
                         <owner>
               <HREF>http://www.ics.uci.edu/~ejw/contact.html</HREF>
                         </owner>
                         <timeout>Second-604800</timeout>
                         <locktoken>
                              <HREF>
                         OpaqueLockToken:xyz122393481230912asdfa09s8df09s7d
                         f08sd0f98a098sda
                              </HREF>
                         </locktoken>
                    </activelock>
               </lockdiscovery>
          </D:Prop>

          This example shows the successful creation 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 the owner type of activity the lock. The server has
   client intends to perform.  For example, an
          activity-based timeout policy applet running in place on this a
   browser may need to lock a resource, but because of the instability
   of the environment within which
          causes the lock to automatically applet is running, the applet
   may be removed after 1 week (604800
          seconds). The response has turned off without warning.  As a Lock-Token header that gives result, the
          state token URL applet is
   likely to ask for a relatively small timeout value so that if the
   applet dies, the lock token generated by this lock
          request.

          5.2.13    Example - Multi-Resource Lock Request

          LOCK /workspace/webdav/proposal.doc HTTP/1.1
          Host: webdav.sb.aol.com
          Lock-Info: LockType=Write LockScope=Exclusive
          Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/bla
          h>
          Time-Out: Infinite, Second-4100000000
          Owner: <http://www.ics.uci.edu/~ejw/contact.html>

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

          <?XML:Namespace href =
               "http://www.ietf.org/standards/dav/" As = "D"/>
          <D:MultiResponse>
               <Response>
                    <HREF>
                    http://webdav.sb.aol.com/workspace/webdav/proposal.doc
                    </HREF>
                    <HREF>
                    http://webdav.sb.aol.com/workspace/webdav/
                    </HREF>
                    <Status>HTTP/1.1 202 Accepted</Status>
               </Response>
               <Response>
                    <HREF>http://foo.bar/blah</HREF>
                    <Status>HTTP/1.1 403 Forbidden</Status>
               </Response>
          </D:MultiResponse>

          This example shows can be quickly harvested.  However, a request document
   management system is likely to ask for an exclusive write lock extremely long timeout
   because its user may be planning on three
          resources,
          http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
          http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah.  In
          this request, the client has specified that it desires an
          infinite length lock, if available, otherwise going off-line.

10. Response Code Extensions to HTTP/1.1

   The following response codes are added to those defined in HTTP/1.1
   [Fielding et al., 1997].

10.1. 102 Processing

   Methods can potentially take a timeout long period of 4.1
          billion seconds, if available.  The Owner header field specifies time to process,
   especially methods that support the web address for contact information for Depth header.  In such cases the principal taking
          out
   client may time-out the lock.

          This lock request has failed, because connection while waiting for a response.  To
   prevent this the server rejected the
          lock request for http://foo.bar/blah.  The 409 Conflict status MAY return a 102 response code indicates to indicate
   to the client that the server was unable to satisfy is still processing the request
          because there method.

   If a method is taking longer than 20 seconds (a reasonable, but
   arbitrary value) to process the server SHOULD return a conflict between 102
   "Processing" response.

10.2. 207 Multi-Status

   The response requires providing status for multiple independent
   operations.

10.3. 418 Unprocessable Entity

   The server understands the state content type of the resources
          and the operation named in request entity, but
   was unable to process the request.  Within contained instructions.

10.4. 419 Insufficient Space on Resource

   The resource does not have sufficient space to record the
          multiresponse, state of
   the 202 Accepted status code indicates that resource after the
          lock execution of this method.

10.5. 420 Method Failure

   The method was accepted by not executed on a particular resource within its
   scope because some part of the resources, and would have been
          completed if all resources named in method's execution failed causing the request were able
   entire method to be
          locked. aborted.  For example, if a resource could not
   be moved as part of a MOVE method, all the other resources would
   fail with a 420 Method Failure.

10.6. 421 Destination Locked

   The 403 Forbidden status code indicates that destination resource of a method is locked, and either the server
          does
   request did not allow lock requests on this resource.

          5.3  Write Lock

          This section describes the semantics specific to contain a valid Lock-Info header, or the write access
          type for locks.  The write Lock-Info
   header identifies a lock held by another principal.

11. Multi-Status Response

   The default 207 Multi-Status response body is a specific instance of text/xml HTTP entity
   that contains a lock
          type, single XML element called multistatus, which
   contains a set of XML elements called response, one for each 200,
   300, 400, and is 500 series status code generated during the only lock type described method
   invocation.  100 series status codes MUST NOT be recorded in this specification.

          5.3.1     Methods Restricted by Write Locks

          A write lock prevents a principal without
   response XML element.

11.1. multistatus XML Element

   Name:       multistatus
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains multiple response messages.
   Parent:     Any
   Value:      1*response [responsedescription]
   Description: The responsedescription at the lock from
          successfully executing top level is used to
   provide a PUT, POST, PATCH, PROPPATCH, MOVE,
          DELETE, MKCOL, ADDREF or DELREF on general message describing the locked resource. All other
          current methods, GET in particular, function independent overarching nature of the
          lock.

          Note, however, that as new methods are created
   response.  If this value is available an application MAY use it will be
          necessary to specify how they interact with a write lock.

          5.3.2     Write Locks and Properties

          While those without a write lock may not alter a property on
   instead of presenting the individual response descriptions contained
   within the responses.

11.2. response XML Element

   Name:       response
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Holds a
          resource it is still possible for single response
   Parent:     multistatus
   Value:      href [prop] status [responsedescription]
   Description: Prop MUST contain one or more empty XML elements
   representing the values names of live properties.  Multiple properties
          to change, even while locked, due to may be
   included if the requirements of their
          schemas. Only dead properties and live properties defined to
          respect locks are guaranteed same response applies to not change while write locked. them all.  If a property href is write locked used
   then a LOCK request on the
          associated resource MUST fail response refers to a problem with the referenced resource,
   not a property.

11.3. status XML Element

   Name:       status
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Holds a single HTTP status-line
   Parent:     response
   Value:      status-line   ;status-line defined in [Fielding et al.,
   1997]

11.4. responsedescription XML Element

   Name:       responsedescription
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains a 409 "Conflict". Note message that a
          write lock on a property MAY can be extended displayed to include the
          associated resource without user
   explaining the principal having explicitly
          requested nature of the extension.

          5.3.3     Write Locks and Null Resources

          It is possible response.
   Parent:     multistatus | response
   Value:      Any
   Description: This XML element provides information suitable to be
   presented to assert a write lock on user.

12. Generic DAV XML Elements

12.1. href XML Element

   Name:       href
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To identify that the content of the element is a null resource in order URI.
   Parent:     Any
   Value:      URI ; See section 3.2.1 of [Fielding et al., 1997]

12.2. link XML Element

   Name:       link
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To identify a property as a link and to lock contain the name. Please note, however,
   source and destination of that locking a null
          resource effectively makes the resource non-null as link.
   Values=     1*src 1*dst
   Description: Link is used to provide the resource
          now has lock related properties defined on it.

          5.3.4     Write Locks sources and Collections

          A write lock on destinations of
   a collection prevents the addition or removal link.  The type of
          members the property containing the link XML element
   provides the type of the collection. As a consequence, when a principal
          issues link.  Link is a request multi-valued element, so
   multiple Links may be used together to create a new internal member indicate multiple links with
   the same type.

12.2.1. src XML Element

   Name:       src
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To indicate the source of a collection
          using PUT or POST, or to remove an existing internal member link.
   Parent:     link
   Values=     URI

12.2.2. dst XML Element

   Name:       dst
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To indicate the destination of a
          collection using DELETE, link
   Parent:     link
   Values=     URI

12.2.3. Example

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
   <?namespace href = "http://www.foocorp.com/Project/" AS = "F"?>
   <D:prop>
     <D:Source>
          <D:link>
               <F:projfiles>Source</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/main.c</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Library</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/main.lib</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Makefile</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/makefile</D:dst>
          </D:link>
     </D:Source>
   </D:prop>

   In this request MUST fail if the principal
          does not have a write lock on example the collection.

          However, if a write lock request is issued to resource http://foo.bar/program has a collection
          containing internal member resources source
   property that contains three links.  Each link contains three
   elements, two of which, src and dst, are currently locked, part of the request MUST fail with a 409 Conflict status code.

          5.3.5     Write Locks DAV schema
   defined in this document, and COPY/MOVE

          The owner of a write lock MUST NOT execute a MOVE method on a
          resource they have locked. This specification intentionally does
          not define what happens if a MOVE method request one which is made on a
          locked resource defined by the lock's owner. schema
   http://www.foocorp.com/project/ (Source, Library, and Makefile).  A COPY method invocation MUST NOT duplicate any write locks
          active on
   client which only implements the source.

          5.3.6     Re-issuing Write Locks

          If a principal already owns a write lock on a resource, any
          future requests for elements in the same type of write lock, on DAV spec will not
   understand the same
          resource, while foocorp elements and will ignore them, thus seeing
   the principal's previous write lock is in effect,
          MUST result in a successful response 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 same lock token as
          provided for links.  This example demonstrates
   the currently existing lock. Two lock requests are
          defined power of XML markup that allows for element values to be identical if their Lock-Info headers are identical.

          5.3.7     Write Locks and The State-Token Header

          5.3.7.1   Problem Definition

          If
   enhanced without breaking older clients.

12.3. prop XML element

   Name:       prop
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains properties related to a user agent resource.
   Parent:     Any
   Values:     XML Elements
   Description: The prop XML element is not required to have knowledge about a lock
          when requesting an operation generic container for
   properties defined on a locked resource, resources.  All elements inside prop MUST
   define properties related to the following
          scenario might occur. Program A, run by User A, takes out resource.  No other elements may be
   used inside of a write
          lock prop element.

13. DAV Properties

13.1. creationdate Property

   Name:       creationdate
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    The time and date the resource was created.
   Value:      The time and date MUST be given in ISO 8601 format
   [ISO8601]
   Description: This property SHOULD be defined on all DAV compliant
   resources.  If present, it contains a resource. Program B, also run by User A, has no
          knowledge timestamp of the lock taken out by Program A, yet performs a PUT
          to moment when
   the locked resource. In this scenario, resource was created (i.e., the PUT succeeds
          because locks are associated with a principal, not a program, and
          thus program B, because moment it is acting with principal A’s
          credential, is allowed to perform the PUT. However, had program B
          known about non-null state).

13.2. displayname Property
   Name:       displayname
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    A name for the lock, it would not have overwritten resource that is suitable for
   presentation to a user.
   Value:      Any valid XML character data (as defined in [Bray,
   Sperberg-McQueen, 1997])
   Description:This property SHOULD be defined on all DAV compliant
   resources.  If present, the resource,
          preferring instead to present property contains a dialog box describing description of the
          conflict
   resource that is suitable for presentation to the a user. Due to this scenario,

13.3. get-content-language Property

   Name:       get-content-language
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Language header returned by a mechanism GET
   without accept headers.  If no Content-Language header is needed
          to prevent different programs from accidentally ignoring locks
          taken out by other programs with the same authorization.

          5.3.7.2   Solution Requirement

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

          The solution must not require that clients guess what sorts property MUST NOT exist.
   Value:      language-tag   ;language-tag is defined in section 14.13
   of
          locks might be used and use if-state-match headers with wildcards
          to prevent collisions. The problem with trying to "guess" which
          locks are being used RFC 2068

13.4. get-content-length Property

   Name:       get-content-length
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Length header returned by a GET
   without accept headers.  If no Content-Length header is that new lock types might be introduced,

          and available,
   this property MUST NOT exist.
   Value:      content-length ; see section 14.14 of RFC 2068

13.5. get-content-type Property

   Name:       get-content-type
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the program would not know to "guess them". So, for example, Content-Type header returned by a client might put GET
   without accept headers.  If no Content-Type header is available,
   this property MUST NOT exist.
   Value:      media-type   ; defined in an if-state-match Section 3.7 of [Fielding et
   al., 1997]

13.6. get-etag Property

   Name:       get-etag
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the ETag header with returned by a wildcard
          specifying GET without
   accept headers.  If no ETag header is available, this property MUST
   NOT exist.
   Value:      entity-tag  ; defined in Section 3.11 of [Fielding et
   al., 1997]
   Description:Note that if the ETag on some resource may reflect changes
   in any write lock is outstanding then part of the
          operation should fail. However a new read/write lock could be
          introduced which state of the client would resource, not know necessarily just a
   change to put in the header.

          5.3.7.3   State-Token Header

          The State-Token header, containing response to the GET method.  For example, a lock token owned by change in
   the
          requesting principal, is used by ACL may cause the principal ETag to indicate that change.

13.7. get-last-modified Property

   Name:       get-last-modified
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the principal Last-Modified header returned by a GET
   method without accept headers.  If no Last-Modified header is aware
   available, this property MUST NOT exist.
   Value:      HTTP-date  ; defined in Section 3.3.1 of [Fielding et
   al., 1997]
   Description:Note that the existence last-modified date on some resource may
   reflect changes in any part of the lock specified by state of the lock token. It is used in resource, not
   necessarily just a change to the following way.

          If response to the following conditions are met:
               1. GET method.  For
   example, a user-agent has authenticated itself as change in a principal,
               2. property may cause the user-agent is submitting a method request last-modified date to a
          resource
                    on which the principal owns a write lock,
               3.
   change.

13.8. index-content-language Property

   Name:       index-content-language
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the method is restricted Content-Language header returned by a write lock, as an
   INDEX without accept headers.  If no Content-Language header is
   available, this property MUST NOT exist.
   Value:      language-tag   ;language-tag is defined in
          the section "Methods Restricted by a Write Lock",
          then 14.13
   of RFC 2068

13.9. index-content-length Property

   Name:       index-content-length
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the method request MUST include a State-Token Content-Length header with
          the  lock token returned by an INDEX
   without accept headers.  If no Content-Length header is available,
   this property MUST NOT exist.
   Value:      content-length ; see section 14.14 of RFC 2068

13.10. index-content-type Property

   Name:       index-content-type
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the write lock, or the method fails with a 409
          Conflict status code. Content-Type header returned by an INDEX
   without accept headers.  If multiple resources are involved with a
          method, such as a COPY or MOVE method, then the lock tokens, if
          any, for all involved resources, no Content-Type header is available,
   this property MUST be included NOT exist.
   Value:      media-type   ; defined in the State-
          Token request header.

          For example, Program A, used by user A, takes out a write lock on
          a resource. Program A then makes a number Section 3.7 of PUT requests on the
          locked resource, all [Fielding et
   al., 1997]

13.11. index-etag Property

   Name:       index-etag
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the requests contain a State-Token ETag header
          which includes the write lock state token. Program B, also run returned by
          User A, then proceeds to perform a PUT to an INDEX without
   accept headers.  If no ETag header is available, this property MUST
   NOT exist.

   Value:      entity-tag  ; defined in Section 3.11 of [Fielding et
   al., 1997]
   Description:Note that the locked resource.
          However program B was not aware ETag on some resource may reflect changes
   in any part of the existence state of the lock and
          so does resource, not include necessarily just a
   change to the appropriate state-token header. The
          method is rejected even though principal A is authorized response to
          perform the PUT. Program B can, if it so chooses, now perform
          lock discovery and obtain INDEX method.  For example, a change
   in the lock token. Note that program A and
          B can perform GETs without using ACL may cause the ETag to change.

13.12. index-last-modified Property

   Name:       index-last-modified
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the state-token Last-Modified header because
          the ability to perform a GET is not affected returned by a write lock.

          Having a lock state token provides an INDEX
   method without accept headers.  If 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 Last-Modified header is used by
   available, this property MUST NOT exist.
   Value:      HTTP-date  ; defined in Section 3.3.1 of [Fielding et
   al., 1997]
   Description:Note that the server, not based last-modified date on some resource may
   reflect changes in any part of the
          secrecy state of the token values.

          5.3.7.3.1 Example

          COPY /~fielding/index.html HTTP/1.1
          Host: www.ics.uci.edu
          Destination: http://www.ics.uci.edu/users/f/fielding/index.html
          State-Token: <OpaqueLockToken:123AbcEfg1284h23h2>
          <OpaqueLockToken:AAAASDFcalkjfdas12312>

          HTTP/1.1 200 OK

          In this resource, not
   necessarily just a change to the response to the INDEX method.  For
   example, both a change in a property may cause the source and destination last-modified date to
   change.

13.13. lockdiscovery Property

   Name:       lockdiscovery
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To discover what locks are locked so
          two lock tokens must be submitted. If only one active on a resource
   Values=     *activelock
   Description:The lockdiscovery property returns a listing of the two
          resources was locked, then only one token would have to be
          submitted.

          5.4  Lock Tokens

          5.4.1     Problem Description

          It is possible that once who has
   a lock, what type of lock has been granted it may be
          removed without he have, the lock owner’s knowledge. This can cause
          serialization problems if timeout type and the time
   remaining on the timeout, and the associated lock owner executes methods
          thinking their lock token.  The server
   is still active. Due free to this, a mechanism is
          needed for a withhold any or all of this information if the requesting
   principal does not have sufficient access rights to predicate see the successful execution of a
          message upon
   requested data.  A server which supports locks MUST provide the continuing existence of a lock.

          5.4.2     Lock Token Introduction
   lockdiscovery property on any resource with locks on it.

13.13.1. activelock XML Element

   Name:       activelock
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    A lock token is a type of state token multivalued XML element that describes a particular
          lock.  A lock token is returned by every successful LOCK
          operation, and can also be discovered through
   active lock discovery on a
          resource.

          There are two types of lock tokens, a generic lock token, which
          is unique only for a particular resource, and an opaque resource
   Parent:     lockdiscovery
   Values=     locktype lockscope [addlocks] owner timeout locktoken

13.13.2. owner XML Element

   Name:       owner
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Returns owner information
   Parent:     activelock
   Values=     XML:REF | *PCDATA

13.13.3. timeout XML Element

   Name:       timeout
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Returns information about the timeout associated with
   the lock
          token, which is unique across all
   Parent:     activelock
   Values=     TimeType

13.13.4. addlocks XML Element

   Name:       addlocks
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Lists additional resources for all time.

          Uniqueness for associated with this lock, if
   any.
   Parent:     activelock
   Values=     1*href

13.13.5. locktoken XML Element

   Name:       locktoken
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Returns the lock token
   Parent:     activelock
   Values=     href
   Description:The href contains a particular Lock-Token-URL.

13.13.6. Example

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:propfind>
     <D:prop><lockdiscovery/></D:prop>
   </D:propfind>

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

   <?XML version="1.0">
   <?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:multistatus>
     <D:response>
          <D:prop>
               <D:lockdiscovery>
                    <D:activelock>
                         <D:locktype>write</D:locktype>
                         <D:lockscope>exclusive</D:lockscope>
                         <D:addlocks>
                              <D:href>http://foo.com/doc/</D:href>
                         </D:addlocks>
                         <D:owner>Jane Smith</D:owner>
                         <D:timeout>Infinite</D:timeout>
                         <D:locktoken>
                              <D:href>iamuri:unique!!!!!</D:href>
                         </D:locktoken>
                    </D:activelock>
               </D:lockdiscovery>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
     </D:response>
   </D:multistatus>

   This resource prevents problems with long
          held outstanding has a single exclusive write lock tokens being confused on it, with newer tokens. an
   infinite timeout.  This uniqueness requirement is the same as for e-tags. Uniqueness
          across all resources for all time allows for tokens to be
          submitted across resources and servers without fear of confusion.

          Generic lock tokens, because of their relaxed uniqueness
          requirements, are faster to generate than opaque lock tokens.

          5.4.3     Generic Lock Tokens

          Any valid URI can be used by also covers the resource as
   http://foo.com/doc/.

13.14. resourcetype Property

   Name:       resourcetype
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    This property contains a generic lock
          token. The only requirement is series of XML elements that
   specify information regarding the nature of the lock token MUST never
          have been issued previously on that resource. Because a lock
          token is  This
   specification only guaranteed to defines a single value, collection.
   Value:      XML elements
   Description:This property MUST be unique defined on all DAV compliant
   resources.  The default value is empty.

13.14.1. collection XML Element

   Name:       collection
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Identifies the associated resource that
          generated it, the lock token MUST NOT be submitted in as a state-
          token request header or an if-state[-not]-match header on any
          resource but collection.
   Collection resources MUST define this value with the resourcetype
   property.
   Parent:     resourcetype
   Values:          None

13.15. Source Link Property Type

   Name:       source
   Namespace:  http://www.ietf.org/standards/dav/link/
   Purpose:    The destination of the source link identifies the
   resource that generated it.

          5.4.4     OpaqueLockToken Lock Token contains the unprocessed source of the link's source.
   Parent:     None
   Value:      An XML document with zero or more link XML elements.

   Discussion: The opaquelocktoken scheme source of the link (src) is designed to typically the URI of the
   output resource on which the link is defined, and there is typically
   only one destination (dst) of the link, which is the URI where the
   unprocessed source of the resource may be unique across all
          resources for all time. Due to accessed.  When more than

   one link destination exists, this uniqueness quality, specification asserts no policy on
   ordering.

13.16. supportedlock Property

   Name:       supportedlock
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To provide a client
          MAY submit an opaque listing of the lock token in a state-token request header
          and an if-state[-not]-match header on capabilities supported
   by the resource.
   Values:     An XML document containing zero or more LockEntry XML
   elements.
   Description:The supportedlock property of a resource other than the
          one that returned it.

          All resources MUST recognize returns a
   listing of the opaquelocktoken scheme combinations of scope and access types which may be
          able to, at minimum, recognize that the
   specified in a lock token was not
          generated by request on the resource. Note, however,  Note that resources the actual
   contents are themselves controlled by access controls so a server is
   not required to generate opaquelocktokens.

          In order to guarantee uniqueness across all resources for all
          time provide information the opaquelocktoken requires client is not authorized to
   see.  If supportedlock is available on _*_ then it MUST define the use
   set of locks allowed on all resources on that server.

13.16.1. lockentry XML Element

   Name:       lockentry
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Defines a DAVLockType/LockScope pair that may be legally
   used with a LOCK on the GUID mechanism.

          Opaquelocktoken generators however have specified resource.
   Parent:     supportedlock
   Values=     locktype lockscope

13.16.2. locktype XML Element

   Name:       locktype
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Lists a choice DAVLockType
   Parent:     lockentry
   Values=     DAVLockTypeValue

13.16.3. lockscope XML Element

   Name:       lockscope
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Lists a DAVLockScope
   Parent:     lockentry

   Values:     DAVLockScopeValue

13.16.4. Example

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:propfind>
     <D:prop><supportedlock/></D:prop>
   </D:propfind>

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

   <?XML version="1.0">
   <?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:multistatus>
     <D:response>
          <D:prop>
               <D:supportedlock>
                    <D:LockEntry>
                         <D:locktype>Write</D:locktype>
                         <D:lockscope>Exclusive</D:lockscope>
                    </D:LockEntry>
                    <D:LockEntry>
                         <D:locktype>Write</D:locktype>
                         <D:lockscope>Shared</D:lockscope>
                    </D:LockEntry>
               </D:supportedlock>
          </D:prop>
          <D:status>HTTP/1.1 200 OK</D:status>
     </D:response>
   </D:multistatus>

14. DAV Compliance Levels

   A DAV compliant resource can choose from two levels of how they
          create these tokens. They compliance.
   A client can either generate a new GUID for
          every lock token they create, discover which is potentially very

          expensive, or they can create level a single GUID resource supports by executing
   OPTIONS on the resource, and then add
          extension characters. If examining the second method "DAV" header which is selected then the
          program generating the
   returned.

   Since this document describes extensions MUST guarantee that to the same
          extension will never HTTP/1.1 protocol,
   minimally all DAV compliant resources, clients, and proxies MUST be used twice
   compliant with the associated GUID.

          Opaque-Lock-Token = "OpaqueLockToken" ":" GUID [Extension]
          GUID = ; As defined in [LEACH]
          Extension = *urlc   ;urlc is defined in [Berners-Lee RFC 2068 [Fielding et al.,
          1997] (draft-fielding-url-syntax-07.txt)

          5.5  UNLOCK Method

          5.5.1     Problem Definition

          The UNLOCK method removes the lock identified by the lock token 1997].

14.1. Level 1

   A level 1 compliant resource MUST meet all "MUST" requirements in
   all sections of this document.

14.2. Level 2
   A level 2 compliant resource MUST meet all level 1 requirements and
   support the State-Token header from supportedlock property as well as the Request-URI, and all other
          resources included LOCK method.

15. Internationalization Considerations

   In the realm of internationalization issues, this specification is
   substantively in compliance with the lock.

          5.5.2     Example

          UNLOCK /workspace/webdav/info.doc HTTP/1.1
          Host: webdav.sb.aol.com
          State-Token: OpaqueLockToken:123AbcEfg1284h23h2

          HTTP/1.1 200 OK IETF Character Set Policy
   [Alvestrand, 1997]. In this example, specification, human-readable fields can
   be found in either the lock identified by value of a property, or in an error message
   returned in a response entity body.  In both cases, the lock token
          "OpaqueLockToken:123AbcEfg1284h23h2" human-
   readable content is successfully removed from encoded using XML, which has explicit provisions
   for character set tagging and encoding, and requires by default that
   XML processors read XML elements encoded using the resource http://webdav.sb.aol.com/workspace/webdav/info.doc.
          If this lock included more than just one resource, UTF-8 and UCS-2
   encodings of the lock is
          removed ISO 10646 basic multilingual plane.  Furthermore,
   XML contains provisions for encoding XML elements using other
   encoding schemes, notable among them UCS-4, which permits encoding
   of characters from those resources as well.

          5.6  Discovery Mechanisms

          5.6.1     Lock Capability Discovery

          5.6.1.1   Problem Definition

          Since server lock support any ISO 10646 character plane.

   The default character set encoding for XML data in this
   specification, and in general, is optional, a client trying to lock a
          resource on a server can either try UTF-8.  WebDAV compliant
   applications MUST support the lock UTF-8 and UCS-2 character set
   encodings for XML elements, and hope SHOULD support the UCS-4 encoding.
   The XML character set encoding declaration for each supported
   character set MUST also be supported, since it is by using this
   encoding declaration that an XML processor determines the
          best, or perform some form encoding
   of discovery an element.

   XML also provides language tagging capability which provides the
   ability to determine what lock
          capabilities specify the server supports.  This is known as lock
          capability discovery. Lock capability discovery differs from
          discovery of supported access control types, since there may 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 language of the lock capabilities supported
          by contents of a particular XML
   element.  Although XML, and hence WebDAV, does not use RFC 1766
   language tags for its language names, the resource.
          Schema: http://www.ietf.org/standards/dav/
          Values: An benefit of using standard
   XML document containing zero or more LockEntry in this context outweighs the advantage of using RFC 1766
   language tags.

   Names used within this specification fall into two categories: names
   specific to protocol elements such as methods and headers, names of
   XML
          elements.
          Description: The SupportedLock property elements, and names of a resource returns a
          listing properties.  Naming of protocol elements
   follows the combinations precedent of scope and access types which may
          be specified HTTP, using English names encoded in a lock request on the resource. Note that the
          actual contents
   USASCII for methods and headers.  Since these protocol elements are themselves controlled by access controls so a

          server is
   not required visible to provide information users, and are in fact simply long token identifiers,
   they do not need to support encoding in multiple character sets.
   Similarly, though the client is names of XML elements used in this
   specification are English names encoded in UTF-8, these names are
   not
          authorized visible to see. If SupportedLock is available on "*" then it
          MUST define the user, and hence do not need to support multiple
   character set encodings.

   The name 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 a DAVLockType/LockScope pair which may be
          legally used with a LOCK property defined on the specified resource.
          Schema: 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.1.6   Example

          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 = "D"/>
          <D:PROPFIND>
               <prop><SupportedLock/></prop>
          </D:PROPFIND>

          HTTP/1.1 207 Multi-Response
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace
               href ="http://www.ietf.org/standards/dav/" AS = "D"/>
          <D:MultiResponse>
               <Response>
                    <Prop>
                         <SupportedLock>
                              <LockEntry>
                                   <LockType>Write</LockType>
                                   <LockScope>Exclusive</LockScope>
                              </LockEntry>
                              <LockEntry>
                                   <LockType>Write</LockType>
                                   <LockScope>Shared</LockScope>
                              </LockEntry>

                         </SupportedLock>
                    </Prop>
                    <Status>HTTP/1.1 200 Success</Status>
          </Response>
          </D:MultiResponse>

          5.6.2     Active Lock Discovery

          5.6.2.1   Problem Definition

          If another principal locks a resource that is a principal wishes URI.  Although
   some applications (e.g., a generic property viewer) will display
   property URIs directly to
          access, their users, it is useful for the second principal to be able to find
          out who expected that the first principal is.

          5.6.2.2   Solution Requirements

          The lock discovery mechanism should provide
   typical application will use a list fixed set of who has the
          resource locked, what locks they have, properties, and what their lock tokens
          are. The lock tokens are useful will
   provide a mapping from the property name URI to a human-readable
   field when displaying the property name to a user.  It is only in shared lock situations
   the case where
          two principals may want to guarantee that they do the set of properties is not overwrite
          each other. The lock tokens are also useful for administrative
          purposes so known ahead of time that
   an administrator can remove a 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 a resource
          Schema: http://www.ietf.org/standards/dav/
          Values= An XML document containing zero or more ActiveLock XML
          elements.

          Description: The LOCKDISCOVERY application need display a property returns name URI to a listing user. We
   recommend that applications provide human-readable property names
   wherever feasible.

   For error reporting, we follow the convention of who
          has HTTP/1.1 status
   codes, including with each status code a lock, what type short, English description
   of lock they have, the time out type and the time remaining on code (e.g., 421 Destination Locked).  While the time out, possibility
   exists that a poorly crafted user agent would display this message
   to a user, internationalized applications will ignore this message,
   and display an appropriate message in the associated lock
          token. The server is free to withhold any or all user's language and
   character set.

   Since interoperation of clients and servers does not require locale
   information, this
          information if the requesting principal specification does not have sufficient
          access rights to see the requested data. A server which supports
          locks MUST provide the LOCKDISCOVERY property on specify any resource
          with locks on it.

          5.6.2.4   ACTIVELOCK XML Element

          Name: http://www.ietf.org/standards/dav/activelock
          Purpose: mechanism for
   transmission of this information.

16. Security Considerations
   [TBD]

17. Terminology

   Collection - A multivalued XML element resource that describes contains member resources.

   Member Resource - A resource contained by a particular
          active lock on collection.  There are
   two types of member resources: external and internal.

   Internal Member Resource _ A member resource of a collection whose
   URI is relative to the URI of the collection.

   External Member Resource - A member resource
          Schema: http://www.ietf.org/standards/dav/
          Parent: of a collection with an
   absolute URI that is not relative to its parent's URI.

   Property - A LOCKDISCOVERY entry
          Values= LOCKTYPE LOCKSCOPE [ADDLOCKS] 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 name/value pair that contains descriptive information
   about a resource.

   Live Property _ A property whose semantics and syntax are enforced
   by the server.  For example, a live "content-length" property would
   have its value, the timeout associated with length of the lock
          Schema: http://www.ietf.org/standards/dav/
          Parent: ACTIVELOCK
          Values= TimeType

          5.6.2.7   ADDLOCKS XML Element

          Name:     http://www.ietf.org/standards/dav/addlocks
          Purpose: Lists additional resources associated with this lock, if
          any.
          Schema: http://www.ietf.org/standards/dav/
          Parent: ACTIVELOCK
          Values= 1*HREF

          5.6.2.8   LOCKTOKEN XML Element

          Name: http://www.ietf.org/standards/dav/statetoken
          Purpose: Returns entity returned by a GET request,
   automatically calculated by the lock token
          Schema: http://www.ietf.org/standards/dav/
          Parent: ACTIVELOCK
          Values= HREF
          Description: server.

   Dead Property _ A property whose semantics and syntax are not
   enforced by the server.  The HREF contains a Lock-Token-URL.

          5.6.2.9   Example

          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 = "D"/>
          <D:PROPFIND>
               <prop><lockdiscovery/></prop>
          </D:PROPFIND>

          HTTP/1.1 207 Multi-Response
          Content-Type: text/xml
          Content-Length: xxxxx

          <?XML:Namespace
               href ="http://www.ietf.org/standards/dav/" AS = "D"/>
          <D:MultiResponse>
               <Response>
                    <Prop>
                         <lockdiscovery>
                              <activelock>
                                   <locktype>write</locktype>
                                   <lockscope>exclusive</lockscope>
                                   <addlocks>
                                        <HREF>http://foo.com/doc/</HREF>
                                   </addlocks>
                                   <owner>Jane Smith</owner>
                                   <timeout>Infinite</timeout>
                                   <locktoken>
                                        <HREF>iamuri:unique!!!!!</HREF>
                                   </locktoken>
                              </activelock>

                         </lockdiscovery>
                    </Prop>
                    <Status>HTTP/1.1 200 Success</Status>
          </Response>
          </D:MultiResponse>

          This resource has server only records the value of a single exclusive write lock on it, with an
          infinite time out. This same lock also covers dead
   property; the resource
          http://foo.com/doc/.

          6    Version Control
          [TBD]

          7    Internationalization Support
          [TBD]

          8    Security Considerations
          [TBD]

          9 client is responsible for maintaining the consistency
   of the syntax and semantics of a dead property.

18. Copyright
   The following copyright notice is copied from RFC 2026 chapter 10.4,
   and describes the applicable copyright for this document

   Copyright (C) The Internet Society October 13, November 19, 1997. All Rights
   Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

          10

19. Acknowledgements

   A specification such as this thrives on piercing critical review and
   withers from apathetic neglect.  The authors gratefully acknowledge
   the contributions of the following people, whose insights were so
   valuable at every stage of our work.

   Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell, Bernard
   Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel,
   Jr., Jim Davis, 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, Richard N. Taylor, Robert Thau, John
   Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and
   Lauren Wood

          11 Wood.

   One from this list deserves special mention.  The contributions by
   Larry Masinter have been invaluable, both in helping the formation
   of the working group and in patiently coaching the authors along the
   way.  In so many ways he has set high standards we have toiled to
   meet.

20. References

   [Alvestrand, 1997] H. T. Alvestrand, "IETF Policy on Character Sets
   and Languages."  Internet-draft, work-in-progress.
   ftp://ds.internic.net/internet-drafts/draft-alvestrand-charset-
   policy-02.txt

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

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

   [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.
   ftp://ds.internic.net/rfc/rfc2068.txt

   [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
   Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.
   ftp://ds.internic.net/rfc/rfc1807.txt

   [Leach, Salz, 1997] P. J. Leach, R. Salz, "UUIDs and GUIDs."
   Internet-draft (expired), work-in-progress, February, 1997.
   http://www.internic.net/internet-drafts/draft-leach-uuids-guids-
   00.txt

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

   [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
   Treese, "PICS Label Distribution Label Syntax and Communication
   Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-
          961031. 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 Versioning on
   Protocol for the World Wide Web." Internet-draft, work-in-
          progress, draft-ietf-webdav-requirements-04.txt,
          ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-
          requirements-04.txt. RFC XXXX. Xerox, Univ. of Bologna,
   U.C. Irvine, Boston Univ. YYY, 1997.
   ftp://ds.internic.net/rfc/rfcXXXX.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 transformation format of
   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.

          12

21. Authors' Addresses

   Y. Y. Goland
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
          Email
   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 R. Carter
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399
          Email
   Email: srcarter@novell.com

   D. Jensen
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399
          Email
   Email: dcjensen@novell.com