©Ą
WebDAV                                                      L. Dusseault
Internet-Draft                                                      OSAF
Expires: January 15, 2005 16, 2006                                    J. Crawford
                                                                     IBM
                                                           July 17, 2004 15, 2005

     HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis
                    draft-ietf-webdav-rfc2518bis-06
                    draft-ietf-webdav-rfc2518bis-07

Status of this Memo

   This document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is any of which he or she becomes
   aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 6 of RFC2026. BCP 79.

   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.

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

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 15, 2005. 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved. (2005).

Abstract

   WebDAV consists of a set of methods, headers, and content-types
   ancillary to HTTP/1.1 for the management of resource properties,
   creation and management of resource collections, namespace
   manipulation, and resource locking (collision avoidance).

   RFC2518 was published in February 1998, and this draft makes minor
   revisions mostly due to interoperability experience.

Table of Contents

   1.  Introduction

   This document describes an extension to the 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 response entity body formats that provide
   operations for:

   Properties: The ability to create, remove, and query information
   about Web pages, such as their authors, creation dates, etc.  Also,
   the ability to link pages of any media type to related pages.

   Collections: . . . . . . . . . . . . . . . . . . . . . . . .    7
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . .    9
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   10
   4.  Data Model for Resource Properties . . . . . . . . . . . . .   11
     4.1   The ability to create sets of documents Resource Property Model  . . . . . . . . . . . . . .   11
     4.2   Properties and to retrieve
   a hierarchical membership listing (like a directory listing in a file
   system).

   Locking: The ability to keep more than one person from working on a
   document at the same time.  This prevents the "lost update problem",
   in which modifications are lost as first one author then another
   writes changes without merging the other author's changes.

   Namespace Operations: The ability to instruct the server to copy HTTP Headers  . . . . . . . . . . . . . .   11
     4.3   XML Usage  . . . . . . . . . . . . . . . . . . . . . . .   11
     4.4   Property Values  . . . . . . . . . . . . . . . . . . . .   12
     4.5   Property Names . . . . . . . . . . . . . . . . . . . . .   13
     4.6   Source Resources and
   move Output Resources  . . . . . . . . .   14
   5.  Collections of Web resources.

   Requirements and rationale for these operations are described in a
   companion document, "Requirements for a Distributed Authoring Resources . . . . . . . . . . . . . . . .   15
     5.1   HTTP URL Namespace Model . . . . . . . . . . . . . . . .   15
     5.2   Collection Resources . . . . . . . . . . . . . . . . . .   15
   6.  Locking  . . . . . . . . . . . . . . . . . . . . . . . . . .   17
     6.1   Exclusive Vs. Shared Locks . . . . . . . . . . . . . . .   17
     6.2   Required Support . . . . . . . . . . . . . . . . . . . .   18
     6.3   Lock Tokens  . . . . . . . . . . . . . . . . . . . . . .   18
     6.4   Lock Token URI Schemes . . . . . . . . . . . . . . . . .   19
     6.5   Lock Capability Discovery  . . . . . . . . . . . . . . .   19
     6.6   Active Lock Discovery  . . . . . . . . . . . . . . . . .   20
     6.7   Locks and
   Versioning Protocol for the World Wide Web" (RFC2291) [15].

   This standard does not specify the versioning operations suggested Multiple Bindings  . . . . . . . . . . . . . .   20
   7.  Write Lock . . . . . . . . . . . . . . . . . . . . . . . . .   21
     7.1   Lock Owner . . . . . . . . . . . . . . . . . . . . . . .   21
     7.2   Methods Restricted by
   RFC2291 [15].  That work was done in a separate document, "Versioning
   Extensions to WebDAV" (RFC3253) [18].

   The sections below provide a detailed introduction to resource
   properties (Section 4), collections of resources (Section 5), Write Locks  . . . . . . . . . . .   21
     7.3   Write Locks and
   locking operations (Section 6).  These sections introduce the
   abstractions manipulated by the WebDAV-specific HTTP methods (Section
   8) Lock Tokens  . . . . . . . . . . . . . .   22
     7.4   Write Locks and Properties . . . . . . . . . . . . . . .   22
     7.5   Avoiding Lost Updates  . . . . . . . . . . . . . . . . .   22
     7.6   Write Locks and Unmapped URLs  . . . . . . . . . . . . .   23
     7.7   Write Locks and Collections  . . . . . . . . . . . . . .   25
     7.8   Write Locks and the new If Request Header  . . . . . . . . .   26
     7.9   Write Locks and COPY/MOVE  . . . . . . . . . . . . . . .   27
     7.10  Refreshing Write Locks . . . . . . . . . . . . . . . . .   28
   8.  HTTP headers used with WebDAV methods (Section 9).

   While the status codes provided by HTTP/1.1 are sufficient to
   describe most error conditions encountered by WebDAV methods, there
   are some errors that do not fall neatly into the existing categories.
   This specification defines new status  codes developed Methods for WebDAV
   methods (Section 10) Distributed Authoring . . . . . . . . . . .   29
     8.1   General request and describes existing HTTP status codes
   (Section 11) as used in WebDAV.  Since some WebDAV methods may
   operate over many resources, the Multi-Status response (Section 12)
   has been introduced to return status information for multiple
   resources.  Finally, this version of WebDAV introduces handling  . . . . . . . . .   29
       8.1.1   Use of XML elements . . . . . . . . . . . . . . . . . . . . .   29
       8.1.2   Required Bodies in Requests  . . . . . . . . . . . .   29
       8.1.3   Use of Location header in responses  . . . . . . . .   29
       8.1.4   Required Response Headers: Date  . . . . . . . . . .   29
       8.1.5   ETag . . . . . . . . . . . . . . . . . . . . . . . .   29
       8.1.6   Including error response bodies in Section 15.

   WebDAV uses XML [11] to marshal complicated request  . . . . . . . . . .   30
     8.2   PROPFIND . . . . . . . . . . . . . . . . . . . . . . . .   31
       8.2.1   Example - Retrieving Named Properties  . . . . . . .   33
       8.2.2   Example - Retrieving Named and response
   information, as well as Dead Properties . . .   35
       8.2.3   Example - Using propname to express metadata, so this specification
   contains definitions of Retrieve all XML elements used (Section 13).  WebDAV
   includes a few special rules on how to process  XML (Section 16)
   appearing in WebDAV so that it truly is extensible.

   WebDAV employs the property mechanism to store information about the
   current state of the resource.  For example, when a lock is taken out
   on a resource, a lock information property describes the current
   state of the lock.

   Finishing off the specification are sections on what it means to be
   compliant Property
               Names  . . . . . . . . . . . . . . . . . . . . . . .   35
       8.2.4   PROPFIND Request Errors  . . . . . . . . . . . . . .   37
     8.3   PROPPATCH  . . . . . . . . . . . . . . . . . . . . . . .   37
       8.3.1   Status Codes for use with this specification (Section 17), on
   internationalization support (Section 18), 207 (Multi-Status) . . . .   37
       8.3.2   Example - PROPPATCH  . . . . . . . . . . . . . . . .   39
     8.4   MKCOL Method . . . . . . . . . . . . . . . . . . . . . .   40
       8.4.1   MKCOL Status Codes . . . . . . . . . . . . . . . . .   40
       8.4.2   Example - MKCOL  . . . . . . . . . . . . . . . . . .   41
     8.5   GET, HEAD for Collections  . . . . . . . . . . . . . . .   41
     8.6   POST for Collections . . . . . . . . . . . . . . . . . .   42
     8.7   DELETE . . . . . . . . . . . . . . . . . . . . . . . . .   42
       8.7.1   DELETE for Non-Collection Resources  . . . . . . . .   42
       8.7.2   DELETE for Collections . . . . . . . . . . . . . . .   42
       8.7.3   Example - DELETE . . . . . . . . . . . . . . . . . .   43
     8.8   PUT  . . . . . . . . . . . . . . . . . . . . . . . . . .   43
       8.8.1   PUT for Non-Collection Resources . . . . . . . . . .   43
       8.8.2   PUT for Collections  . . . . . . . . . . . . . . . .   44
     8.9   COPY . . . . . . . . . . . . . . . . . . . . . . . . . .   44
       8.9.1   COPY for Non-collection Resources  . . . . . . . . .   44
       8.9.2   COPY for Properties  . . . . . . . . . . . . . . . .   45
       8.9.3   COPY for Collections . . . . . . . . . . . . . . . .   45
       8.9.4   COPY and on security (Section
   19).

2.  Notational Conventions

   Since this document describes a set of extensions to the HTTP/1.1
   protocol, the augmented BNF used herein to describe protocol elements
   is exactly the same as described in section 2.1 of RFC2616 [8],
   including the rules about implied linear white-space.  Since this
   augmented BNF uses the basic production rules provided in section 2.2
   of RFC2616 [8], these rules apply to this document as well.

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

3.  Terminology

   URI/URL - A Uniform Resource Identifier Overwrite Header  . . . . . . . . . . .   46
       8.9.5   Status Codes . . . . . . . . . . . . . . . . . . . .   47
       8.9.6   COPY Examples  . . . . . . . . . . . . . . . . . . .   47
     8.10  MOVE . . . . . . . . . . . . . . . . . . . . . . . . . .   49
       8.10.1  MOVE for Properties  . . . . . . . . . . . . . . . .   50
       8.10.2  MOVE for Collections . . . . . . . . . . . . . . . .   50
       8.10.3  MOVE and Uniform Resource Locator,
   respectively.  These terms (and the distinction between them) are
   defined in RFC2396 [6].

   Collection - A resource that contains a set of URLs, which identify
   and locate member resources Overwrite Header  . . . . . . . . . . .   51
       8.10.4  Status Codes . . . . . . . . . . . . . . . . . . . .   51
       8.10.5  Examples . . . . . . . . . . . . . . . . . . . . . .   52
     8.11  LOCK Method  . . . . . . . . . . . . . . . . . . . . . .   53
       8.11.1  Refreshing Locks . . . . . . . . . . . . . . . . . .   54
       8.11.2  Depth and which meet the collections
   requirements (Section 5).

   Member URL - A URL which is a member of the set of Locking  . . . . . . . . . . . . . . . . .   55
       8.11.3  Locking Unmapped URLs contained by
   a collection.

   Internal Member URL  . . . . . . . . . . . . . . .   55
       8.11.4  Lock Compatibility Table . . . . . . . . . . . . . .   56
       8.11.5  LOCK responses . . . . . . . . . . . . . . . . . . .   56
       8.11.6  Example - A Member URL that is immediately relative to
   the URL of the collection (the definition of immediately relative is
   given later (Section 5.2)).

   Property Simple Lock Request  . . . . . . . . . . .   57
       8.11.7  Example - A name/value pair that contains descriptive information
   about Refreshing a resource.

   Live Property Write Lock  . . . . . . . . .   59
       8.11.8  Example - A property whose semantics and syntax are enforced by
   the server.  For example, the live "getcontentlength" property has
   its value, the length of the entity returned by a GET request,
   automatically calculated by the server.

   Dead Property - A property whose semantics and syntax are not
   enforced by the server.  The server only records the value of a dead
   property; the client is responsible for maintaining the consistency
   of the syntax and semantics of a dead property.

4.  Data Model for Resource Properties

4.1  The Resource Property Model

   Properties are pieces of data that describe the state of a resource.
   Properties are data about data.

   Properties are used in 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 Multi-Resource Lock Request  . . . . . . .   60
     8.12  UNLOCK Method  . . . . . . . . . . . . . . . . . . . . .   61
       8.12.1  Status Codes . . . . . . . . . . . . . . . . . . . .   61
       8.12.2  Example  . . . . . . . . . . . . . . . . . . . . . .   62
   9.  HTTP Headers for the discovery
   of what authors have written which documents.

   The Distributed Authoring . . . . . . . . . . .   63
     9.1   DAV property model consists of name/value pairs.  The name of a
   property identifies the property's syntax and semantics, Header . . . . . . . . . . . . . . . . . . . . . . .   63
     9.2   Depth Header . . . . . . . . . . . . . . . . . . . . . .   63
     9.3   Destination Header . . . . . . . . . . . . . . . . . . .   65
     9.4   Force-Authentication Header  . . . . . . . . . . . . . .   65
     9.5   If Header  . . . . . . . . . . . . . . . . . . . . . . .   65
       9.5.1   No-tag-list Production . . . . . . . . . . . . . . .   66
       9.5.2   Tagged-list Production . . . . . . . . . . . . . . .   67
       9.5.3   Not Production . . . . . . . . . . . . . . . . . . .   67
       9.5.4   Matching Function  . . . . . . . . . . . . . . . . .   68
       9.5.5   If Header and provides
   an address by which to refer Non-DAV Aware Proxies  . . . . . . . .   69
     9.6   Lock-Token Header  . . . . . . . . . . . . . . . . . . .   69
     9.7   Overwrite Header . . . . . . . . . . . . . . . . . . . .   69
     9.8   Timeout Request Header . . . . . . . . . . . . . . . . .   69
   10.   Status Code Extensions to its syntax and semantics.

   There are two categories HTTP/1.1 . . . . . . . . . . . .   71
     10.1  102 Processing . . . . . . . . . . . . . . . . . . . . .   71
     10.2  207 Multi-Status . . . . . . . . . . . . . . . . . . . .   71
     10.3  422 Unprocessable Entity . . . . . . . . . . . . . . . .   71
     10.4  423 Locked . . . . . . . . . . . . . . . . . . . . . . .   71
     10.5  424 Failed Dependency  . . . . . . . . . . . . . . . . .   72
     10.6  507 Insufficient Storage . . . . . . . . . . . . . . . .   72
   11.   Use of properties: "live" and "dead".  A live
   property has its syntax and semantics enforced by the server.  Live
   properties include cases where a) the value of a property is read-
   only, maintained by the server, and b) the value of the property is
   maintained by the client, but the server performs syntax checking on
   submitted values.  All instances of a given live property MUST comply
   with the definition associated with that property name.  A dead
   property has its syntax and semantics enforced by the client; the
   server merely records the value of the property verbatim.

4.2  Existing Metadata Proposals

   Properties have long played an essential role in the maintenance of
   large document repositories, and many current proposals contain some
   notion of a property, or discuss web metadata more generally.  These
   include PICS [20], PICS-NG, XML, Web Collections, and several
   proposals on representing relationships within HTML.  Work on PICS-NG
   and Web Collections has been subsumed by the Resource Description
   Framework (RDF) metadata activity of the World Wide Web Consortium.
   RDF consists of a network-based data model and an XML representation
   of that model.

   Some proposals come from a digital library perspective.  These
   include the Dublin Core [RFC2413] metadata set and the Warwick
   Framework [WF], a container architecture for different metadata
   schemas.  The literature includes many examples of metadata,
   including MARC [USMARC], a bibliographic metadata format, and a
   technical report bibliographic format employed by the Dienst system
   [RFC1807].  Additionally, the proceedings from the first IEEE
   Metadata conference describe many community-specific metadata sets.

   Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
   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.

4.3  Properties and HTTP Headers

   Properties already exist, in a limited sense, in HTTP 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 set or retrieve just those properties.

4.4  XML Usage

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers.  Unlike HTTP/1.1, WebDAV encodes method parameter
   information either in an XML [11] request entity body, or in an HTTP
   header.  The use of XML to encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility; and by XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.

   In addition to encoding method parameters, XML is used in WebDAV to
   encode the responses from methods, providing the extensibility and
   internationalization advantages of XML for method output, as well as
   input.

   The XML namespace extension [10] is also used in this specification
   in order to allow for new XML elements to be added without fear of
   colliding with other element names.  Although WebDAV request and
   response bodies can be extended by arbitrary XML elements, which can
   be ignored by the message recipient, an XML element in the "DAV:"
   namespace SHOULD NOT be used in the request or response body unless
   that XML element is explicitly defined in an IETF RFC reviewed by a
   WebDAV working group.

   Note that "DAV:" is a scheme name defined solely to provide a
   namespace for WebDAV XML elements and property names.  This practice
   is discouraged in part because registration of new scheme names is
   difficult.  "DAV:" was defined as the WebDAV namespace before
   standard best practices emerged, and this namespace is kept and still
   used because of significant existing deployments, but this should not
   be emulated.

4.5  Property Values

   The value of a property is always a (well-formed) XML fragment.

   XML has been chosen because it is a flexible, self-describing,
   structured data format that supports rich schema definitions, and
   because of its support for multiple character sets.  XML's self-
   describing nature allows any property's value to be extended by
   adding new elements.  Older clients will not break when they
   encounter extensions because they will still have the data specified
   in the original schema and will ignore elements they do not
   understand.  XML's support for multiple character sets allows any
   human-readable property to be encoded and read in a character set
   familiar to the user.  XML's support for multiple human languages,
   using the "xml:lang" attribute, handles cases where the same
   character set is employed by multiple human languages.  Note that
   xml:lang scope is recursive, so a xml:lang attribute on any element
   containing a property name element applies to the property value
   unless it has been overridden by a more locally scoped attribute.

   A property is always represented in XML with an XML element
   consisting of the property name.  The simplest example is an empty
   property, which is different from a property that does not exist.

   <R:title xmlns:R="http://www.example.com/ns/"></R:title>

   The value of a property appears inside the property name element.
   The value may be any kind of well-formed XML content, including both
   text-only and mixed content.  When the property value contains
   further XML elements, namespaces that are in scope for that part of
   the XML document apply within the property value as well, and MUST be
   preserved in server storage for retransmission later.  Namespace
   prefixes need not be preserved due to the rules of prefix declaration
   in XML.

   Attributes on the property name element may convey information about
   the property, but are not considered part of the value.  However,
   when language information appears in the 'xml:lang' attribute on the
   property name element, the language information MUST be preserved in
   server storage for retransmission later.

   The XML attribute xml:space MUST NOT be used to change white space
   handling.  White space in property values is significant.

4.6  Property Names

   A property name is a universally unique identifier that is associated
   with a schema that provides information about the syntax and
   semantics of the property.

   Because a property's name is universally unique, clients can depend
   upon consistent behavior for a particular property across multiple
   resources, on the same and across different servers, so long as that
   property is "live" on the resources in question, and the
   implementation of the live property is faithful to its definition.

   The XML namespace mechanism, which is based on URIs [6], is used to
   name properties because it prevents namespace collisions and provides
   for varying degrees of administrative control.

   The property namespace is flat; that is, no hierarchy of properties
   is explicitly recognized.  Thus, if a property A and a property A/B
   exist on a resource, there is no recognition of any relationship
   between the two properties.  It is expected that a separate
   specification will eventually be 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 resource's
   property namespace.

5.  Collections of Web Resources

   This section provides a description of a new type of Web resource,
   the collection, and discusses its interactions with the HTTP URL
   namespace.  The purpose of a collection resource is to model
   collection-like objects (e.g., file system directories) within a
   server's namespace.

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

5.1  HTTP URL Namespace Model

   The HTTP URL namespace is a hierarchical namespace where the
   hierarchy is delimited with the "/" character.

   An HTTP URL namespace is said to be consistent if it meets the
   following conditions: for every URL in the HTTP hierarchy there
   exists a collection that contains that URL as an internal member.
   The root, or top-level collection of the namespace under
   consideration is exempt from the previous rule.

   Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
   namespace be consistent.  However, certain WebDAV methods are
   prohibited from producing results that cause namespace
   inconsistencies.

   Although implicit in RFC2616 [8] and RFC2396 [6], any resource,
   including collection resources, MAY be identified by more than one
   URI.  For example, a resource could be identified by multiple HTTP
   URLs.

5.2  Collection Resources

   A collection is a resource whose state consists of at least a list of
   internal member URLs and a set of properties, but which may have
   additional state such as entity bodies returned by GET.  An internal
   member URL MUST be immediately relative to a base URL of the
   collection.  That is, the internal member URL is equal to a
   containing collection's URL plus an additional segment for non-
   collection resources, or additional segment plus trailing slash "/"
   for collection resources, where segment is defined in section 3.3 of
   RFC2396 [6].

   Any given internal member URL MUST only belong to the collection
   once, i.e., it is illegal to have multiple instances of the same URL
   in a collection.  Properties defined on collections behave exactly as
   do properties on non-collection resources.

   For all WebDAV compliant resources A and B, identified by URLs U and
   V, for which U is immediately relative to V, B MUST be a collection
   that has U as an internal member URL.  So, if the resource with URL
   http://example.com/bar/blah is WebDAV compliant and if the resource
   with URL http://example.com/bar/ is WebDAV compliant then the
   resource with URL http://example.com/bar/ must be a collection and
   must contain URL http://example.com/bar/blah as an internal member.

   Collection resources MAY list the URLs of non-WebDAV compliant
   children in the HTTP URL namespace hierarchy as internal members but
   are not required to do so.  For example, if the resource with URL
   http://example.com/bar/blah is not WebDAV compliant and the URL
   http://example.com/bar/ identifies a collection then URL http://
   example.com/bar/blah may or may not be an internal member of the
   collection with URL http://example.com/bar/.

   If a WebDAV compliant resource has no WebDAV compliant children in
   the HTTP URL namespace hierarchy then the WebDAV compliant resource
   is not required to be a collection.

   There is a standing convention that when a collection is referred to
   by its name without a trailing slash, the server MAY handle the
   request as if the trailing slash were present.  In this case it
   SHOULD return a Content-Location header Status Codes . . . . . . . . . . . . . . . . .   73
     11.1  301 Moved Permanently  . . . . . . . . . . . . . . . . .   73
     11.2  302 Found  . . . . . . . . . . . . . . . . . . . . . . .   73
     11.3  400 Bad Request  . . . . . . . . . . . . . . . . . . . .   73
     11.4  403 Forbidden  . . . . . . . . . . . . . . . . . . . . .   73
     11.5  409 Conflict . . . . . . . . . . . . . . . . . . . . . .   73
     11.6  412 Precondition Failed  . . . . . . . . . . . . . . . .   73
     11.7  414 Request-URI Too Long . . . . . . . . . . . . . . . .   74
     11.8  503 Service Unavailable  . . . . . . . . . . . . . . . .   74
   12.   Multi-Status Response  . . . . . . . . . . . . . . . . . .   75
     12.1  Responses requiring Location in the response, pointing to
   the URL ending with the "/".  For example, if a client invokes a
   method on http://example.bar/blah (no trailing slash), the server may
   respond as if the operation were invoked on http://example.com/blah/
   (trailing slash), and should return a Content-Location header with
   the value http://example.bar/blah/.  Wherever a server produces a URL
   referring to a collection, the server MUST include the trailing
   slash.  In general clients SHOULD use the "/" form of collection
   names.

   A resource MAY be a Multi-Status . . . . . .   75
   13.   XML Element Definitions  . . . . . . . . . . . . . . . . .   77
     13.1  activelock XML Element . . . . . . . . . . . . . . . . .   77
     13.2  depth XML Element  . . . . . . . . . . . . . . . . . . .   77
     13.3  locktoken XML Element  . . . . . . . . . . . . . . . . .   77
     13.4  lockroot XML Element . . . . . . . . . . . . . . . . . .   78
     13.5  timeout XML Element  . . . . . . . . . . . . . . . . . .   78
     13.6  collection but not be WebDAV compliant.  That is,
   the resource may comply with all the rules XML Element . . . . . . . . . . . . . . . . .   79
     13.7  href XML Element . . . . . . . . . . . . . . . . . . . .   79
     13.8  lockentry XML Element  . . . . . . . . . . . . . . . . .   79
     13.9  lockinfo XML Element . . . . . . . . . . . . . . . . . .   80
     13.10   lockscope XML Element  . . . . . . . . . . . . . . . .   80
     13.11   exclusive XML Element  . . . . . . . . . . . . . . . .   80
     13.12   shared XML Element . . . . . . . . . . . . . . . . . .   81
     13.13   locktype XML Element . . . . . . . . . . . . . . . . .   81
     13.14   write XML Element  . . . . . . . . . . . . . . . . . .   82
     13.15   multistatus XML Element  . . . . . . . . . . . . . . .   82
     13.16   response XML Element . . . . . . . . . . . . . . . . .   82
     13.17   propstat XML Element . . . . . . . . . . . . . . . . .   83
     13.18   status XML Element . . . . . . . . . . . . . . . . . .   83
     13.19   responsedescription XML Element  . . . . . . . . . . .   84
     13.20   owner XML Element  . . . . . . . . . . . . . . . . . .   84
     13.21   prop XML element . . . . . . . . . . . . . . . . . . .   85
     13.22   propertyupdate XML element . . . . . . . . . . . . . .   85
     13.23   remove XML element . . . . . . . . . . . . . . . . . .   85
     13.24   set out in this
   specification regarding how a collection is to behave without
   necessarily supporting all methods that a WebDAV compliant resource
   is required to support.  In such a case the resource may return the
   DAV:resourcetype property with the value DAV:collection but MUST NOT
   return a XML element  . . . . . . . . . . . . . . . . . . .   86
     13.25   propfind XML Element . . . . . . . . . . . . . . . . .   86
     13.26   allprop XML Element  . . . . . . . . . . . . . . . . .   87
     13.27   propname XML Element . . . . . . . . . . . . . . . . .   87
     13.28   dead-props XML Element . . . . . . . . . . . . . . . .   87
     13.29   location XML Element . . . . . . . . . . . . . . . . .   88
     13.30   error XML Element  . . . . . . . . . . . . . . . . . .   88
   14.   DAV header containing the value "1" on an OPTIONS response.

   Clients MUST be able to support the case where WebDAV resources are
   contained inside non-WebDAV resources.  For example, if a OPTIONS
   response from "http://example.com/servlet/dav/collection" indicates
   WebDAV support, the client cannot assume that "http://example.com/
   servlet/dav/" or its parent necessarily are WebDAV collections.

5.3  Source Resources and Output Resources

   For many resources, the entity returned by a GET method exactly
   matches Properties . . . . . . . . . . . . . . . . . . . . . .   89
     14.1  creationdate Property  . . . . . . . . . . . . . . . . .   89
     14.2  displayname Property . . . . . . . . . . . . . . . . . .   90
     14.3  getcontentlanguage Property  . . . . . . . . . . . . . .   90
     14.4  getcontentlength Property  . . . . . . . . . . . . . . .   91
     14.5  getcontenttype Property  . . . . . . . . . . . . . . . .   91
     14.6  getetag Property . . . . . . . . . . . . . . . . . . . .   92
     14.7  getlastmodified Property . . . . . . . . . . . . . . . .   93
     14.8  lockdiscovery Property . . . . . . . . . . . . . . . . .   94
       14.8.1  Example - Retrieving the persistent state of lockdiscovery Property  . .   94
     14.9  resourcetype Property  . . . . . . . . . . . . . . . . .   96
     14.10   supportedlock Property . . . . . . . . . . . . . . . .   96
       14.10.1   Example - Retrieving the resource, supportedlock Property  .   98
   15.   Precondition/postcondition XML elements  . . . . . . . . .   99
   16.   Instructions for example, a GIF file
   stored on a disk.  For this simple case, the URL at which a resource
   is accessed is identical Processing XML in DAV . . . . . . . . . .  102
   17.   DAV Compliance Classes . . . . . . . . . . . . . . . . . .  103
     17.1  Class 1  . . . . . . . . . . . . . . . . . . . . . . . .  103
     17.2  Class 2  . . . . . . . . . . . . . . . . . . . . . . . .  103
     17.3  Class 'bis'  . . . . . . . . . . . . . . . . . . . . . .  103
   18.   Internationalization Considerations  . . . . . . . . . . .  105
   19.   Security Considerations  . . . . . . . . . . . . . . . . .  107
     19.1  Authentication of Clients  . . . . . . . . . . . . . . .  107
     19.2  Denial of Service  . . . . . . . . . . . . . . . . . . .  107
     19.3  Security through Obscurity . . . . . . . . . . . . . . .  108
     19.4  Privacy Issues Connected to the URL at which the source (the
   persistent state) Locks  . . . . . . . . . . .  108
     19.5  Privacy Issues Connected to Properties . . . . . . . . .  108
     19.6  Implications of the resource is accessed. XML External Entities  . . . . . . . . .  109
     19.7  Risks Connected with Lock Tokens . . . . . . . . . . . .  109
   20.   IANA Considerations  . . . . . . . . . . . . . . . . . . .  111
   21.   Acknowledgements . . . . . . . . . . . . . . . . . . . . .  112
   22.   References . . . . . . . . . . . . . . . . . . . . . . . .  113
     22.1  Normative References . . . . . . . . . . . . . . . . . .  113
     22.2  Informational References . . . . . . . . . . . . . . . .  113
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  114
   A.  Previous Authors' Addresses  . . . . . . . . . . . . . . . .  115
   B.  Appendices . . . . . . . . . . . . . . . . . . . . . . . . .  116
     B.1   Appendix 1 - Notes on Processing XML Elements  . . . . .  116
       B.1.1   Notes on Empty XML Elements  . . . . . . . . . . . .  116
       B.1.2   Notes on Illegal XML Processing  . . . . . . . . . .  116
       B.1.3   Example - XML Syntax Error . . . . . . . . . . . . .  116
       B.1.4   Example - Unknown XML Element  . . . . . . . . . . .  117
     B.2   Appendix 3: Notes on HTTP Client Compatibility . . . . .  118
     B.3   Changes  . . . . . . . . . . . . . . . . . . . . . . . .  119
       B.3.1   Changes in -06 . . . . . . . . . . . . . . . . . . .  119
       B.3.2   Changes in -07 . . . . . . . . . . . . . . . . . . .  119
       Intellectual Property and Copyright Statements . . . . . . .  121

1.  Introduction

   This is also document describes an extension to the case
   for HTML source files HTTP/1.1 protocol that are not processed by the server prior
   allows clients to
   transmission.

   However, the server can sometimes process HTML resources before they
   are transmitted as perform remote web content authoring operations.
   This extension provides a return coherent set of methods, headers, request
   entity body.  For example, a server-
   side-include directive within an HTML file might instruct a server body formats, and response entity body formats that provide
   operations for:

   Properties: The ability to
   replace the directive with another value, create, remove, and query information
   about Web pages, such as their authors, creation dates, etc.  Also,
   the current date.
   In this case, what is returned by GET (HTML plus date) differs from
   the persistent state ability to link pages of the resource (HTML plus directive).
   Typically there is no way any media type to access the HTML resource containing the
   unprocessed directive.

   Sometimes the entity returned by GET is the output related pages.

   Collections: The ability to create sets of documents and to retrieve
   a data-
   producing process that is described by one or more source resources
   (that may not even have hierarchical membership listing (like a location directory listing in the URI namespace).  A single
   data-producing process may dynamically generate the state of a
   potentially large number of output resources.  An example of this is a CGI script that describes file
   system).

   Locking: The ability to keep more than one person from working on a "finger" gateway process that maps part
   of
   document at the namespace of a server into finger requests, such same time.  This prevents the "lost update problem",
   in which modifications are lost as http://
   finger.example.com/finger_gateway/user@host.

   Although this problem would usefully be solved, interoperable WebDAV
   implementations have been widely deployed first one author then another
   writes changes without actually solving
   this problem.  Thus, merging the source vs.  output problem is not solved other author's changes.

   Namespace Operations: The ability to instruct the server to copy and
   move Web resources.

   Requirements and rationale for these operations are described in
   this specification, a
   companion document, "Requirements for a Distributed Authoring and has been deferred to
   Versioning Protocol for the World Wide Web" (RFC2291) [12].

   This standard does not specify the versioning operations suggested by
   RFC2291 [12].  That work was done in a separate document.

6.  Locking

   The ability document, "Versioning
   Extensions to lock WebDAV" (RFC3253) [14].

   The sections below provide a detailed introduction to resource provides a mechanism for serializing
   access
   properties (Section 4), collections of resources (Section 5), and
   locking operations (Section 6).  These sections introduce the
   abstractions manipulated by the WebDAV-specific HTTP methods
   (Section 8) and the new HTTP headers used with WebDAV methods
   (Section 9).

   While the status codes provided by HTTP/1.1 are sufficient to
   describe most error conditions encountered by WebDAV methods, there
   are some errors that resource.  Using a lock, an authoring client can
   provide a reasonable guarantee that another principal will do not modify
   a resource while it is being edited.  In this way, a client can
   prevent fall neatly into the "lost update" problem. existing categories.
   This specification allows locks to vary defines new status codes developed for WebDAV
   methods (Section 10) and describes existing HTTP status codes
   (Section 11) as used in WebDAV.  Since some WebDAV methods may
   operate over two client-specified
   parameters, many resources, the number Multi-Status response (Section 12)
   has been introduced to return status information for multiple
   resources.  Finally, this version of principals involved (exclusive vs.  shared) WebDAV introduces XML elements
   in error response bodies in Section 15.

   WebDAV uses XML [11] to marshal complicated request and the type response
   information, as well as to express metadata, so this specification
   contains definitions of access all XML elements used (Section 13).  WebDAV
   includes a few special rules on how to be granted.  This document defines locking
   for only one access type, write.  However, the syntax process  XML (Section 16)
   appearing in WebDAV so that it truly is extensible,
   and permits extensible.

   Finishing off the eventual specification of locking for other access
   types.

6.1  Exclusive Vs. Shared Locks

   The most basic form of lock is an exclusive lock.  Only one exclusive
   lock may exist are sections on any resource, whether what it is directly or indirectly
   locked means for a
   resource to be compliant with this specification (Section 7.5).  Exclusive locks avoid having 17), on
   internationalization support (Section 18), and on security
   (Section 19).

2.  Notational Conventions

   Since this document describes a set of extensions to merge results,
   without requiring any coordination other than the methods HTTP/1.1
   protocol, the augmented BNF used herein to describe protocol elements
   is exactly the same as described in section 2.1 of RFC2616 [7],
   including the rules about implied linear white-space.  Since this specification.

   However, there are times when
   augmented BNF uses the goal basic production rules provided in section 2.2
   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 RFC2616 [7], these rules apply to exercise
   their access rights.  Shared locks are provided for this case.  A
   shared lock allows multiple principals document as well.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to receive a lock.  Hence any
   principal with appropriate access can use be interpreted as described in RFC2119 [2].

3.  Terminology

   URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
   respectively.  These terms (and the lock.

   With shared locks there are two trust sets distinction between them) are
   defined in RFC2396 [5].

   Collection - A resource that affect contains a resource.
   The first trust set is created by access permissions.  Principals who
   are trusted, for example, may have permission to write to the
   resource.  Among those who have access permission to write to of URLs, which identify
   and locate member resources and which meet the
   resource, collections
   requirements (Section 5).

   Member URL - A URL which is a member of the set of principals who have taken out a shared lock also
   must trust each other, creating URLs contained by
   a (typically) smaller trust set
   within the access permission write set.

   Starting with every possible principal on collection.

   Internal Member URL - A Member URL that is immediately relative to
   the Internet, in most
   situations URL of the vast majority collection (the definition of these principals will not have write
   access to a immediately relative is
   given later (Section 5.2)).

   Property - A name/value pair that contains descriptive information
   about a resource.  Of the small number who do have write
   access, some principals may decide to guarantee their edits

   Live Property - A property whose semantics and syntax are free
   from overwrite conflicts enforced by using exclusive write locks.  Others may
   decide they trust their collaborators will not overwrite their work
   (the potential set of collaborators being
   the set server.  For example, the live "getcontentlength" property has
   its value, the length of principals who
   have write permission) and use a shared lock, which informs their
   collaborators that the entity returned by a principal may be working on GET request,
   automatically calculated by the server.

   Dead Property - A property whose semantics and syntax are not
   enforced by the resource. server.  The WebDAV extensions to HTTP do not need to provide all server only records the value of a dead
   property; the
   communications paths necessary client is responsible for principals to coordinate their
   activities.  When using shared locks, principals may use any out maintaining the consistency
   of
   band communication channel to coordinate their work (e.g., face-to-
   face interaction, written notes, post-it notes on the screen,
   telephone conversation, Email, etc.)  The intent syntax and semantics of a shared lock dead property.

   Principal - A "principal" is a distinct human or computational actor
   that initiates access to let collaborators know who else may be working on network resources.

4.  Data Model for Resource Properties

4.1  The Resource Property Model

   Properties are pieces of data that describe the state of a resource.

   Shared locks
   Properties are included because experience from web distributed
   authoring systems has indicated that exclusive locks data about data.

   Properties are often too
   rigid.  An exclusive lock is used in distributed authoring environments to enforce a particular editing
   process: take out an exclusive lock, read the resource, perform
   edits, write the resource, release the lock.  This editing process
   has the problem that locks are not always properly released, provide
   for
   example when a program crashes, or when a lock owner leaves without
   unlocking a resource.  While both timeouts efficient discovery and administrative action
   can be used to remove an offending lock, neither mechanism may be
   available when needed; the timeout may be long or the administrator
   may not be available.

6.2  Required Support

   A WebDAV compliant resource is not required to support locking in any
   form.  If management of resources.  For example, a
   'subject' property might allow for the resource does support locking it may choose to support
   any combination indexing of exclusive all resources by
   their subject, and shared locks for any access types.

   The reason an 'author' property might allow for this flexibility is that locking policy strikes to the
   very heart discovery
   of what authors have written which documents.

   The DAV property model consists of name/value pairs.  The name of a
   property identifies the resource management property's syntax and versioning systems employed semantics, and provides
   an address by various storage repositories.  These repositories require control
   over what sort of 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 sufficiently different which to merit
   exclusion refer to its syntax and semantics.

   There are two categories of certain locking features, this specification leaves
   locking as properties: "live" and "dead".  A live
   property has its syntax and semantics enforced by the sole axis server.  Live
   properties include cases where a) the value of negotiation within WebDAV.

6.3  Lock Tokens

   A lock token is a type property is read-
   only, maintained by the server, and b) the value of state token, represented as a URI, which
   identifies a particular lock.  A lock token the property is returned in
   maintained by the Lock-
   Token header in client, but the response to server performs syntax checking on
   submitted values.  All instances of a successful LOCK operation.  The
   lock token also appears in given live property MUST comply
   with the definition associated with that property name.  A dead
   property has its syntax and semantics enforced by the value of client; the lockdiscovery property,
   server merely records the value of which is returned in the body property verbatim.

4.2  Properties and HTTP Headers

   Properties already exist, in a limited sense, in HTTP message
   headers.  However, in distributed authoring environments a relatively
   large number of the response properties are needed to a
   successful LOCK operation (this property also includes describe the tokens state of
   other current locks on the resource).  Finally, the lockdiscovery
   property can be queried using PROPFIND a
   resource, and the token can be
   discovered that way.  Each lock has only one unique lock token.

   Lock token URIs MUST be unique across all resources for setting/returning them all time.
   This uniqueness constraint through HTTP headers is
   inefficient.  Thus a mechanism is needed which allows lock tokens a principal to be submitted across
   resources and servers without fear of confusion.

   This specification provides
   identify a lock token URI scheme called
   opaquelocktoken that meets set of properties in which the uniqueness requirements.  However
   resources are free principal is interested and
   to return any URI scheme so long as it meets the
   uniqueness requirements. set or retrieve just those properties.

4.3  XML Usage

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers.  Unlike HTTP/1.1, WebDAV encodes method parameter
   information either in an XML [11] request entity body, or in an HTTP
   header.  The IETF recommends using registered URI
   schemes use of XML to ensure uniqueness.

   Having a lock token provides no special access rights.  Anyone can
   find out anyone else's lock token encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility; and by performing lock discovery.
   Locks MUST be enforced based upon whatever authentication mechanism XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.

   In addition to encoding method parameters, XML is used by in WebDAV to
   encode the server, not based on responses from methods, providing the secrecy extensibility and
   internationalization advantages of the token values.

6.4  opaquelocktoken Lock Token URI Scheme XML for method output, as well as
   input.

   The opaquelocktoken URI scheme XML namespace extension [10] is designed to be unique across all
   resources for all time.  Due to also used in this uniqueness quality, a client may
   submit an opaque lock token specification
   in an If header on a resource other than
   the one that returned it.

   In order to guarantee uniqueness across all resources allow for all time
   the opaquelocktoken requires the use of the Universal Unique
   Identifier (UUID) mechanism, as described in ISO-11578 [12].

   Opaquelocktoken generators, however, have a choice new XML elements to be added without fear of how they create
   these tokens.  They
   colliding with other element names.  Although WebDAV request and
   response bodies can either generate a new UUID for every lock
   token they create or they be extended by arbitrary XML elements, which can create a single UUID  and then add
   extension characters.  If the second method is selected then the
   program generating
   be ignored by the extensions MUST guarantee that message recipient, an XML element in the same
   extension will never "DAV:"
   namespace SHOULD NOT be used twice with the associated UUID.

   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
   production is in the string representation of a UUID, as request or response body unless
   that XML element is explicitly defined in
   ISO-11578 [12]. an IETF RFC reviewed by a
   WebDAV working group.

   Note that white space (LWS) "DAV:" is not allowed between a scheme name defined solely to provide a
   namespace for WebDAV XML elements of this production.

   Extension = path  ; path and property names.  This practice
   is defined discouraged in section 3.3 part because registration of RFC2396 [6]

6.5  Lock Capability Discovery

   Since server lock support new scheme names is optional,
   difficult.  "DAV:" was defined as the WebDAV namespace before
   standard best practices emerged, and this namespace is kept and still
   used because of significant existing deployments, but this should not
   be emulated.

4.4  Property Values

   The value of a client trying to lock property is always a
   resource on (well-formed) XML fragment.

   XML has been chosen because it is a server can either try the lock flexible, self-describing,
   structured data format that supports rich schema definitions, and hope for the best,
   or perform some form
   because of discovery its support for multiple character sets.  XML's self-
   describing nature allows any property's value to determine what lock capabilities
   the server supports.  This is known as lock capability discovery.  A
   client can determine what lock types the server supports be extended by
   retrieving the supportedlock property.

   Any DAV compliant resource that supports
   adding new elements.  Older clients will not break when they
   encounter extensions because they will still have the LOCK method MUST support data specified
   in the supportedlock property.

6.6  Active Lock Discovery

   If another principal locks a resource that a principal wishes to
   access, it is useful original schema and will ignore elements they do not
   understand.  XML's support for the second principal multiple character sets allows any
   human-readable property to be able to find out
   who the first principal is.  For this purpose the lockdiscovery
   property is provided.  This property lists all outstanding locks,
   describes their type, encoded and where available, provides their lock token.

   Any DAV compliant resource that supports read in a character set
   familiar to the LOCK method MUST user.  XML's support for multiple human languages,
   using the lockdiscovery property.

6.7  Avoiding Lost Updates

   Although "xml:lang" attribute, handles cases where the locking mechanisms specified here provide some help in
   preventing lost updates, they cannot guarantee same
   character set is employed by multiple human languages.  Note that updates will
   never be lost.  Consider the following scenario:

   Two clients A and B are interested in editing the resource
   'index.html'.  Client A
   xml:lang scope is an HTTP client rather than a WebDAV
   client, and recursive, so does not know how to perform locking.

   Client A doesn't lock the document, but does a GET and begins
   editing.

   Client B does LOCK, performs xml:lang attribute on any element
   containing a GET and begins editing.

   Client B finishes editing, performs property name element applies to the property value
   unless it has been overridden by a PUT, then an UNLOCK.

   Client more locally scoped attribute.

   A performs a PUT, overwriting and losing all property is always represented in XML with an XML element
   consisting of B's changes.

   There are several reasons why the WebDAV protocol itself cannot
   prevent this situation.  First, it cannot force all clients to use
   locking because it must be compatible with HTTP clients property name.  The simplest example is an empty
   property, which is different from a property that do does not
   comprehend locking.  Second, it cannot require servers to support
   locking because exist.

   <R:title xmlns:R="http://www.example.com/ns/"></R:title>

   The value of a property appears inside the variety of repository implementations, some property name element.

   The value may be any kind of
   which rely on reservations well-formed XML content, including both
   text-only and merging rather than on locking.
   Finally, being stateless, it cannot enforce a sequence of operations
   like LOCK / GET / PUT / UNLOCK.

   WebDAV servers that support locking can reduce mixed content.  When the likelihood property value contains
   further XML elements, namespaces that
   clients will accidentally overwrite each other's changes by requiring
   clients to lock resources before modifying them.  Such servers would
   effectively prevent HTTP 1.0 are in scope for that part of
   the XML document apply within the property value as well, and HTTP 1.1 clients from modifying
   resources.

   WebDAV clients can MUST be good citizens by using a lock / retrieve /
   write /unlock sequence of operations (at least by default) whenever
   they interact with a WebDAV
   preserved in server that supports locking.

   HTTP 1.1 clients can storage for retransmission later.  Namespace
   prefixes need not be good citizens, avoiding overwriting other
   clients' changes, by using entity tags in If-Match headers with any
   requests that would modify resources.

   Information managers may attempt preserved due to prevent overwrites by
   implementing client-side procedures requiring locking before
   modifying WebDAV resources.

6.8  Locks and Multiple Bindings

   A resource the rules of prefix declaration
   in XML.

   Attributes on the property name element may convey information about
   the property, but are not considered part of the value.  However,
   when language information appears in the 'xml:lang' attribute on the
   property name element, the language information MUST be made available through more than preserved in
   server storage for retransmission later.  Note that a property only
   has one URI.  However
   locks apply to resources, value, in one language (or language MAY be left undefined),
   not URIs.  Therefore a LOCK request on multiple values in different languages or a
   resource single value in
   multiple languages.

   The XML attribute xml:space MUST NOT succeed if can not be honored by all the URIs
   through which the resource used to change white space
   handling.  White space in property values is addressable.

7.  Write Lock

   This section describes significant.

4.5  Property Names

   A property name is a universally unique identifier that is associated
   with a schema that provides information about the syntax and
   semantics specific to of the write lock type.
   The write lock is property.

   Because a specific instance of property's name is universally unique, clients can depend
   upon consistent behavior for a lock type, particular property across multiple
   resources, on the same and across different servers, so long as that
   property is "live" on the only
   lock type described resources in this specification.

   Write locks prevent unauthorized changes to resources.  In general
   terms, changes affected by write locks include changes to:

   o  the content of question, and the resource
   o  any dead property
   implementation of the resource
   o  any live property defined is faithful to be lockable (all its definition.

   The XML namespace mechanism, which is based on URIs [5], is used to
   name properties defined
      in this specification are lockable)
   o  the direct membership because it prevents namespace collisions and provides
   for varying degrees of the resource, if it administrative control.

   The property namespace is a collection
   o  the URL/location flat; that is, no hierarchy of properties
   is explicitly recognized.  Thus, if a resource

   The next few sections describe in more specific terms how write locks
   interact with various operations.

7.1  Methods Restricted by Write Locks property A write lock MUST prevent a principal without the lock from
   successfully executing and a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
   DELETE, or MKCOL property A/B
   exist on the locked resource.  All other current methods,
   GET in particular, function independently a resource, there is no recognition of any relationship
   between the lock.

   Note, however, two properties.  It is expected that as new methods are created it a separate
   specification will eventually be necessary produced which will address issues
   relating to specify how they interact with a write lock.

7.2  Write Locks and Lock Tokens

   A successful request for an exclusive or shared write lock MUST
   result in hierarchical properties.

   Finally, it is not possible to define the generation of same property twice on a unique lock token associated with the
   requesting principal.  Thus if five principals have
   single resource, as this would cause a shared write
   lock on collision in the same resource resource's
   property namespace.

4.6  Source Resources and Output Resources

   Some HTTP resources are dynamically generated by the server.  For
   these resources, there will presumably exists source code somewhere
   governing how that resource is generated.  The relationship of source
   files to output HTTP resources may be five lock tokens, one for
   each principal.

7.3  Write Locks and Properties

   While those without a write lock may not alter a property on to one, one to many, many
   to one or many to many.  There is no mechanism in HTTP to determine
   whether a resource it is still possible for the values of live properties to
   change, even while locked, due dynamic, let alone where its source files
   exist or how to author them.  Although this problem would usefully be
   solved, interoperable WebDAV implementations have been widely
   deployed without actually solving this problem, by dealing only with
   static resources.  Thus, the requirements of their schemas.
   Only dead properties and live properties defined to respect locks are
   guaranteed not to change while write locked.

7.4  Write Locks and Unmapped URLs

   It source vs. output problem is possible to lock an unmapped URL not solved
   in order this specification and has been deferred to lock the name for
   use. a separate document.

5.  Collections of Web Resources

   This is section provides a simple way to avoid description of a new type of Web resource,
   the lost-update problem on collection, and discusses its interactions with the
   creation HTTP URL
   namespace.  The purpose of a new collection resource (another way is to use If-None-Match
   header model
   collection-like objects (e.g., file system directories) within a
   server's namespace.

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

5.1  HTTP 1.1).  It has URL Namespace Model

   The HTTP URL namespace is a hierarchical namespace where the side benefit
   hierarchy is delimited with the "/" character.

   An HTTP URL namespace is said to be consistent if it meets the
   following conditions: for every URL in the HTTP hierarchy there
   exists a collection that contains that URL as an internal member.
   The root, or top-level collection of locking the new resource immediately for use namespace under
   consideration is exempt from the previous rule.  The top-level
   collection of the creator.

   The lost-update problem namespace under consideration is not an issue for collections because MKCOL
   can only be used to create a collection, not to overwrite an existing
   collection.  In order to immediately lock a necessarily
   the collection upon creation,
   clients identified by the absolute path '/', it may attempt to pipeline be
   identified by one or more path segments (e.g. /servlets/webdav/...)

   Neither HTTP/1.1 nor WebDAV require that the MKCOL and LOCK requests together.

   A lock request to an unmapped entire HTTP URL SHOULD result in the creation of an
   locked
   namespace be consistent -- a WebDAV-compatible resource with empty content.  A subsequent PUT request with
   the correct lock token SHOULD normally succeed, and this new request
   provides the content, content-type, content-language and other
   information as appropriate.

   In this situation, may not have
   a parent collection.  However, certain WebDAV server that was implemented from RFC2518
   MAY create "lock-null" resources which methods are special prohibited
   from producing results that cause namespace inconsistencies.

   Although implicit in RFC2616 [7] and unusual
   resources.  Historically, RFC2396 [5], any resource,
   including collection resources, MAY be identified by more than one
   URI.  For example, a lock-null resource:

   o  Responds with resource could be identified by multiple HTTP
   URLs.

5.2  Collection Resources

   A collection is a 404 or 405 to any DAV method except for PUT,
      MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
   o  Appears resource whose state consists of at least a list of
   internal member URLs and a set of properties, but which may have
   additional state such as entity bodies returned by GET.  An internal
   member URL MUST be immediately relative to a member base URL of its parent the
   collection.
   o  Disappears (URI becomes unmapped) if its lock goes away before it  That is, the internal member URL is converted equal to a regular resource.  (This must also happen if it
      is renamed or moved,
   containing collection's URL plus an additional segment for non-
   collection resources, or if any parent additional segment plus trailing slash "/"
   for collection resources, where segment is renamed or
      moved, because locks are tied to URLs).
   o  May be turned into a regular resource when a PUT request to the defined in section 3.3 of
   RFC2396 [5].

   Any given internal member URL is successful.  Ceases MUST only belong to be a lock-null resource.
   o  May be turned into a the collection when a MKCOL request
   once, i.e., it is illegal to have multiple instances of the same URL is
      successful.  Ceases to be
   in a lock-null resource.
   o  Has collection.  Properties defined values for lockdiscovery and supportedlock properties.

   However, interoperability and compliance problems have been found
   with lock-null resources.  Therefore, they are deprecated.  WebDAV
   servers SHOULD create regular locked empty resources, which are and on collections behave in every way exactly as normal
   do properties on non-collection resources.

   For all WebDAV compliant resources A locked empty resource:

   o  Can be read, deleted, moved, copied, and in all ways behave as a
      regular resource, not a lock-null resource.
   o  Appears as a member of its parent collection.
   o  SHOULD NOT disappear when its lock goes away (clients must
      therefore be responsible for cleaning up their own mess, as with
      any other operation)
   o  SHOULD default to having no content type.
   o  MAY NOT have values B, identified by URLs U and
   V, for properties like getcontentlanguage which
      haven't been specified yet by the client.

   o  May have content added with a PUT request.  MUST be able U is immediately relative to change
      content type.
   o V, B MUST NOT be turned into a collection.  A MKCOL request must fail collection
   that has U as it would to any existing resource.
   o  MUST have defined values for lockdiscovery an internal member URL.  So, if the resource with URL
   http://example.com/bar/blah is WebDAV compliant and supportedlock
      properties.
   o  The response MUST indicate that a if the resource was created, by use of
   with URL http://example.com/bar/ is WebDAV compliant then the "201 Created" response code (a LOCK request to an existing
   resource instead will result in 200 OK).  The body with URL http://example.com/bar/ must still
      include be a collection and
   must contain URL http://example.com/bar/blah as an internal member.

   Collection resources MAY list the lockdiscovery property, URLs of non-WebDAV compliant
   children in the HTTP URL namespace hierarchy as internal members but
   are not required to do so.  For example, if the resource with URL
   http://example.com/bar/blah is not WebDAV compliant and the URL
   http://example.com/bar/ identifies a LOCK request to collection then URL
   http://example.com/bar/blah may or may not be an
      existing resource.

   The client is expected to update internal member of
   the locked empty collection with URL http://example.com/bar/.

   If a WebDAV compliant resource shortly
   after locking it, using PUT and possibly PROPPATCH.  When has no WebDAV compliant children in
   the client
   uses PUT HTTP URL namespace hierarchy then the WebDAV compliant resource
   is not required to be a collection.

   There is a standing convention that when a collection is referred to overwrite
   by its name without a locked empty resource trailing slash, the client MUST supply
   a Content-Type server MAY handle the
   request as if any is known.  If the client supplies trailing slash were present.  In this case it
   SHOULD return a Content-
   Type value Content-Location header in the server MUST set that value (this requirement actually
   applies response, pointing to any resource that is overwritten but is particularly
   necessary for locked empty resources which are initially created with
   no Content-Type.

   Clients can easily interoperate both
   the URL ending with servers that support the
   deprecated lock-null resources "/".  For example, if a client invokes a
   method on http://example.bar/blah (no trailing slash), the server may
   respond as if the operation were invoked on http://example.com/blah/
   (trailing slash), and servers that support simpler
   locked empty resources by only attempting PUT after should return a LOCK Content-Location header with
   the value http://example.bar/blah/.  Wherever a server produces a URL
   referring to an
   unmapped URL, not MKCOL or GET.

7.5  Write Locks and Collections

   A write lock on a collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URLs of server MUST include the trailing
   slash.  In general clients SHOULD use the "/" form of collection by non-lock owners.

   A zero-depth lock on a collection affects changes
   names.

   Clients MUST be able to support the direct
   membership of that collection.  When a principal issues case where WebDAV resources are
   contained inside non-WebDAV resources.  For example, if a PUT OPTIONS
   response from "http://example.com/servlet/dav/collection" indicates
   WebDAV support, the client cannot assume that
   "http://example.com/servlet/dav/" or POST
   request its parent necessarily are
   WebDAV collections.

6.  Locking

   The ability to create lock a new resource in a write locked collection, or
   issues provides a DELETE mechanism for serializing
   access to that resource.  Using a lock, an existing internal member URL of authoring client can
   provide a write locked
   collection, this request MUST fail if the reasonable guarantee that another principal does will not provide
   the correct lock token for the locked collection. modify
   a resource while it is being edited.  In addition, this way, a depth-infinity lock affects all write operations client can
   prevent the "lost update" problem.

   This specification allows locks to
   all descendents of vary over two client-specified
   parameters, the locked collection.  With a depth-infinity
   lock, number of principals involved (exclusive vs. shared)
   and the root type of access to be granted.  This document defines locking
   for only one access type, write.  However, the lock syntax is directly locked, extensible,
   and all its
   descendants are indirectly locked.

   o  Any new resource added as a descendent permits the eventual specification of a depth-infinity locked
      collection becomes indirectly locked.
   o  Any indirectly locked resource moved out locking for other access
   types.

6.1  Exclusive Vs. Shared Locks

   The most basic form of the locked collection
      into lock is an unlocked collection exclusive lock.  Only one exclusive
   lock may exist on any resource, whether it is thereafter unlocked.

   o  Any indirectly locked resource moved out of a locked source
      collection into a depth-infinity locked target collection remains directly or indirectly
   locked but is now within the scope of the lock on the
      target collection (the target collection's lock token will
      thereafter be required (Section 7.7).  Exclusive locks avoid having to make further changes).

   If merge results,
   without requiring any coordination other than the methods described
   in this specification.

   However, there are times when the goal of a depth-infinity write LOCK request lock is issued not to exclude
   others from exercising an access right but rather to provide a collection
   containing member URLs identifying resources
   mechanism for principals to indicate that they intend to exercise
   their access rights.  Shared locks are currently
   locked in provided for this case.  A
   shared lock allows multiple principals to receive a manner which conflicts lock.  Hence any
   principal with appropriate access can use the write lock, the request
   MUST fail with lock.

   With shared locks there are two trust sets that affect a 423 (Locked) status code, and resource.
   The first trust set is created by access permissions.  Principals who
   are trusted, for example, may have permission to write to the response SHOULD
   contain
   resource.  Among those who have access permission to write to the 'missing-lock-token' precondition.

   If a lock owner causes
   resource, the URL set of principals who have taken out a resource to be added as an
   internal member URL of shared lock also
   must trust each other, creating a depth-infinity locked collection then (typically) smaller trust set
   within the
   new resource MUST be automatically added to access permission write set.

   Starting with every possible principal on the lock.  This is Internet, in most
   situations the
   only mechanism that allows a resource to be added vast majority of these principals will not have write
   access to a write lock.
   Thus, for example, if given resource.  Of the collection /a/b/ is small number who do have write
   access, some principals may decide to guarantee their edits are free
   from overwrite conflicts by using exclusive write locked and the
   resource /c is moved to /a/b/c then resource /a/b/c locks.  Others may
   decide they trust their collaborators will be added to not overwrite their work
   (the potential set of collaborators being the set of principals who
   have write lock.

7.6  Write Locks permission) and the If Request Header

   If use a user agent is not required to have knowledge about shared lock, which informs their
   collaborators that a lock when
   requesting an operation principal may be working on a locked resource, the following scenario
   might occur.  Program A, run by User A, takes out a write lock on a resource.  Program B, also run by User A, has no knowledge

   The WebDAV extensions to HTTP do not need to provide all of the
   lock taken
   communications paths necessary for principals to coordinate their
   activities.  When using shared locks, principals may use any out by Program A, yet performs a PUT of
   band communication channel to coordinate their work (e.g., face-to-
   face interaction, written notes, post-it notes on the locked screen,
   telephone conversation, Email, etc.)  The intent of a shared lock is
   to let collaborators know who else may be working on a resource.  In this scenario, the PUT succeeds because

   Shared locks are
   associated with a principal, not a program, and thus program B, included because it is acting with principal AȔs credential, experience from web distributed
   authoring systems has indicated that exclusive locks are often too
   rigid.  An exclusive lock is allowed used to
   perform the PUT.  However, had program B known about the enforce a particular editing
   process: take out an exclusive lock, it
   would not have overwritten read the resource, perform
   edits, write the resource, preferring instead to
   present a dialog box describing release the conflict to lock.  This editing process
   has the user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring problem that locks taken out by other programs with the
   same authorization.

   In order to prevent these collisions are not always properly released, for
   example when a program crashes, or when a lock token MUST owner leaves without
   unlocking a resource.  While both timeouts and administrative action
   can be submitted
   by used to remove an authorized principal for all locked resources that a method offending lock, neither mechanism may
   change be
   available when needed; the timeout may be long or the method MUST fail. administrator
   may not be available.

6.2  Required Support

   A lock token WebDAV compliant resource is submitted when it
   appears not required to support locking in an any
   form.  If header.  For example, if a the resource is does support locking it may choose to be moved
   and both the source support
   any combination of exclusive and destination are locked then two lock tokens
   must be submitted in the if header, one shared locks for any access types.

   The reason for this flexibility is that locking policy strikes to the source and
   very heart of the other resource management and versioning systems employed
   by various storage repositories.  These repositories require control
   over what sort of locking will be made available.  For example, some
   repositories only support shared write locks while others only
   provide support for the destination.

   Example - Write Lock

      >>Request

        COPY /~fielding/index.html HTTP/1.1
        Host: www.ics.uci.edu
        Destination: http://www.ics.uci.edu/users/f/fielding/index.html
        If: <http://www.ics.uci.edu/users/f/fielding/index.html>
            (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

      >>Response

        HTTP/1.1 204 No Content

   In exclusive write locks while yet others use no
   locking at all.  As each system is sufficiently different to merit
   exclusion of certain locking features, this example, even though both specification leaves
   locking as the source and destination are
   locked, only one sole axis of negotiation within WebDAV.

6.3  Lock Tokens

   A lock token must be submitted, for the is a type of state token, represented as a URI, which
   identifies a particular lock.  A lock on the
   destination.  This token is because returned in the source resource is not modified by
   a COPY, and hence unaffected by Lock-
   Token header in the write lock.  In this example,
   user agent authentication has previously occurred via response to a mechanism
   outside successful LOCK operation.  The
   lock token also appears in the scope value of the HTTP protocol, lockdiscovery property,
   the value of which is returned in the underlying transport
   layer.

7.7  Write Locks and COPY/MOVE

   A COPY method invocation MUST NOT duplicate any write body of the response to a
   successful LOCK operation (this property also includes the tokens of
   other current locks active on the source.  However, as previously noted, if resource).  Finally, the COPY copies lockdiscovery
   property can be queried using PROPFIND and the
   resource into a collection token can be
   discovered that is locked with "Depth: infinity",
   then the resource will way.  Each lock has only one unique lock token.

   Lock token URIs MUST be added unique across all resources for all time.
   This uniqueness constraint allows lock tokens to the lock.

   A successful MOVE request on be submitted across
   resources and servers without fear of confusion.

   This specification provides a write locked resource MUST NOT move
   the write lock with token URI scheme called
   opaquelocktoken that meets the resource.  However, uniqueness requirements.  However
   resources are free to return any URI scheme so long as it meets the resource is subject
   uniqueness requirements.  According to being added current IETF best practices,
   implementations SHOULD use registered URI schemes to an existing ensure
   uniqueness.

   Submitting a lock at the destination (see Section
   7.5).  For example, if token does not confer full privilege to use the MOVE makes
   lock token or modify the resource a child of a
   collection that is locked with "Depth: infinity", then the resource
   will resource.  Anyone can find out anyone
   else's lock token by performing lock discovery.  Write access and
   other privileges MUST be added to that collection's lock.  Additionally, if a resource
   locked with "Depth: infinity" is moved to a destination that is
   within enforced through normal privilege or
   authentication mechanisms, not based on the scope slight obscurity of the same lock (e.g., within the namespace tree
   covered by the lock), the moved resource will again be
   token values.

   Since lock tokens are unique, a added to the
   lock.  In both these examples, as specified client MAY submit a lock token in Section 7.6, an
   If header must be submitted containing on a lock token for both the source
   and destination.

7.8  Refreshing Write Locks

   A client MUST NOT submit resource other than the same write lock request twice.  Note one that returned it.

6.4  Lock Token URI Schemes

   In order to guarantee uniqueness across all resources for all time a client is always aware it is resubmitting
   server MAY use the same Universal Unique  Identifier (UUID) [9] mechanism
   to generate a lock
   request because it must include token:

   urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

   The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
   while still guaranteeing the lock token in the If header in
   order to make the request be unique across all
   resources for all time.  With the 'opaquelocktoken' scheme, the
   server MAY reuse a resource that is already locked.

   However, a client may submit a LOCK method UUID with an extension characters added.  If header but
   without a body.  This form of LOCK the
   server does this then the algorithm generating the extensions MUST only be used to "refresh" a
   lock.  Meaning, at minimum,
   guarantee that any timers associated with the lock
   MUST same extension will never be re-set.

   A server may return a Timeout header used twice with a lock refresh that is
   different than the Timeout header returned when
   associated UUID.

   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
   production is the lock was
   originally requested.  Additionally clients may submit Timeout
   headers string representation of arbitrary value with their lock refresh requests.
   Servers, as always, may ignore Timeout headers submitted by the
   client. a UUID.  Note that timeout white
   space (LWS) is measured in seconds remaining until
   expiration.

   If an error not allowed between elements of this production.

   Extension = path  ; path is received defined in response to section 3.3 of RFC2396 [5]

6.5  Lock Capability Discovery

   Since server lock support is optional, a refresh LOCK request the client MUST NOT assume that trying to lock a
   resource on a server can either try the lock was refreshed.

8.  HTTP Methods for Distributed Authoring

8.1  General request and response handling

8.1.1  Use of XML

   Some hope for the best,
   or perform some form of discovery to determine what lock capabilities
   the server supports.  This is known as lock capability discovery.  A
   client can determine what lock types the following new HTTP methods use XML as a request and
   response format.  All server supports by
   retrieving the supportedlock property.

   Any DAV compliant clients and resources MUST use
   XML parsers resource that are compliant with XML [11] and XML Namespaces [10].
   All XML used in either requests or responses MUST be, at minimum,
   well formed and use namespaces correctly.  If a server receives non-
   wellformed XML in a request it supports the LOCK method MUST reject support
   the entire request with a
   400 (Bad Request). supportedlock property.

6.6  Active Lock Discovery

   If another principal locks a client receives ill-formed XML in resource that a response
   then principal wishes to
   access, it MUST NOT assume anything about is useful for the outcome of second principal to be able to find out
   who the executed
   method first principal is.  For this purpose the lockdiscovery
   property is provided.  This property lists all outstanding locks,
   describes their type, and SHOULD treat where available, provides their lock token.

   Any DAV compliant resource that supports the server as malfunctioning.

8.1.2  Required Bodies in Requests

   Some of these new methods do not define bodies.  Servers LOCK method MUST examine
   all requests for a body, even when a body was support
   the lockdiscovery property.

6.7  Locks and Multiple Bindings

   A resource may be made available through more than one URI.  However
   locks apply to resources, not expected.  In cases
   where URIs.  Therefore a LOCK request body is present but would on a
   resource MUST NOT succeed if can not be ignored honored by a server, all the
   server MUST reject URIs
   through which the request with 415 (Unsupported Media Type). resource is addressable.

7.  Write Lock

   This informs section describes the client (which may have been attempting semantics specific to use an
   extension) that the body could not be processed as they intended.

8.1.3  Use write lock type.
   The write lock is a specific instance of Location header in responses

   When the Location header a lock type, and is used the only
   lock type described in this specification.

   An exclusive write lock will prevent parallel changes to a response, it is used resource
   by any principal other than the
   server to indicate write lock holder.  In general terms,
   changes affected by write locks include changes to:

   o  the preferred address for content of the target resource

   o  any dead property of the request.  Whenever resource

   o  any live property defined to be lockable (all properties defined
      in this specification are lockable)

   o  the server has a preferred address, direct membership of the resource, if it should
   use that address consistently.  This means that when a response
   contains is a Location header, all the URLs in collection

   o  the response body (e.g. URL/location of a Multi-Status) should be consistent (most importantly, should use resource

   The next few sections describe in more specific terms how write locks
   interact with various operations.

7.1  Lock Owner

   The creator of the same host and port).

8.1.4  Required Response Headers: Date

   Note that HTTP 1.1 requires lock is the Date header in all responses if
   possible.

8.1.5  ETag

   HTTP 1.1 recommends lock owner.  The server MUST restrict
   the use usage of the ETag header in responses lock token to GET the lock owner (both for shared and PUT requests.  Correct use of ETags is even more important in a
   distributed authoring environment, because ETags are necessary along
   with
   exclusive locks to avoid -- for multi-user shared lock cases, each
   authenticated principal MUST obtain its own shared lock).

   The server MAY allow privileged users other than the lost-update problem.  A client might fail lock owner to
   renew
   destroy a lock, for example when the lock times out and (for example, the client is
   accidentally offline resource owner or in the middle of an administrator)
   as a long upload.  When special case of lock usage.

   If an anonymous user requests a
   client fails to renew the lock, it's quite possible the resource can
   still be relocked and server MAY refuse the user can go on editing, as long as no
   changes were made
   request.

7.2  Methods Restricted by Write Locks

   A server MUST reject any write request that alters a write-locked
   resource unless a valid lock token is provided.  The write operations
   defined in the meantime.  ETags HTTP and WebDAV are required for the client
   to be able to distinguish this case.  Otherwise, the client is forced
   to ask the user whether to overwrite PUT, POST, PROPPATCH, LOCK, UNLOCK,
   MOVE, COPY (for the resource on destination resource), DELETE, and MKCOL.  All
   other HTTP/WebDAV methods, GET in particular, function independently
   of the server
   without even being able to tell lock.  A shared write lock prevents the user whether same operations,
   however it also allows access by any principal that has changed.
   Timestamps do not solve this problem nearly as well as ETags.

   WebDAV servers SHOULD support strong ETags for all resources a shared
   write lock on the same resource.

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

7.3  Write Locks and Lock Tokens

   A successful request for a resource, the server an exclusive or shared write lock MUST
   return the ETag header
   result in all PUT and GET responses to that resource,
   as well as provide the same value for generation of a unique lock token associated with the 'getetag' property.

   Because clients may be forced to prompt users or throw away changed
   content
   requesting principal.  Thus if the ETag changes, five principals have a WebDAV server MUST not change shared write
   lock on the ETag
   (or getlastmodified value) same resource there will be five lock tokens, one for
   each principal.

7.4  Write Locks and Properties

   While those without a write lock may not alter a property on a
   resource that has an unchanged body.
   The ETag represents it is still possible for the state values of live properties to
   change, even while locked, due to the body or contents requirements of the
   resource.  There is no similar way to tell if their schemas.
   Only dead properties have
   changed.

8.1.6  Including error response bodies

   HTTP and WebDAV did live properties defined to respect locks are
   guaranteed not use the bodies of most error responses for
   machine-parsable information until DeltaV introduced a mechanism to
   include more specific information in change while write locked.

7.5  Avoiding Lost Updates

   Although the body of an error response
   (section 1.6 of RFC3253 [18]).  The mechanism is appropriate to use
   with any error response write locks provide some help in preventing lost
   updates, they cannot guarantee that may take a body but does not already
   have a body defined.  The mechanism updates will never be lost.
   Consider the following scenario:

   Two clients A and B are interested in editing the resource
   'index.html'.  Client A is particularly appropriate when an HTTP client rather than a status code can mean many things (for example, 400 Bad Request can
   mean required headers are missing, headers are incorrectly formatted,
   or much more).

   This mechanism WebDAV
   client, and so does not take know how to perform locking.

   Client A doesn't lock the place of using document, but does a correct numeric
   error code as defined here or in HTTP, because the client MUST always
   be able to take GET and begins
   editing.

   Client B does LOCK, performs a reasonable course GET and begins editing.

   Client B finishes editing, performs a PUT, then an UNLOCK.

   Client A performs a PUT, overwriting and losing all of action based only on B's changes.

   There are several reasons why the
   numeric error.  However, WebDAV protocol itself cannot
   prevent this situation.  First, it does remove the need cannot force all clients to define new
   numeric error codes, avoiding use
   locking because it must be compatible with HTTP clients that do not
   comprehend locking.  Second, it cannot require servers to support
   locking because of the confusion variety of who is allowed to
   define such new codes.  The codes used in this mechanism are XML
   elements in a namespace, so naturally any group defining repository implementations, some of
   which rely on reservations and merging rather than on locking.
   Finally, being stateless, it cannot enforce a new error
   code sequence of operations
   like LOCK / GET / PUT / UNLOCK.

   WebDAV servers that support locking can use their own namespace.  As always, reduce the "DAV:" namespace is
   reserved for use likelihood that
   clients will accidentally overwrite each other's changes by IETF-chartered requiring
   clients to lock resources before modifying them.  Such servers would
   effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
   resources.

   WebDAV working groups.

   A server supporting "bis" SHOULD include a specific XML error code in clients can be good citizens by using a "DAV:error" response body element, when lock / retrieve /
   write /unlock sequence of operations (at least by default) whenever
   they interact with a specific XML error code
   is defined WebDAV server that supports locking.

   HTTP 1.1 clients can be good citizens, avoiding overwriting other
   clients' changes, by using entity tags in this document.  The Č¼DAV:errorČ« element If-Match headers with any
   requests that would modify resources.

   Information managers may contain
   multiple elements describing specific errors.  For error conditions
   not specified in this document, the server MAY simply choose an
   appropriate numeric status and leave the response body blank.

        HTTP/1.1 403 Forbidden
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:error xmlns:D="DAV:">
          <D:forbid-external-entities/>
        </D:error>

   In this specification, both the numeric attempt to prevent overwrites by
   implementing client-side procedures requiring locking before
   modifying WebDAV resources.

7.6  Write Locks and the XML error code are
   defined for some failure situations, in which case the XML error code
   must have the "DAV:" namespace, appear Unmapped URLs

   It is possible to lock an unmapped URL in order to lock the "error" root element,
   and be returned in name for
   use.  This is a body with simple way to avoid the numeric error code specified.

8.2  PROPFIND

   The PROPFIND method retrieves properties defined lost-update problem on the
   creation of a new resource
   identified by (another way is to use If-None-Match
   header specified in HTTP 1.1).  It has the Request-URI, if side benefit of locking
   the new resource does immediately for use of the creator.

   The lost-update problem is not have any
   internal members, or on an issue for collections because MKCOL
   can only be used to create a collection, not to overwrite an existing
   collection.  In order to immediately lock a collection upon creation,
   clients may attempt to pipeline the MKCOL and LOCK requests together.

   A lock request to an unmapped URL SHOULD result in the creation of an
   locked resource identified by with empty content.  A subsequent PUT request with
   the Request-URI correct lock token SHOULD normally succeed, and potentially its member resources, if this new request
   provides the resource is content, content-type, content-language and other
   information as appropriate.

   In this situation, a collection WebDAV server that has internal member URLs.  All DAV compliant was implemented from RFC2518
   MAY create "lock-null" resources MUST
   support the PROPFIND method which are special and the propfind XML element (Section
   13.25) along unusual
   resources.  Historically, a lock-null resource:

   o  Responds with all XML elements defined a 404 or 405 to any DAV method except for use with that element.

   A client may submit PUT,
      MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.

   o  Appears as a member of its parent collection.

   o  Disappears (URI becomes unmapped) if its lock goes away before it
      is converted to a regular resource.  (This must also happen if it
      is renamed or moved, or if any parent collection is renamed or
      moved, because locks are tied to URLs).

   o  May be turned into a Depth header with regular resource when a value of "0", "1", or
   "infinity" with PUT request to the
      URL is successful.  Ceases to be a PROPFIND on lock-null resource.

   o  May be turned into a collection resource.  Servers MUST
   support when a MKCOL request to the "0", "1" URL is
      successful.  Ceases to be a lock-null resource.

   o  Has defined values for lockdiscovery and "infinity" behaviors on WebDAV-compliant supportedlock properties.

   However, interoperability and compliance problems have been found
   with lock-null resources.  By default, the PROPFIND method without a Depth header
   MUST act  Therefore, they are deprecated.  WebDAV
   servers SHOULD create regular locked empty resources, which are and
   behave in every way as if a "Depth: infinity" header was included. normal resources.  A client may submit a propfind XML element locked empty resource:

   o  Can be read, deleted, moved, copied, and in the body of the request
   method describing what information is being requested.  It is
   possible to request: all ways behave as a
      regular resource, not a lock-null resource.

   o  Request particular property values, by naming the properties
      desired within the 'prop' element (the ordering  Appears as a member of properties in
      here MAY be ignored by server) its parent collection.

   o  Request all dead property values, by using 'dead-props' element.
      This can  SHOULD NOT disappear when its lock goes away (clients must
      therefore be combined with retrieving specific live properties
      named as above.  Servers advertising support responsible for RFC2518bis MUST
      support this feature. cleaning up their own mess, as with
      any other operation)

   o  Request property values for those properties defined in this
      specification plus dead properties, by using 'allprop' element  SHOULD default to having no content type.

   o  Request a list of names of all the  MAY NOT have values for properties defined on the
      resource, like getcontentlanguage which
      haven't been specified yet by using the 'propname' element.

   A client may choose not to submit client.

   o  May have content added with a request body.  An empty PROPFIND
   request body PUT request.  MUST be treated able to change
      content type.

   o  MUST NOT be turned into a collection.  A MKCOL request must fail
      as if it were an 'allprop' request.

   Note that 'allprop' does not return would to any existing resource.

   o  MUST have defined values for all live properties.
   WebDAV servers increasingly have expensively-calculated or lengthy
   properties (see RFC3253 [18] and RFC3744 [19]) and do not return all
   properties already.  Instead, WebDAV clients can use propname
   requests to discover what live properties exist, and request named
   properties when retrieving values.  A WebDAV server MAY omit certain
   live properties from other specifications when responding to an
   allprop request from an older client, and MAY return only custom
   (dead) properties lockdiscovery and those defined in this specification.

   All servers MUST support returning a response of content type text/
   xml or application/xml that contains a multistatus XML element that
   describes the results of the attempts to retrieve the various supportedlock
      properties.

   o  The multistatus contains one response element for each MUST indicate that a resource in the scope was created, by use of
      the "201 Created" response code (a LOCK request (in no required order) or may be
   empty if no resources match the request.

   If there is to an error retrieving a property then a proper error existing
      resource instead will result
   MUST be included in 200 OK).  The body must still
      include the response.  A lockdiscovery property, as with a LOCK request to retrieve the value of
   a property which does not exist is an error
      existing resource.

   The client is expected to update the locked empty resource shortly
   after locking it, using PUT and MUST be noted, if possibly PROPPATCH.  When the
   response client
   uses PUT to overwrite a multistatus XML element, with a response XML element
   which contains a 404 (Not Found) status value.

   Consequently, the multistatus XML element for a collection locked empty resource
   with member URLs the client MUST include supply
   a response XML element for each member
   URL of Content-Type if any is known.  If the collection, to whatever depth was requested.  Each
   response XML element client supplies a Content-
   Type value the server MUST contain an href XML element set that gives the
   URL of the value (this requirement actually
   applies to any resource on that is overwritten but is particularly
   necessary for locked empty resources which the properties in the prop XML element are defined.  URLs for collections appearing in initially created with
   no Content-Type.

   Clients can easily interoperate both with servers that support the results MUST end
   in a slash character.  Results for
   deprecated lock-null resources and servers that support simpler
   locked empty resources by only attempting PUT after a PROPFIND LOCK to an
   unmapped URL, not MKCOL or GET.

7.7  Write Locks and Collections

   A write lock on a collection
   resource with internal collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URLs are returned as a flat list whose
   order of entries is not significant. the collection by non-lock owners.

   A server enumerating zero-depth lock on a collection affects changes to the members direct
   membership of that collection.  When a collection using absolute URLs
   in principal issues a PROPFIND response MUST use write
   request to create a common prefix new resource in those URLs, and a write locked collection, or
   isses a DELETE, MOVE or other request that prefix MUST be the absolute would remove an existing
   internal member URL used in of a write locked collection or change the response to refer to
   binding name, this request MUST fail if the parent collection.

   Unless otherwise notified, clients may expect that principal does not
   provide the URL correct lock token for the
   parent collection in the PROPFIND response will be the same URL locked collection.

   This means that
   was used to refer to the parent if a collection is locked (depth 0 or infinity), its
   lock-token is required in all these cases:

   o  DELETE a collection's direct internal member

   o  MOVE a member out of the PROPFIND request.
   Servers MAY use an alternate URL for the parent collection in

   o  MOVE a
   PROPFIND response, but in this case member into the server MUST include collection, unless it overwrites a
   Content-Location header whose value pre-
      existing member

   o  MOVE to rename it within a collection,

   o  COPY a member into a collection, unless it overwrites a pre-
      existing member

   o  PUT or MKCOL request which would create a new member.

   The collection's lock token is required in addition to the lock token
   on the internal member itself, if it is locked separately.

   In addition, a depth-infinity lock affects all write operations to
   all descendents of the fully-qualified URL used
   by locked collection.  With a depth-infinity
   lock, the server to refer to root of the parent lock is directly locked, and all its
   descendants are indirectly locked.

   o  Any new resource added as a descendent of a depth-infinity locked
      collection in this response.

   Clients expect the fully-qualified URLs becomes indirectly locked.

   o  Any indirectly locked resource moved out of members the locked collection
      into an unlocked collection is thereafter unlocked.

   o  Any indirectly locked resource moved out of a locked source
      collection to
   have into a common prefix which depth-infinity locked target collection remains
      indirectly locked but is now within the fully-qualified URL scope of the parent
   collection itself.

   URLs in a PROPFIND response body MAY be represented as fully-
   qualified URLs, in which case they must all contain lock on the full parent
      target collection URL (scheme, host, port, and absolute path).
   Alternatively, these URLs MAY (the target collection's lock token will
      thereafter be absolute paths (not containing
   scheme, host or port), but in this case they must all still contain
   the full parent collection path. required to make further changes).

   If a server allows resource names to include characters that arenȔt
   legal in HTTP URL paths, these characters must be URI-escaped on the
   wire.  For example, it depth-infinity write LOCK request is illegal issued to use a space character or double-
   quote collection
   containing member URLs identifying resources that are currently
   locked in a URI [6].  URIs appearing in PROPFIND or PROPPATCH XML
   bodies (or other XML marshalling defined in this specification) are
   still subject to all URI rules, including forbidden characters.

   Properties may be subject to access control.  In manner which conflicts with the write lock, the case of allprop request
   MUST fail with a 423 (Locked) status code, and propname, if the response SHOULD
   contain the 'missing-lock-token' precondition.

   If a principal does not have lock owner causes the right URL of a resource to know whether be added as an
   internal member URL of a particular property exists depth-infinity locked collection then the property MAY be silently
   excluded from the response.

   The results of this method SHOULD NOT
   new resource MUST be cached.

8.2.1  Example - Retrieving Named Properties

      >>Request

        PROPFIND  /file HTTP/1.1
        Host: www.example.com
        Content-type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:">
         <D:prop xmlns:R="http://www.example.com/boxschema/">
           <R:bigbox/>
           <R:author/>
           <R:DingALing/>
           <R:Random/>
         </D:prop>
        </D:propfind>

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx
        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:">
         <D:response xmlns:R="http://www.example.com/boxschema/">
           <D:href>http://www.example.com/file</D:href>
           <D:propstat>
             <D:prop>
               <R:bigbox>
                 <R:BoxType>Box type A</R:BoxType>
               </R:bigbox>
               <R:author>
                 <R:Name>J.J. Johnson</R:Name>
               </R:author>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
           <D:propstat>
             <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 automatically added to the
        DingALing property.
             </D:responsedescription>
           </D:propstat>
         </D:response>
         <D:responsedescription> There has been an access violation error.
         </D:responsedescription>
        </D:multistatus>

   In this example, PROPFIND lock.  This is executed on a non-collection resource
   http://www.example.com/file.  The propfind XML element specifies the
   name of four properties whose values are being requested.  In this
   case
   only two properties were returned, since the principal issuing
   the request did not have sufficient access rights to see the third
   and fourth properties.

8.2.2  Example - Retrieving Named and Dead Properties

      >>Request

        PROPFIND /mycol/ HTTP/1.1
        Host: www.example.com
        Depth: 1
        Content-type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:">
         <D:prop>
           <D:creationdate/>
           <D:getlastmodified/>
         </D:prop>
         <D:dead-props/>
        </D:propfind>

   In this example, PROPFIND is executed on mechanism that allows a resource to be added to a write lock.
   Thus, for example, if the collection /a/b/ is write locked and the
   resource http:/
   /www.example.com/mycol/.  The client requests /c is moved to /a/b/c then resource /a/b/c will be added to
   the values of two
   specific live properties plus all dead properties (names write lock.

7.8  Write Locks and values).
   The response the If Request Header

   If a user agent is not shown.

8.2.3  Example - Using propname required to Retrieve all Property Names

      >>Request
        PROPFIND  /container/ HTTP/1.1
        Host: www.example.com
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <multistatus xmlns="DAV:">
         <response>
           <href>http://www.example.com/container/</href>
           <propstat>
             <prop xmlns:R="http://www.example.com/boxschema/">
               <R:bigbox/>
               <R:author/>
               <creationdate/>
               <displayname/>
               <resourcetype/>
               <supportedlock/>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
         </response>
         <response>
           <href>http://www.example.com/container/front.html</href>
           <propstat>
             <prop xmlns:R="http://www.example.com/boxschema/">
               <R:bigbox/>
               <creationdate/>
               <displayname/>
               <getcontentlength/>
               <getcontenttype/>
               <getetag/>
               <getlastmodified/>
               <resourcetype/>
               <supportedlock/>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
         </response>
        </multistatus>

   In this example, PROPFIND is invoked have knowledge about a lock when
   requesting an operation on a locked resource, the collection resource
   http://www.example.com/container/, with following scenario
   might occur.  Program A, run by User A, takes out a propfind XML element
   containing write lock on a
   resource.  Program B, also run by User A, has no knowledge of the propname XML element, meaning
   lock taken out by Program A, yet performs a PUT to the name of all
   properties should be returned.  Since no Depth header locked
   resource.  In this scenario, the PUT succeeds because locks are
   associated with a principal, not a program, and thus program B,
   because it is acting with principal Ais credential, is present, allowed to
   perform the PUT.  However, had program B known about the lock, it
   assumes its default value of "infinity", meaning
   would not have overwritten the name of resource, preferring instead to
   present a dialog box describing the
   properties on conflict to the collection and all its descendents should be
   returned.

   Consistent user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by other programs with the previous
   same authorization.

   In order to prevent these collisions a lock token MUST be submitted
   by an authorized principal for all locked resources that a method may
   change or the method MUST fail.  A lock token is submitted when it
   appears in an If header.  For example, if a resource http://
   www.example.com/container/ has six properties defined on it: bigbox is to be moved
   and author in both the "http://www.example.com/boxschema/" namespace, and
   creationdate, displayname, resourcetype, source and supportedlock destination are locked then two lock tokens
   must be submitted in the
   "DAV:" namespace.

   The resource http://www.example.com/container/index.html, a member of
   the "container" collection, has nine properties defined on it, bigbox
   in if header, one for the "http://www.example.com/boxschema/" namespace and,
   creationdate, displayname, getcontentlength, getcontenttype, getetag,
   getlastmodified, resourcetype, source and supportedlock in the "DAV:"
   namespace.

   This example also demonstrates other
   for the use of XML namespace scoping destination.

   Example - Write Lock

      >>Request

        COPY /~fielding/index.html HTTP/1.1
        Host: www.ics.uci.edu
        Destination: http://www.ics.uci.edu/users/f/fielding/index.html
        If: <http://www.ics.uci.edu/users/f/fielding/index.html>
            (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

      >>Response

        HTTP/1.1 204 No Content

   In this example, even though both the source and destination are
   locked, only one lock token must be submitted, for the default namespace.  Since lock on the "xmlns" attribute does
   destination.  This is because the source resource is not contain modified by
   a prefix, the namespace applies COPY, and hence unaffected by default to all enclosed elements.
   Hence, all elements which do not explicitly state the namespace to
   which they belong are members write lock.  In this example,
   user agent authentication has previously occurred via a mechanism
   outside the scope of the "DAV:" namespace schema.

8.2.4  PROPFIND Request Errors

   PROPFIND requests may also fail entirely, before HTTP protocol, in the server even gets
   a chance to evaluate individual properties.  404 (Not Found) underlying transport
   layer.

7.9  Write Locks and 401
   (Unauthorized) are possible COPY/MOVE

   A COPY method invocation MUST NOT duplicate any write locks active on
   the source.  However, as previously noted, if the COPY copies the
   resource into a collection that is locked with every request.  These are some
   other notable errors.

   403 Forbidden  - "Depth: infinity",
   then the resource will be added to the lock.

   A server MAY reject all PROPFIND requests successful MOVE request on
   collections a write locked resource MUST NOT move
   the write lock with depth header the resource.  However, the resource is subject
   to being added to an existing lock at the destination (see
   Section 7.7).  For example, if the MOVE makes the resource a child of "Infinity", in which case it SHOULD
   use this error
   a collection that is locked with "Depth: infinity", then the element 'propfind-infinite-depth-forbidden'
   inside resource
   will be added to that collection's lock.  Additionally, if a resource
   locked with "Depth: infinity" is moved to a destination that is
   within the body.

8.3  PROPPATCH

   The PROPPATCH method processes instructions specified in scope of the request
   body to set and/or remove properties defined on same lock (e.g., within the resource
   identified namespace tree
   covered by the Request-URI.

   All DAV compliant resources MUST support lock), the PROPPATCH method and
   MUST process instructions that are moved resource will again be a added to the
   lock.  In both these examples, as specified using in Section 7.8, an If
   header must be submitted containing a lock token for both the
   propertyupdate, set, source
   and remove XML elements.  Execution of the
   directives in this method is, of course, subject to access control
   constraints.  DAV compliant resources SHOULD support destination.

7.10  Refreshing Write Locks

   A client MUST NOT submit the setting of
   arbitrary dead properties.

   The same write lock request message body of twice.  Note
   that a PROPPATCH method MUST contain client is always aware it is resubmitting the
   propertyupdate XML element.  Instruction processing MUST occur same lock
   request because it must include the lock token in the If header in
   document
   order (an exception to make the normal rule request for a resource that ordering is
   irrelevant).  Instructions already locked.

   However, a client may submit a LOCK method with an If header but
   without a body.  This form of LOCK MUST either all only be executed or none
   executed.  Thus if used to "refresh" a
   lock.  Meaning, at minimum, that any error occurs during processing all executed
   instructions timers associated with the lock
   MUST be undone and re-set.

   A server may return a proper Timeout header with a lock refresh that is
   different than the Timeout header returned when the lock was
   originally requested.  Additionally clients may submit Timeout
   headers of arbitrary value with their lock refresh requests.
   Servers, as always, may ignore Timeout headers submitted by the
   client.  Note that timeout is measured in seconds remaining until
   expiration.

   If an error result returned.
   Instruction processing details can be found is received in response to a refresh LOCK request the definition
   client MUST NOT assume that the lock was refreshed.

8.  HTTP Methods for Distributed Authoring

8.1  General request and response handling

8.1.1  Use of XML

   Some of the
   set following new HTTP methods use XML as a request and remove instructions in sections 13.23
   response format.  All DAV compliant clients and section 13.24.

8.3.1  Status Codes for resources MUST use with 207 (Multi-Status)

   The following
   XML parsers that are examples of response codes one would expect to be compliant with XML [11] and XML Namespaces [10].
   All XML used in either requests or responses MUST be, at minimum,
   well formed and use namespaces correctly.  If a 207 (Multi-Status) response for this method.  Note,
   however, that unless explicitly prohibited any 2/3/4/5xx series
   response code may be used server receives non-
   wellformed XML in a 207 (Multi-Status) response.

   200 (OK) - The command succeeded.  As there can be request it MUST reject the entire request with a mixture
   400 (Bad Request).  If a client receives ill-formed XML in a response
   then it MUST NOT assume anything about the outcome of sets the executed
   method and removes SHOULD treat the server as malfunctioning.

8.1.2  Required Bodies in Requests

   Some of these new methods do not define bodies.  Servers MUST examine
   all requests for a body, even when a 201 (Created) seems inappropriate.

   403 (Forbidden) - The client, for reasons body was not expected.  In cases
   where a request body is present but would be ignored by a server, the
   server MUST reject the server chooses not to
   specify, cannot alter one of request with 415 (Unsupported Media Type).
   This informs the properties.

   403 (Forbidden): The client has attempted (which may have been attempting to set a read- only
   property, such use an
   extension) that the body could not be processed as getetag.  If returning this error, they intended.

8.1.3  Use of Location header in responses

   When the Location header is used in a response, it is used by the
   server
   SHOULD use 'read-only-property' inside to indicate the response body.

   409 (Conflict) - The client has provided a value whose semantics are
   not appropriate preferred address for the property.

   423 (Locked) - The specified target resource is locked and of
   the client either
   is not a lock owner or request.  Whenever the lock type requires server has a lock token to be
   submitted and the client did not submit it. preferred address, it should
   use that address consistently.  This means that when a response SHOULD
   contain
   contains a Location header, all the 'missing-lock-token' precondition element.

   507 (Insufficient Storage) - The server did not have sufficient space
   to record URLs in the property.

8.3.2  Example - PROPPATCH

      >>Request

        PROPPATCH /bar.html HTTP/1.1
        Host: www.example.com
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propertyupdate xmlns:D="DAV:"
        xmlns:Z="http://www.w3.com/standards/z39.50/">
         <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>
      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:"
        xmlns:Z="http://www.w3.com/standards/z39.50">
         <D:response>
           <D:href>http://www.example.com/bar.html</D:href>
           <D:propstat>
             <D:prop><Z:Authors/></D:prop>
             <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
           <D:propstat>
             <D:prop><Z:Copyright-Owner/></D:prop>
             <D:status>HTTP/1.1 409 Conflict</D:status>
           </D:propstat>
           <D:responsedescription> Copyright Owner can not be deleted or
        altered.</D:responsedescription>
         </D:response>
        </D:multistatus>

   In this example, response body (e.g. a
   Multi-Status) should be consistent (most importantly, should use the client requests
   same host and port).

8.1.4  Required Response Headers: Date

   Note that HTTP 1.1 requires the server to set Date header in all responses if
   possible.

8.1.5  ETag

   HTTP 1.1 recommends the value use of the "Authors" property ETag header in the "http://www.w3.com/standards/z39.50/"
   namespace, responses to GET
   and PUT requests.  Correct use of ETags is even more important in a
   distributed authoring environment, because ETags are necessary along
   with locks to remove avoid the property "Copyright-Owner" lost-update problem.  A client might fail to
   renew a lock, for example when the lock times out and the client is
   accidentally offline or in the
   "http://www.w3.com/standards/z39.50/" namespace.  Since middle of a long upload.  When a
   client fails to renew the
   Copyright-Owner property could not lock, it's quite possible the resource can
   still be removed, no property
   modifications occur.  The 424 (Failed Dependency) status code for relocked and the
   Authors property indicates this action would have succeeded if it user can go on editing, as long as no
   changes were not made in the meantime.  ETags are required for the conflict with removing client
   to be able to distinguish this case.  Otherwise, the Copyright-Owner property.

8.4  MKCOL Method

   The MKCOL method client is used forced
   to create a new collection.  All ask the user whether to overwrite the resource on the server
   without even being able to tell the user whether it has changed.
   Timestamps do not solve this problem nearly as well as ETags.

   WebDAV
   compliant resources MUST servers SHOULD support the MKCOL method.

   MKCOL creates strong ETags for all resources that may
   be PUT.  If ETags are supported for a new collection resource at resource, the location specified by server MUST
   return the Request-URI.  If ETag header in all PUT and GET responses to that resource,
   as well as provide the resource identified by same value for the Request-URI is
   non-null then 'getetag' property.

   Because clients may be forced to prompt users or throw away changed
   content if the MKCOL MUST fail.  During MKCOL processing, ETag changes, a WebDAV server MUST make not change the Request-URI ETag
   (or getlastmodified value) for a member resource that has an unchanged body.
   The ETag represents the state of its parent collection, unless the Request-URI body or contents of the
   resource.  There is "/".  If no such ancestor exists, the method MUST
   fail.  When similar way to tell if properties have
   changed.

8.1.6  Including error response bodies

   HTTP and WebDAV did not use the MKCOL operation creates bodies of most error responses for
   machine-parsable information until DeltaV introduced a new collection resource,
   all ancestors MUST already exist, or mechanism to
   include more specific information in the method MUST fail body of an error response
   (section 1.6 of RFC3253 [14]).  The mechanism is appropriate to use
   with any error response that may take a 409
   (Conflict) status code.  For example, if a request to create
   collection /a/b/c/d/ is made, and /a/b/c/ body but does not exist, the request
   must fail.

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

   A MKCOL request message may contain a message body. body defined.  The behavior mechanism is particularly appropriate when
   a status code can mean many things (for example, 400 Bad Request can
   mean required headers are missing, headers are incorrectly formatted,
   or much more).

   This mechanism does not take the place of using a MKCOL request when correct numeric
   error code as defined here or in HTTP, because the body is present is limited client MUST always
   be able to creating
   collections, members of take a collection, bodies reasonable course of members and
   properties action based only on the collections or members.  If the server receives a
   MKCOL request entity type
   numeric error.  However, it does not support or understand it MUST
   respond with a 415 (Unsupported Media Type) status code.  If remove the
   server decides need to reject the request based on the presence of an
   entity or the type of an entity, it should use define new
   numeric error codes, avoiding the 415 (Unsupported
   Media Type) status code.  The exact behavior confusion of MKCOL for various
   request media types who is undefined allowed to
   define such new codes.  The codes used in this document, and will be
   specified mechanism are XML
   elements in separate documents.

8.4.1  MKCOL Status Codes

   Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
   idempotent semantics.

   201 (Created) - The collection was created.

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

   405 (Method Not Allowed) - MKCOL so naturally any group defining a new error
   code can only be executed on an unmapped
   URL.

   409 (Conflict) - use their own namespace.  As always, the "DAV:" namespace is
   reserved for use by IETF-chartered WebDAV working groups.

   A collection cannot be made at the Request-URI until
   one or more intermediate collections have been created.  The server
   MUST NOT create those intermediate collections automatically.

   415 (Unsupported Media Type) - supporting "bis" SHOULD include a specific XML error code in
   a "DAV:error" response body element, when a specific XML error code
   is defined in this document.  The server does DAV:error element may contain
   multiple elements describing specific errors.  For error conditions
   not support specified in this document, the
   request type of server MAY simply choose an
   appropriate numeric status and leave the body.

   507 (Insufficient Storage) - The resource does not have sufficient
   space to record response body blank.

        HTTP/1.1 403 Forbidden
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:error xmlns:D="DAV:">
          <D:forbid-external-entities/>
        </D:error>

   In this specification, both the state of numeric and the resource after XML error code are
   defined for some failure situations, in which case the execution of this
   method.

8.4.2  Example - MKCOL

   This example creates XML error code
   must have the "DAV:" namespace, appear in the "error" root element,
   and be returned in a collection called /webdisc/xfiles/ on body with the
   server www.example.com.

      >>Request

        MKCOL /webdisc/xfiles/ HTTP/1.1
        Host: www.example.com

      >>Response

        HTTP/1.1 201 Created

8.5  GET, HEAD for Collections numeric error code specified.

8.2  PROPFIND

   The semantics of GET are unchanged when applied to a collection,
   since GET is PROPFIND method retrieves properties defined as, "retrieve whatever information (in on the form
   of an entity) is resource
   identified by the Request-URI" [RFC2616].  GET when
   applied to a collection may return Request-URI, if the contents of an "index.html"
   resource, a human-readable view of resource does not have any
   internal members, or on the contents of resource identified by the collection, or
   something else altogether.  Hence it Request-URI
   and potentially its member resources, if the resource is possible a collection
   that has internal member URLs.  All DAV compliant resources MUST
   support the result PROPFIND method and the propfind XML element
   (Section 13.25) along with all XML elements defined for use with that
   element.

   A client may submit a Depth header with a value of "0", "1", or
   "infinity" with a
   GET PROPFIND on a collection will bear no correlation to the membership of resource.  Servers MUST
   support the
   collection.

   Similarly, since "0", "1" and "infinity" behaviors on WebDAV-compliant
   resources.  By default, the definition of HEAD is a GET PROPFIND method without a response
   message body, Depth header
   MUST act as if a "Depth: infinity" header was included.

   A client may submit a propfind XML element in the semantics body of HEAD are unmodified when applied to
   collection resources.

8.6  POST for Collections

   Since by definition the actual function performed by POST request
   method describing what information is
   determined being requested.  It is
   possible to:

   o  Request particular property values, by naming the server and often depends on the particular
   resource, properties
      desired within the behavior 'prop' element (the ordering of POST when applied to collections cannot properties in
      here MAY be
   meaningfully modified because it is largely undefined.  Thus the
   semantics of POST are unmodified when applied to a collection.

8.7  DELETE

8.7.1  DELETE ignored by server)

   o  Request all dead property values, by using 'dead-props' element.
      This can be combined with retrieving specific live properties
      named as above.  Servers advertising support for RFC2518bis MUST
      support this feature.

   o  Request property values for Non-Collection Resources

   When a client issues a DELETE request to a Request-URI mapping to those properties defined in this
      specification plus dead properties, by using 'allprop' element
   o  Request a
   non-collection resource, if list of names of all the operation is successful properties defined on the server
   MUST remove that mapping.  Thus, after a successful DELETE operation
   (and in
      resource, by using the absence of other actions) a subsequent GET/HEAD/PROPFIND
   request 'propname' element.

   A client may choose not to the target Request-URI MUST return 404 (Not Found).

8.7.2  DELETE for Collections

   The DELETE method on submit a collection request body.  An empty PROPFIND
   request body MUST act be treated as if a "Depth: infinity"
   header was used on it. it were an 'allprop' request.

   Note that 'allprop' does not return values for all live properties.
   WebDAV servers increasingly have expensively-calculated or lengthy
   properties (see RFC3253 [14] and RFC3744 [15]) and do not return all
   properties already.  Instead, WebDAV clients can use propname
   requests to discover what live properties exist, and request named
   properties when retrieving values.  A client WebDAV server MAY omit certain
   live properties from other specifications when responding to an
   allprop request from an older client, and MAY return only custom
   (dead) properties and those defined in this specification.

   All servers MUST NOT submit a Depth header with support returning a DELETE on response of content type text/
   xml or application/xml that contains a collection with any value but infinity.

   DELETE instructs multistatus XML element that
   describes the collection specified results of the attempts to retrieve the various
   properties.  The multistatus contains one response element for each
   resource in the Request-URI and
   all resources identified by its internal member URLs are to scope of the request (in no required order) or may be
   deleted.
   empty if no resources match the request.

   If any resource identified by there is an error retrieving a member URL cannot be deleted property then all
   of the member's ancestors a proper error result
   MUST NOT be deleted, so as to maintain
   namespace consistency.

   Any headers included with DELETE MUST be applied in processing every
   resource the response.  A request to be deleted.

   When retrieve the DELETE method has completed processing it MUST result in value of
   a
   consistent namespace.

   If property which does not exist is an error occurs deleting an internal resource (a resource other
   than the resource identified in the Request-URI) then and MUST be noted, if the
   response
   can be uses a 207 (Multi-Status).  Multi-Status is used here to indicate
   which internal resources could NOT be deleted, including an error
   code which should help the client understand which resources caused
   the failure.  For example, the Multi-Status body could include multistatus XML element, with a response with status 423 (Locked) if an internal resource was locked.

   The server MAY return XML element
   which contains a 4xx 404 (Not Found) status response, rather than a Multi-
   Status, if the entire DELETE request failed and it canȔt identify
   the internal resources that caused the DELETE to fail.

   424 (Failed Dependency) errors SHOULD NOT be in value.

   Consequently, the 207 (Multi-
   Status).  They can be safely left out because multistatus XML element for a collection resource
   with member URLs MUST include a response XML element for each member
   URL of the client will know collection, to whatever depth was requested.  Each
   response XML element MUST contain an href XML element that gives the ancestors
   URL of a the resource could not be deleted when on which the client
   receives an error for properties in the ancestor's progeny.  Additionally 204 (No
   Content) errors SHOULD NOT be returned prop XML element
   are defined.  URLs for collections appearing in the 207 (Multi- Status).
   The reason results MUST end
   in a slash character.  Results for this prohibition is that 204 (No Content) a PROPFIND on a collection
   resource with internal member URLs are returned as a flat list whose
   order of entries is not significant.

   A server enumerating the
   default success code.

8.7.3  Example - DELETE

      >>Request

        DELETE  /container/ HTTP/1.1
        Host: www.example.com

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <d:multistatus xmlns:d="DAV:">
         <d:response>
           <d:href>http://www.example.com/container/resource3</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus>

   In this example the attempt to delete http://www.example.com/
   container/resource3 failed because it is locked, members of a collection using absolute URLs
   in a PROPFIND response MUST use a common prefix in those URLs, and no lock token
   was submitted with
   that prefix MUST be the request.  Consequently, absolute URL used in the attempt response to delete
   http://www.example.com/container/ also failed.  Thus the client knows
   that the attempt refer to delete http://www.example.com/container/ must
   have also failed since
   the parent can not be deleted unless its child
   has also been deleted.  Even though a Depth header has not been
   included, a depth of infinity is assumed because the method is on a collection.

8.8  PUT

8.8.1  PUT for Non-Collection Resources

   A PUT performed on an existing resource replaces

   Unless otherwise notified, clients may expect that the GET response
   entity of URL for the resource.  Properties defined on
   parent collection in the resource may PROPFIND response will be
   recomputed during PUT processing but are not otherwise affected.  For
   example, if the same URL that
   was used to refer to the parent collection in the PROPFIND request.
   Servers MAY use an alternate URL for the parent collection in a
   PROPFIND response, but in this case the server recognizes MUST include a
   Content-Location header whose value is the content type of fully-qualified URL used
   by the request body,
   it may be able server to automatically extract information that could refer to the parent collection in this response.

   URLs in a PROPFIND response body MAY be
   profitably exposed represented as properties.

   A PUT that would result fully-
   qualified URLs, in which case they must all contain the creation of a resource without an
   appropriately scoped full parent
   collection MUST fail with a 409
   (Conflict).

8.8.2  PUT for Collections

   As defined URL (scheme, host, port, and absolute path).
   Alternatively, these URLs MAY be absolute paths (not containing
   scheme, host or port), but in RFC2616 [8], this case they must all still contain
   the "PUT method requests full parent collection path.

   If a server allows resource names to include characters that arenit
   legal in HTTP URL paths, these characters must be URI-escaped on the enclosed
   entity
   wire.  For example, it is illegal to use a space character or double-
   quote in a URI [5].  URIs appearing in PROPFIND or PROPPATCH XML
   bodies (or other XML marshalling defined in this specification) are
   still subject to all URI rules, including forbidden characters.

   Properties may be stored under subject to access control.  In the supplied Request-URI."  Since submission case of an entity representing a collection would implicitly encode
   creation allprop
   and deletion of resources, this specification intentionally propname, if a principal does not define a transmission format for creating a collection using
   PUT.  Instead, have the MKCOL method is defined right to create collections.

8.9  COPY

   The COPY method creates know whether
   a duplicate of the source resource,
   identified by the Request-URI, in the destination resource,
   identified by the URI in particular property exists then the Destination header.  The Destination
   header MUST property MAY be present. silently
   excluded from the response.

   The exact behavior results of the COPY this method
   depends on the SHOULD NOT be cached.

8.2.1  Example - Retrieving Named Properties

    >>Request

      PROPFIND  /file HTTP/1.1
      Host: www.example.com
      Content-type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:propfind xmlns:D="DAV:">
       <D:prop xmlns:R="http://www.example.com/boxschema/">
         <R:bigbox/>
         <R:author/>
         <R:DingALing/>
         <R:Random/>
       </D:prop>
      </D:propfind>

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:multistatus xmlns:D="DAV:">
       <D:response xmlns:R="http://www.example.com/boxschema/">
         <D:href>http://www.example.com/file</D:href>
         <D:propstat>
           <D:prop>
             <R:bigbox>
               <R:BoxType>Box type of the source resource.

   All WebDAV compliant resources MUST support the COPY method.
   However, support for the COPY method A</R:BoxType>
             </R:bigbox>
             <R:author>
               <R:Name>J.J. Johnson</R:Name>
             </R:author>
           </D:prop>
           <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
         <D:propstat>
           <D:prop><R:DingALing/><R:Random/></D:prop>
           <D:status>HTTP/1.1 403 Forbidden</D:status>
           <D:responsedescription> The user does not guarantee the ability
   to copy a resource.  For example, separate programs may control
   resources on the same server.  As a result, it may not be possible to
   copy a resource to a location that appears have access to be on the same server.

8.9.1  COPY for Non-collection Resources

   When the source resource
      DingALing property.
           </D:responsedescription>
         </D:propstat>
       </D:response>
       <D:responsedescription> There has been an access violation error.
       </D:responsedescription>
      </D:multistatus>

   In this example, PROPFIND is not executed on a collection non-collection resource
   http://www.example.com/file.  The propfind XML element specifies the result
   name of four properties whose values are being requested.  In this
   case only two properties were returned, since the COPY
   method is principal issuing
   the creation of a new resource at request did not have sufficient access rights to see the destination whose
   state third
   and behavior match that of the source fourth properties.

8.2.2  Example - Retrieving Named and Dead Properties

      >>Request

        PROPFIND /mycol/ HTTP/1.1
        Host: www.example.com
        Depth: 1
        Content-type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:">
         <D:prop>
           <D:creationdate/>
           <D:getlastmodified/>
         </D:prop>
         <D:dead-props/>
        </D:propfind>

   In this example, PROPFIND is executed on a collection resource as closely as
   possible.  Since the environment at the destination may be different
   than at
   http://www.example.com/mycol/.  The client requests the source due values of two
   specific live properties plus all dead properties (names and values).
   The response is not shown.

8.2.3  Example - Using propname to factors outside Retrieve all Property Names

      >>Request
        PROPFIND  /container/ HTTP/1.1
        Host: www.example.com
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <multistatus xmlns="DAV:">
         <response>
           <href>http://www.example.com/container/</href>
           <propstat>
             <prop xmlns:R="http://www.example.com/boxschema/">
               <R:bigbox/>
               <R:author/>
               <creationdate/>
               <displayname/>
               <resourcetype/>
               <supportedlock/>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
         </response>
         <response>
           <href>http://www.example.com/container/front.html</href>
           <propstat>
             <prop xmlns:R="http://www.example.com/boxschema/">
               <R:bigbox/>
               <creationdate/>
               <displayname/>
               <getcontentlength/>
               <getcontenttype/>
               <getetag/>
               <getlastmodified/>
               <resourcetype/>
               <supportedlock/>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
         </response>
        </multistatus>

   In this example, PROPFIND is invoked on the scope of control of collection resource
   http://www.example.com/container/, with a propfind XML element
   containing the
   server, such as propname XML element, meaning the absence name of resources required for correct
   operation, it may not all
   properties should be possible to completely duplicate returned.  Since no Depth header is present, it
   assumes its default value of "infinity", meaning the
   behavior name of the resource at
   properties on the destination.  Subsequent alterations
   to collection and all its descendents should be
   returned.

   Consistent with the destination previous example, resource will not modify
   http://www.example.com/container/ has six properties defined on it:
   bigbox and author in the source resource.
   Subsequent alterations to "http://www.example.com/boxschema/"
   namespace, and creationdate, displayname, resourcetype, and
   supportedlock in the source "DAV:" namespace.

   The resource will not modify the
   destination resource.

8.9.2  COPY for Properties

   After http://www.example.com/container/index.html, a successful COPY invocation, all dead properties on member of
   the source
   resource MUST be duplicated "container" collection, has nine properties defined on it, bigbox
   in the destination resource, along with
   all properties as appropriate.  Live properties described "http://www.example.com/boxschema/" namespace and,
   creationdate, displayname, getcontentlength, getcontenttype, getetag,
   getlastmodified, resourcetype, and supportedlock in this
   document SHOULD be duplicated as identically behaving live properties
   at the destination resource, but not necessarily with "DAV:"
   namespace.

   This example also demonstrates the same
   values.  If a property cannot be copied live, then its value MUST be
   duplicated, octet-for-octet, in an identically named, dead property
   on use of XML namespace scoping and
   the destination resource.

   A COPY operation creates default namespace.  Since the "xmlns" attribute does not contain
   a new resource, much like prefix, the namespace applies by default to all enclosed elements.
   Hence, all elements which do not explicitly state the namespace to
   which they belong are members of the "DAV:" namespace schema.

8.2.4  PROPFIND Request Errors

   PROPFIND requests may also fail entirely, before the server even gets
   a PUT operation
   does.  Live properties which are related chance to resource creation (such
   as creationdate) should have their values set accordingly.

8.9.3  COPY for Collections

   The COPY method on a collection without a Depth header MUST act evaluate individual properties. 404 (Not Found) and 401
   (Unauthorized) are possible as if
   a Depth header with value "infinity" was included. every request.  These are some
   other notable errors.

   403 Forbidden  - A client may
   submit a Depth header on a COPY server MAY reject all PROPFIND requests on a collection
   collections with a value of "0"
   or "infinity".  Servers MUST support the "0" and "infinity" Depth depth header behaviors on WebDAV-compliant resources.

   A COPY of depth infinity instructs that "Infinity", in which case it SHOULD
   use this error with the collection resource
   identified by element 'propfind-infinite-depth-forbidden'
   inside the Request-URI is to be copied body.

8.3  PROPPATCH

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

   All DAV compliant resources MUST support the Destination header, PROPPATCH method and all its internal
   member resources
   MUST process instructions that are to be copied to a location relative to it,
   recursively through all levels of specified using the collection hierarchy.

   A COPY
   propertyupdate, set, and remove XML elements.  Execution of "Depth: 0" only instructs that the collection and its
   properties but not
   directives in this method is, of course, subject to access control
   constraints.  DAV compliant resources identified by its internal member URLs,
   are SHOULD support the setting of
   arbitrary dead properties.

   The request message body of a PROPPATCH method MUST contain the
   propertyupdate XML element.  Instruction processing MUST occur in
   document order (an exception to the normal rule that ordering is
   irrelevant).  Instructions MUST either all be copied.

   Any headers included with a COPY executed or none
   executed.  Thus if any error occurs during processing all executed
   instructions MUST be applied in undone and a proper error result returned.
   Instruction processing every
   resource to details can be copied with found in the exception definition of the Destination header.

   The Destination header only specifies the destination URI
   set and remove instructions in sections 13.23 and section 13.24.

8.3.1  Status Codes for the
   Request-URI.  When applied to members of the collection identified by
   the Request-URI the value use with 207 (Multi-Status)

   The following are examples of Destination is response codes one would expect to be modified to reflect
   the current location
   used in the hierarchy.  So, if the Request-URI is /a/
   with Host header value http://example.com/ and the Destination is
   http://example.com/b/ then when http://example.com/a/c/d is processed
   it must use a Destination of http://example.com/b/c/d.

   When the COPY method has completed processing it MUST have created 207 (Multi-Status) response for this method.  Note,
   however, that unless explicitly prohibited any 2/3/4/5xx series
   response code may be used in a
   consistent namespace at the destination (see Section 8.7.2for the
   definition 207 (Multi-Status) response.

   200 (OK) - The command succeeded.  As there can be a mixture of namespace consistency).  However, if an error occurs
   while copying an internal collection, sets
   and removes in a body, a 201 (Created) seems inappropriate.

   403 (Forbidden) - The client, for reasons the server MUST NOT copy any
   resources identified by members chooses not to
   specify, cannot alter one of this collection (i.e., the server
   must skip this subtree), properties.

   403 (Forbidden): The client has attempted to set a read- only
   property, such as getetag.  If returning this would create an inconsistent
   namespace.  After detecting an error, the COPY operation server
   SHOULD try
   to finish as much of the original copy operation as possible (i.e., use 'read-only-property' inside the server should still attempt to copy other subtrees and their
   members, that response body.

   409 (Conflict) - The client has provided a value whose semantics are
   not descendents of an error-causing collection).

   So, appropriate for example, if an infinite depth copy operation the property.

   423 (Locked) - The specified resource is performed on
   collection /a/, which contains collections /a/b/ and /a/c/, locked and an
   error occurs copying /a/b/, an attempt should still the client either
   is not a lock owner or the lock type requires a lock token to be made
   submitted and the client did not submit it.  This response SHOULD
   contain the 'missing-lock-token' precondition element.

   507 (Insufficient Storage) - The server did not have sufficient space
   to copy /
   a/c/.  Similarly, after encountering an error copying a non-
   collection resource as part of an infinite depth copy, record the property.

8.3.2  Example - PROPPATCH

      >>Request

        PROPPATCH /bar.html HTTP/1.1
        Host: www.example.com
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propertyupdate xmlns:D="DAV:"
        xmlns:Z="http://www.w3.com/standards/z39.50/">
         <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>

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:"
        xmlns:Z="http://www.w3.com/standards/z39.50">
         <D:response>
           <D:href>http://www.example.com/bar.html</D:href>
           <D:propstat>
             <D:prop><Z:Authors/></D:prop>
             <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
           <D:propstat>
             <D:prop><Z:Copyright-Owner/></D:prop>
             <D:status>HTTP/1.1 409 Conflict</D:status>
           </D:propstat>
           <D:responsedescription> Copyright Owner can not be deleted or
        altered.</D:responsedescription>
         </D:response>
        </D:multistatus>
   In this example, the client requests the server
   SHOULD try to finish as much set the value of
   the original copy operation as
   possible.

   If an error "Authors" property in executing the COPY method occurs with a resource other
   than "http://www.w3.com/standards/z39.50/"
   namespace, and to remove the resource identified property "Copyright-Owner" in the Request-URI then
   "http://www.w3.com/standards/z39.50/" namespace.  Since the response
   MUST
   Copyright-Owner property could not be a 207 (Multi-Status), and the URL of the resource causing the
   failure MUST appear with the specific error. removed, no property
   modifications occur.  The 424 (Failed Dependency) status code SHOULD NOT be returned in for the
   207 (Multi-Status) response from
   Authors property indicates this action would have succeeded if it
   were not for the conflict with removing the Copyright-Owner property.

8.4  MKCOL Method

   The MKCOL method is used to create a COPY new collection.  All WebDAV
   compliant resources MUST support the MKCOL method.  These responses can
   be safely omitted because

   MKCOL creates a new collection resource at the client will know that location specified by
   the Request-URI.  If the progeny of a resource could not be copied when identified by the client receives an error for Request-URI is
   non-null then the parent.  Additionally 201 (Created)/204 (No Content) status codes
   SHOULD NOT be returned as values in 207 (Multi-Status) responses from
   COPY methods.  They, too, can be safely omitted because they are MKCOL MUST fail.  During MKCOL processing, a server
   MUST make the Request-URI a member of its parent collection, unless
   the Request-URI is "/".  If no such ancestor exists, the method MUST
   fail.  When the MKCOL operation creates a new collection resource,
   all ancestors MUST already exist, or the
   default success codes.

8.9.4  COPY method MUST fail with a 409
   (Conflict) status code.  For example, if a request to create
   collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the Overwrite Header

   If request
   must fail.

   When MKCOL is invoked without a resource exists at request body, the destination and newly created
   collection SHOULD have no members.

   A MKCOL request message may contain a message body.  The precise
   behavior of a MKCOL request when the Overwrite header body is
   "T" then prior present is undefined,
   but limited to performing creating collections, members of a collection, bodies
   of members and properties on the copy collections or members.  If the
   server MUST perform receives a
   DELETE MKCOL request entity type it does not support or
   understand it MUST respond with "Depth: infinity" on the destination resource. a 415 (Unsupported Media Type) status
   code.  If the
   Overwrite header is set server decides to "F" then reject the operation will fail.

8.9.5 request based on the
   presence of an entity or the type of an entity, it should use the 415
   (Unsupported Media Type) status code.

8.4.1  MKCOL Status Codes

   Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
   idempotent semantics.

   201 (Created) - The source resource was successfully copied.  The
   copy operation resulted in the creation of a new resource.

   204 (No Content) - The source resource collection was successfully copied to a
   pre-existing destination resource.

   207 (Multi-Status) created.

   403 (Forbidden) - Multiple resources were to be affected by the
   COPY, but errors on some This indicates at least one of them prevented two conditions: 1)
   the operation from taking
   place.  Specific error messages, together with server does not allow the most appropriate creation of collections at the source and destination URLs, appear given
   location in its namespace, or 2) the body parent collection of the multi-
   status response.  E.g.  if a destination resource was locked and
   could not be overwritten, then the destination resource URL appears
   with the 423 (Locked) status.

   403 (Forbidden)
   Request-URI exists but cannot accept members.

   405 (Method Not Allowed) - The operation is forbidden.  Possibly this is
   because the source and destination resources are the same resource. MKCOL can only be executed on an unmapped
   URL.

   409 (Conflict) - A resource collection cannot be created made at the destination Request-URI until
   one or more intermediate collections have been created.  The server
   MUST NOT create those intermediate collections automatically.

   412 (Precondition Failed) - A precondition failed, e.g.  the
   Overwrite header is "F" and the state of the destination resource is
   non-null.

   423 (Locked) - The destination resource, or resource within the
   destination collection, was locked.  This response SHOULD contain the
   'missing-lock-token' precondition element.

   502 (Bad Gateway) - This may occur when the destination is on another
   server, repository or namespace.  Either the source namespace does
   not support copying to the destination namespace, or the destination
   namespace refuses to accept the resource.  The client may wish to try
   GET/PUT and PROPFIND/PROPPATCH instead.

   507 (Insufficient Storage) - The destination resource does not have
   sufficient space to record the state of the resource after the
   execution of this method.

8.9.6  COPY Examples

   This example shows resource http://www.ics.uci.edu/~fielding/
   index.html being copied to the location http://www.ics.uci.edu/users/
   f/fielding/index.html.  The 204 (No Content) status code indicates
   the existing resource at the destination was overwritten.

   COPY with Overwrite

      >>Request

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

      >>Response

        HTTP/1.1 204 No Content NOT create those intermediate collections automatically.

   415 (Unsupported Media Type) - The following example shows server does not support the same copy operation being performed,
   but with
   request type of the Overwrite header set body.

   507 (Insufficient Storage) - The resource does not have sufficient
   space to "F."  A response record the state of 412
   (Precondition Failed) is returned because the destination resource
   has a non-null state.

   COPY with No Overwrite

      >>Request

        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

      >>Response

        HTTP/1.1 412 Precondition Failed after the execution of this
   method.

8.4.2  Example - COPY of MKCOL

   This example creates a Collection collection called /webdisc/xfiles/ on the
   server www.example.com.

      >>Request

        COPY /container/

        MKCOL /webdisc/xfiles/ HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/othercontainer/
        Depth: infinity

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>

        <d:multistatus xmlns:d="DAV:">
         <d:response>
           <d:href>http://www.example.com/othercontainer/R2/</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus> 201 Created

8.5  GET, HEAD for Collections

   The Depth header semantics of GET are unchanged when applied to a collection,
   since GET is unnecessary as defined as, "retrieve whatever information (in the default behavior form
   of COPY on a
   collection an entity) is identified by the Request-URI" [RFC2616].  GET when
   applied to act as if a "Depth: infinity" header had been
   submitted.  In this example most of the resources, along with the
   collection, were copied successfully.  However the collection R2
   failed because may return the destination R2 is locked.  Because there was contents of an
   error copying R2, none "index.html"
   resource, a human-readable view of R2's members were copied.  However no
   errors were listed for those members due to the error minimization
   rules.

8.10  MOVE

   The MOVE operation on a non-collection resource contents of the collection, or
   something else altogether.  Hence it is possible that the logical
   equivalent result of a copy (COPY), followed by consistency maintenance
   processing, followed by
   GET on a delete collection will bear no correlation to the membership of the source, where all three
   actions are performed atomically.  The consistency maintenance step
   allows
   collection.

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

8.6  POST for Collections

   Since by definition the move, such as
   updating all URLs other than actual function performed by POST is
   determined by the Request-URI which identify server and often depends on the
   source particular
   resource, to point to the new destination resource.
   Consequently, the Destination header MUST behavior of POST when applied to collections cannot be present
   meaningfully modified because it is largely undefined.  Thus the
   semantics of POST are unmodified when applied to a collection.

8.7  DELETE

   Locks rooted on all MOVE
   methods and a resource MUST follow all COPY requirements be destroyed in a successful DELETE
   of that resource.

8.7.1  DELETE for Non-Collection Resources

   When a client issues a DELETE request to a Request-URI mapping to a
   non-collection resource, if the COPY part of operation is successful the MOVE method.  All WebDAV compliant resources server
   MUST support remove that mapping.  Thus, after a successful DELETE operation
   (and in the
   MOVE method.  However, support absence of other actions) a subsequent GET/HEAD/PROPFIND
   request to the target Request-URI MUST return 404 (Not Found).

8.7.2  DELETE for Collections

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

   DELETE instructs that the MOVE method does not guarantee collection specified in the ability Request-URI and
   all resources identified by its internal member URLs are to move a be
   deleted.

   If any resource to identified by a particular destination.

   For example, separate programs may actually control different sets member URL cannot be deleted then all
   of
   resources on the same server.  Therefore, it may not member's ancestors MUST NOT be possible deleted, so as to
   move a resource within a maintain
   namespace that appears to belong consistency.

   Any headers included with DELETE MUST be applied in processing every
   resource to be deleted.

   When the same
   server.

   If DELETE method has completed processing it MUST result in a
   consistent namespace.

   If an error occurs deleting an internal resource exists at the destination, (a resource other
   than the destination resource
   will identified in the Request-URI) then the response
   can be deleted as a side-effect of the MOVE operation, subject 207 (Multi-Status).  Multi-Status is used here to
   the restrictions of the Overwrite header.

8.10.1  MOVE for Properties

   Live properties described in this document MUST indicate
   which internal resources could NOT be moved along with deleted, including an error
   code which should help the resource, such that client understand which resources caused
   the resource has identically behaving live
   properties at failure.  For example, the destination resource, but not necessarily Multi-Status body could include a
   response with status 423 (Locked) if an internal resource was locked.

   The server MAY return a 4xx status response, rather than a Multi-
   Status, if the
   same values.  If request failed.

   424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-
   Status).  They can be safely left out because the live properties client will know
   that the ancestors of a resource could not work be deleted when the same way at client
   receives an error for the destination, ancestor's progeny.  Additionally 204 (No
   Content) errors SHOULD NOT be returned in the server MUST fail 207 (Multi- Status).
   The reason for this prohibition is that 204 (No Content) is the request (the client can
   perform COPY then
   default success code.

8.7.3  Example - DELETE if it wants a MOVE

      >>Request

        DELETE  /container/ HTTP/1.1
        Host: www.example.com

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <d:multistatus xmlns:d="DAV:">
         <d:response>
           <d:href>http://www.example.com/container/resource3</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus>

   In this example the attempt to work that badly).
   This can mean that delete
   http://www.example.com/container/resource3 failed because it is
   locked, and no lock token was submitted with the server reports request.
   Consequently, the live property as "Not
   Found" if that's attempt to delete http://www.example.com/container/
   also failed.  Thus the most appropriate behavior for client knows that live property
   at the destination, as long as attempt to delete
   http://www.example.com/container/ must have also failed since the live property
   parent can not be deleted unless its child has also been deleted.
   Even though a Depth header has not been included, a depth of infinity
   is still supported
   with assumed because the same semantics.

   MOVE method is frequently used by clients to rename on a file without changing
   its parent collection, so it's not appropriate to reset live
   properties which are set at collection.

8.8  PUT

8.8.1  PUT for Non-Collection Resources

   A PUT performed on an existing resource replaces the GET response
   entity of the resource.  Properties defined on the resource creation. may be
   recomputed during PUT processing but are not otherwise affected.  For
   example, the
   creationdate property value SHOULD remain the same after if a MOVE.

   Dead properties must be moved along with the resource.

8.10.2  MOVE for Collections

   A MOVE with "Depth: infinity" instructs that server recognizes the collection
   identified by content type of the Request-URI request body,
   it may be moved able to the address specified automatically extract information that could be
   profitably exposed as properties.

   A PUT that would result in the Destination header, and all resources identified by its internal
   member URLs are to be moved to locations relative to it, recursively
   through all levels creation of the collection hierarchy.

   The MOVE method on a resource without an
   appropriately scoped parent collection MUST act as if fail with a "Depth: infinity"
   header was used on it.  A client MUST NOT submit 409
   (Conflict).

8.8.2  PUT for Collections

   As defined in RFC2616 [7], the "PUT method requests that the enclosed
   entity be stored under the supplied Request-URI."  Since submission
   of an entity representing a Depth header on collection would implicitly encode
   creation and deletion of resources, this specification intentionally
   does not define a
   MOVE on transmission format for creating a collection with any value but "infinity".

   Any headers included with MOVE MUST be applied in processing every
   resource using
   PUT.  Instead, the MKCOL method is defined to create collections.  A
   PUT request to an existing collection MAY be moved with the exception treated as an error (405
   Method Not Allowed).

8.9  COPY

   The COPY method creates a duplicate of the source resource identified
   by the Request-URI, in the destination resource identified by the URI
   in the Destination header.  The behavior of the Destination header is MUST be present.
   The exact behavior of the same as given for COPY method depends on collections.

   When the MOVE method has completed processing it MUST have created a
   consistent namespace at both type of the
   source and destination (see section
   5.1 for the definition resource.  The state of namespace consistency).  However, if an
   error occurs while moving an internal collection, the server MUST NOT
   move any resources identified by members of resource to be copied is fixed at
   the failed collection
   (i.e., point the server must skip begins processing the error-causing subtree), as this would
   create an inconsistent namespace.  In this case, after detecting COPY request.

   All WebDAV compliant resources MUST support the
   error, COPY method.
   However, support for the move operation SHOULD try COPY method does not guarantee the ability
   to finish as much of copy a resource.  For example, separate programs may control
   resources on the
   original move as same server.  As a result, it may not be possible (i.e., the server should still attempt to
   move other subtrees and the resources identified by their members,
   copy a resource to a location that are not descendents of an error-causing collection).  So, appears to be on the same server.

8.9.1  COPY for
   example, if an infinite depth move Non-collection Resources

   When the source resource is performed on collection /a/,
   which contains collections /a/b/ and /a/c/, and an error occurs
   moving /a/b/, an attempt should still be made to try moving /a/c/.
   Similarly, after encountering an error moving not a non- collection
   resource as part the result of an infinite depth move, the server SHOULD try to
   finish as much COPY
   method is the creation of a new resource at the destination whose
   state and behavior match that of the original move operation source resource as closely as
   possible.

   If an error occurs with a resource other  Since the environment at the destination may be different
   than at the resource identified
   in source due to factors outside the Request-URI then scope of control of the response MUST
   server, such as the absence of resources required for correct
   operation, it may not be a 207 (Multi-Status),
   and possible to completely duplicate the errored resource's URL MUST appear with
   behavior of the specific error.

   The 424 (Failed Dependency) status code SHOULD NOT be returned in resource at the
   207 (Multi-Status) response from a MOVE method.  These errors can be
   safely omitted because destination.  Subsequent alterations
   to the client destination resource will know that not modify the progeny of a source resource.
   Subsequent alterations to the source resource could will not be moved when modify the client receives an error
   destination resource.

8.9.2  COPY for Properties

   After a successful COPY invocation, all dead properties on the
   parent.  Additionally 201 (Created)/204 (No Content) responses SHOULD
   NOT source
   resource MUST be returned duplicated on the destination resource, along with
   all properties as values appropriate.  Live properties described in 207 (Multi-Status) responses from a
   MOVE.  These responses can this
   document SHOULD be safely omitted because they are the
   default success codes.

8.10.3  MOVE and the Overwrite Header

   If a resource exists duplicated as identically behaving live properties
   at the destination and the Overwrite header is
   "T" then prior to performing the move resource, but not necessarily with the server MUST perform same
   values.  If a
   DELETE with "Depth: infinity" property cannot be copied live, then its value MUST be
   duplicated, octet-for-octet, in an identically named, dead property
   on the destination resource.  If the
   Overwrite header is set to "F" then the

   A COPY operation will fail.

8.10.4  Status Codes

   201 (Created) - The source resource was successfully moved, and creates a new resource, much like a PUT operation
   does.  Live properties which are related to resource was created at the destination.

   204 (No Content) - creation (such
   as creationdate) should have their values set accordingly.

8.9.3  COPY for Collections

   The source resource COPY method on a collection without a Depth header MUST act as if
   a Depth header with value "infinity" was successfully moved to included.  A client may
   submit a
   pre-existing destination resource.

   207 (Multi-Status) - Multiple resources were to be affected by Depth header on a COPY on a collection with a value of "0"
   or "infinity".  Servers MUST support the
   MOVE, but errors "0" and "infinity" Depth
   header behaviors on some WebDAV-compliant resources.

   A COPY of them prevented depth infinity instructs that the operation from taking
   place.  Specific error messages, together with collection resource
   identified by the most appropriate
   of Request-URI is to be copied to the source and destination URLs, appear location
   identified by the URI in the body Destination header, and all its internal
   member resources are to be copied to a location relative to it,
   recursively through all levels of the multi-
   status response.  E.g.  if a source resource was locked collection hierarchy.  Servers
   should of course avoid infinite recursion, and could not
   be moved, then can do so by copying
   the source resource URL appears with as it existed at the point where processing
   started.

   A COPY of "Depth: 0" only instructs that the 423 (Locked)
   status.

   403 (Forbidden) - The source collection and destination its
   properties but not resources identified by its internal member URLs,
   are the same.

   409 (Conflict) - A to be copied.

   Any headers included with a COPY MUST be applied in processing every
   resource cannot to be created at copied with the destination
   until one or more intermediate collections have been created. exception of the Destination header.

   The
   server MUST NOT create those intermediate collections automatically.
   Or, Destination header only specifies the server was unable to preserve destination URI for the behavior
   Request-URI.  When applied to members of the live
   properties and still move collection identified by
   the resource Request-URI the value of Destination is to be modified to reflect
   the destination (see
   'live-properties-not-preserved' postcondition).

   412 (Precondition Failed) Ș A condition failed, e.g. current location in the Overwrite
   header hierarchy.  So, if the Request-URI is "F" /a/
   with Host header value http://example.com/ and the state Destination is
   http://example.com/b/ then when http://example.com/a/c/d is processed
   it must use a Destination of http://example.com/b/c/d.

   When the destination resource is non-null.

   423 (Locked) - The source or COPY method has completed processing it MUST have created a
   consistent namespace at the destination resource, or some
   resource within (see Section 8.7.2for the source or destination
   definition of namespace consistency).  However, if an error occurs
   while copying an internal collection, was locked.
   This response SHOULD contain the 'missing-lock-token' precondition
   element.

   502 (Bad Gateway) - This may occur when the destination is on another server and MUST NOT copy any
   resources identified by members of this collection (i.e., the destination server refuses
   must skip this subtree), as this would create an inconsistent
   namespace.  After detecting an error, the COPY operation SHOULD try
   to accept finish as much of the resource.
   This could also occur when original copy operation as possible (i.e.,
   the destination server should still attempt to copy other subtrees and their
   members, that are not descendents of an error-causing collection).

   So, for example, if an infinite depth copy operation is performed on another sub-section
   collection /a/, which contains collections /a/b/ and /a/c/, and an
   error occurs copying /a/b/, an attempt should still be made to copy
   /a/c/.  Similarly, after encountering an error copying a non-
   collection resource as part of an infinite depth copy, the same server namespace.

8.10.5  Examples

   This example shows resource http://www.ics.uci.edu/~fielding/
   index.html being moved
   SHOULD try to the location http://www.ics.uci.edu/users/
   f/fielding/index.html.  The contents finish as much of the destination original copy operation as
   possible.

   If an error in executing the COPY method occurs with a resource
   would have been overwritten if other
   than the destination resource had been
   non-null.  In this case, since there was nothing at identified in the destination
   resource, Request-URI then the response code is 201 (Created).

   MOVE of a Non-Collection

      >>Request

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

      >>Response

        HTTP/1.1 201 Created
        Location: http://www.ics.uci.edu/users/f/fielding/index.html

   MOVE of
   MUST be a Collection

      >>Request

        MOVE /container/ HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/othercontainer/
        Overwrite: F
        If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
            (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <d:multistatus xmlns:d='DAV:'>
         <d:response>
           <d:href>http://www.example.com/othercontainer/C2/</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus>

   In this example (Multi-Status), and the client has submitted a number URL of lock tokens the resource causing the
   failure MUST appear with the request.  A lock token specific error.

   The 424 (Failed Dependency) status code SHOULD NOT be returned in the
   207 (Multi-Status) response from a COPY method.  These responses can
   be safely omitted because the client will need to know that the progeny of a
   resource could not be submitted copied when the client receives an error for every
   resource, both source and destination, anywhere
   the parent.  Additionally 201 (Created)/204 (No Content) status codes
   SHOULD NOT be returned as values in 207 (Multi-Status) responses from
   COPY methods.  They, too, can be safely omitted because they are the scope of
   default success codes.

8.9.4  COPY and the
   method, that Overwrite Header

   If a resource exists at the destination and the Overwrite header is locked.  In this case
   "T" then prior to performing the proper lock token was not
   submitted for copy the server MUST perform a
   DELETE with "Depth: infinity" on the destination http://www.example.com/othercontainer/
   C2/.  This means that resource.  If the resource /container/C2/ could
   Overwrite header is set to "F" then the operation will fail.
   (Extensions to WebDAV might not be moved.
   Because there was an error moving /container/C2/, none of /container/
   C2's members were moved.  However no errors were listed for those
   members due follow this rule to the error minimization rules.  User agent
   authentication letter but
   must consider backwards compatibility with clients that expect COPY
   to work this way.)

   Interoperability testing has previously occurred via shown that some clients expect a mechanism outside
   collection COPY to actually do a merge if a destination collection
   exists.  That behavior is appropriate for file system folders but not
   necessarily for other data objects modelled as collections.  Thus,
   implementors are urged to comply with the standard language above,
   and leave clients to perform a manual merge if that's the expected
   behavior when copying a collection over another collection.

8.9.5  Status Codes

   201 (Created) - The source resource was successfully copied.  The
   copy operation resulted in the
   scope creation of the HTTP protocol, in an underlying transport layer.

8.11  LOCK Method a new resource.

   204 (No Content) - The following sections describe the LOCK method, which is used source resource was successfully copied to
   take out a lock of any access type and
   pre-existing destination resource.

   207 (Multi-Status) - Multiple resources were to refresh an existing lock.
   These sections be affected by the
   COPY, but errors on some of them prevented the LOCK method describe only those semantics that
   are specific to operation from taking
   place.  Specific error messages, together with the LOCK method and are independent most appropriate
   of the access
   type source and destination URLs, appear in the body of the lock being requested.

   Any multi-
   status response.  E.g. if a destination resource which supports the LOCK method MUST, at minimum, support
   the XML request was locked and response formats defined herein.

   A LOCK method invocation to an unlocked resource creates a lock on could
   not be overwritten, then the destination resource identified by URL appears with
   the Request-URI, which becomes 423 (Locked) status.

   403 (Forbidden) - The operation is forbidden.  Possibly this is
   because the root of source and destination resources are the lock.  Lock method requests to create a new lock MUST same resource.

   409 (Conflict) - A resource cannot be created at the destination
   until one or more intermediate collections have a XML
   request body which contains an owner XML element and other
   information for this lock request. been created.  The
   server MUST preserve the
   information provided by NOT create those intermediate collections automatically.

   412 (Precondition Failed) - A precondition failed, e.g. the client in Overwrite
   header is "F" and the owner field when state of the lock
   information destination resource is requested. non-null.

   423 (Locked) - The LOCK request MAY have a Timeout
   header.

   Clients MUST assume that locks may arbitrarily disappear at any time,
   regardless of destination resource, or resource within the value given in
   destination collection, was locked.  This response SHOULD contain the Timeout header.  The Timeout
   header only indicates
   'missing-lock-token' precondition element.

   502 (Bad Gateway) - This may occur when the behavior of destination is on another
   server, repository or namespace.  Either the server if extraordinary
   circumstances do source namespace does
   not occur.  For example, a sufficiently privileged
   user may remove a lock at any time support copying to the destination namespace, or the system may crash in such a
   way that it loses destination
   namespace refuses to accept the resource.  The client may wish to try
   GET/PUT and PROPFIND/PROPPATCH instead.

   507 (Insufficient Storage) - The destination resource does not have
   sufficient space to record the state of the lock's existence.  The response
   MUST contain resource after the value
   execution of the lockdiscovery property in a prop XML
   element.

   A success response this method.

8.9.6  COPY Examples

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being copied to a LOCK request MUST include the Lock-Token
   response header with
   location http://www.ics.uci.edu/users/f/fielding/index.html.  The 204
   (No Content) status code indicates the token associated with existing resource at the new lock, and MUST
   contain a body
   destination was overwritten.

   COPY with Overwrite

      >>Request

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

      >>Response

        HTTP/1.1 204 No Content

   The following example shows the value of the 'lockdiscovery' property.  Note
   that the Lock-Token header would not be returned in same copy operation being performed,
   but with the Overwrite header set to "F." A response for
   a successful refresh LOCK request because a new lock was not created.

   The scope of a lock 412
   (Precondition Failed) is returned because the entire state of the resource, including
   its body and associated properties.  As a result, a lock on a destination resource MUST also lock the resource's properties.

   For collections,
   has a lock also affects the ability to add or remove
   members.  The nature non-null state.

   COPY with No Overwrite

      >>Request

        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

      >>Response

        HTTP/1.1 412 Precondition Failed
   Example - COPY of a Collection

      >>Request

        COPY /container/ HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/othercontainer/
        Depth: infinity

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>

        <d:multistatus xmlns:d="DAV:">
         <d:response>
           <d:href>http://www.example.com/othercontainer/R2/</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus>

   The Depth header is unnecessary as the effect depends upon the type default behavior of access
   control involved.  This means that if COPY on a
   collection is locked, its
   lock-token is required in all these cases:

   o  DELETE a collection's direct internal member
   o  MOVE to act as if a member out "Depth: infinity" header had been
   submitted.  In this example most of the collection
   o  MOVE a member into resources, along with the
   collection, unless it overwrites a pre-
      existing member
   o  MOVE to rename it within a collection,
   o  COPY a member into a collection, unless it overwrites a pre-
      existing member
   o  PUT or MKCOL request which would create a new member.

   The collection's lock token were copied successfully.  However the collection R2
   failed because the destination R2 is required in addition locked.  Because there was an
   error copying R2, none of R2's members were copied.  However no
   errors were listed for those members due to the lock token
   on the internal member itself, if it exists. error minimization
   rules.

8.10  MOVE

   The interaction of MOVE operation on a LOCK with various methods non-collection resource is dependent upon the
   lock type.  However, independent logical
   equivalent of lock type, a successful DELETE of copy (COPY), followed by consistency maintenance
   processing, followed by a resource MUST cause all delete of its direct locks the source, where all three
   actions are performed atomically.  The consistency maintenance step
   allows the server to be removed.

8.11.1  Refreshing Locks

   A lock is refreshed perform updates caused by sending a LOCK request without a body to a
   resource within the scope of move, such as
   updating all URLs other than the lock.  A LOCK request to refresh a
   lock must specify Request-URI which lock identify the
   source resource, to point to refresh by using the Lock-Token new destination resource.
   Consequently, the Destination header with a single lock token (only one lock may MUST be refreshed at a
   time).  This request present on all MOVE
   methods and MUST NOT contain follow all COPY requirements for the COPY part of
   the MOVE method.  All WebDAV compliant resources MUST support the
   MOVE method.  However, support for the MOVE method does not guarantee
   the ability to move a body, but resource to a particular destination.

   For example, separate programs may actually control different sets of
   resources on the same server.  Therefore, it may contain not be possible to
   move a
   Timeout header.  A server MAY accept the Timeout header resource within a namespace that appears to belong to change the
   duration remaining on same
   server.

   If a resource exists at the lock destination, the destination resource
   will be deleted as a side-effect of the MOVE operation, subject to
   the new value.  A server restrictions of the Overwrite header.

8.10.1  MOVE for Properties

   Live properties described in this document MUST
   ignore be moved along with
   the Depth header on a LOCK refresh, and resource, such that the client SHOULD NOT
   send resource has identically behaving live
   properties at the Depth header on a LOCK refresh as destination resource, but not necessarily with the server
   same values.  If the live properties will not
   convert work the lock or confirm same way at
   the depth.

   If destination, the resource has other (shared) locks, those locks are unaffected
   by a lock refresh.  Additionally, those locks do not prevent server MUST fail the
   named lock from being refreshed.

   Note request (the client can
   perform COPY then DELETE if it wants a MOVE to work that badly).
   This can mean that in RFC2518, clients were indicated through the example in server reports the text to use live property as "Not
   Found" if that's the If header to specify what lock to refresh (rather
   than most appropriate behavior for that live property
   at the Lock-Token header).  Servers are encouraged to continue to
   support this destination, as well long as the Lock-Token header.

8.11.2  Depth and Locking

   The Depth header may be used live property is still supported
   with the LOCK method.  Values other than
   0 or infinity MUST NOT same semantics.

   MOVE is frequently used by clients to rename a file without changing
   its parent collection, so it's not appropriate to reset live
   properties which are set at resource creation.  For example, the
   creationdate property value SHOULD remain the same after a MOVE.

   Dead properties must be used moved along with the Depth header on a LOCK
   method.  All resources that support the LOCK method MUST support the
   Depth header. resource.

8.10.2  MOVE for Collections

   A Depth header of value 0 means to just lock MOVE with "Depth: infinity" instructs that the resource specified collection
   identified by the Request-URI.

   If the Depth header is set Request-URI be moved to infinity then the resource address specified in
   the Request-URI along with Destination header, and all resources identified by its internal members, all the way down
   the hierarchy,
   member URLs are to be locked.  A successful result MUST return a
   single lock token which represents moved to locations relative to it, recursively
   through all levels of the resources that have been
   locked.  If an UNLOCK is successfully executed collection hierarchy.

   The MOVE method on this token, all
   associated resources are unlocked.  If the lock cannot be granted to
   all resources, a 207 (Multi-Status) status code collection MUST be returned with act as if a response entity body containing "Depth: infinity"
   header was used on it.  A client MUST NOT submit a multistatus XML element
   describing which resource(s) prevented the lock from being granted.
   Hence, partial success is not an option.  Either the entire hierarchy
   is locked or no resources are locked.

   If no Depth header is submitted on a LOCK request then the request
   MUST act as if
   MOVE on a "Depth:infinity" had been submitted.

8.11.3  Locking Unmapped URLs

   A successful LOCK method collection with any value but "infinity".

   Any headers included with MOVE MUST result be applied in processing every
   resource to be moved with the creation exception of an empty
   resource which is locked (and which the Destination header.
   The behavior of the Destination header is not a collection), when the same as given for COPY
   on collections.

   When the MOVE method has completed processing it MUST have created a
   resource did not previously exist
   consistent namespace at that URL.  Later on, both the lock
   may go away but source and destination (see section
   5.1 for the empty resource remains.  Empty resources MUST
   then appear in PROPFIND responses including that URL in definition of namespace consistency).  However, if an
   error occurs while moving an internal collection, the response
   scope.  A server MUST respond successfully NOT
   move any resources identified by members of the failed collection
   (i.e., the server must skip the error-causing subtree), as this would
   create an inconsistent namespace.  In this case, after detecting the
   error, the move operation SHOULD try to a GET request finish as much of the
   original move as possible (i.e., the server should still attempt to an
   empty resource, either by using a 204 No Content response, or by
   using 200 OK with a Content-Length header indicating zero length
   move other subtrees and
   no Content-Type.

8.11.4  Lock Compatibility Table

   The table below describes the behavior resources identified by their members,
   that occurs when a lock
   request are not descendents of an error-causing collection).  So, for
   example, if an infinite depth move is made performed on a resource.

        Current State   Shared Lock Request   Exclusive Lock Request
      --------------------------------------------------------------------
        None            True                  True
        Shared Lock     True                  False
        Exclusive Lock  False                 False*

   Legend: True = lock may be granted.  False = lock MUST NOT collection /a/,
   which contains collections /a/b/ and /a/c/, and an error occurs
   moving /a/b/, an attempt should still be
   granted.  *=It is illegal for a principal made to request try moving /a/c/.
   Similarly, after encountering an error moving a non- collection
   resource as part of an infinite depth move, the same lock
   twice.

   The current lock state server SHOULD try to
   finish as much of the original move operation as possible.

   If an error occurs with a resource is given in other than the leftmost column,
   and lock requests are listed resource identified
   in the first row.  The intersection of Request-URI then the response MUST be a
   row 207 (Multi-Status),
   and column gives the result of a lock request.  For example, if a
   shared lock is held on errored resource's URL MUST appear with the specific error.

   The 424 (Failed Dependency) status code SHOULD NOT be returned in the
   207 (Multi-Status) response from a resource, and an exclusive lock is
   requested, MOVE method.  These errors can be
   safely omitted because the table entry is "false", indicating client will know that the lock must progeny of a
   resource could not be granted.

8.11.5  LOCK responses

   200 (OK) - The lock request succeeded and moved when the value of client receives an error for the
   lockdiscovery property is included
   parent.  Additionally 201 (Created)/204 (No Content) responses SHOULD
   NOT be returned as values in 207 (Multi-Status) responses from a
   MOVE.  These responses can be safely omitted because they are the body.

   409 (Conflict) - A
   default success codes.

8.10.3  MOVE and the Overwrite Header

   If a resource cannot be created exists at the destination
   until one or more intermediate collections have been created.  The destination and the Overwrite header is
   "T" then prior to performing the move the server MUST NOT create those intermediate collections automatically.

   412 (Precondition Failed) - The included lock token was not
   enforceable perform a
   DELETE with "Depth: infinity" on this resource or the server could not satisfy destination resource.  If the
   request in
   Overwrite header is set to "F" then the lockinfo XML element.

   423 (Locked) operation will fail.

8.10.4  Status Codes

   201 (Created) - The source resource is locked already.  For consistency's
   sake, this response SHOULD contain was successfully moved, and a new
   resource was created at the 'missing-lock-token'
   precondition element.

   400 (Bad Request), with 'request-uri-must-match-lock-token'
   precondition destination.

   204 (No Content) - The LOCK request source resource was made with successfully moved to a Lock-Token header,
   indicating that the client wishes
   pre-existing destination resource.

   207 (Multi-Status) - Multiple resources were to refresh the given lock.
   However, the Request-URI did not fall within the scope of the lock
   identified be affected by the token.  The lock may have a scope that does not
   include the Request-URI, or the lock could have disappeared, or the
   token may be invalid.

8.11.6  Example - Simple Lock Request

      >>Request

        LOCK /workspace/webdav/proposal.doc HTTP/1.1
        Host: example.com
        Timeout: Infinite, Second-4100000000
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx
        Authorization: Digest username="ejw",
           realm="ejw@example.com", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

        <?xml version="1.0" encoding="utf-8" ?>
        <D:lockinfo xmlns:D='DAV:'>
         <D:lockscope><D:exclusive/></D:lockscope>
         <D:locktype><D:write/></D:locktype>
         <D:owner>
           <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
         </D:owner>
        </D:lockinfo>

      >>Response

        HTTP/1.1 200 OK
        Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <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:e71d4fae-5dec-22d6-fea5-
        00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href>http://example.com/workspace/webdav
                 /proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop>

   This example shows
   MOVE, but errors on some of them prevented the successful creation operation from taking
   place.  Specific error messages, together with the most appropriate
   of an exclusive write lock
   on the source and destination URLs, appear in the body of the multi-
   status response.  E.g. if a source resource http://example.com/workspace/webdav/proposal.doc.  The was locked and could not
   be moved, then the source resource http://www.ics.uci.edu/~ejw/contact.html contains contact
   information for URL appears with the owner of 423 (Locked)
   status.

   403 (Forbidden) - The source and destination resources are the lock. same.

   409 (Conflict) - A resource cannot be created at the destination
   until one or more intermediate collections have been created.  The
   server has an
   activity-based timeout policy in place on this resource, which causes MUST NOT create those intermediate collections automatically.
   Or, the lock server was unable to automatically be removed after 1 week (604800 seconds).
   Note that preserve the nonce, response, behavior of the live
   properties and opaque fields have not been
   calculated in still move the Authorization request header.

   Note that resource to the locktoken destination (see 'live-
   properties-not-preserved' postcondition).

   412 (Precondition Failed) n A condition failed, e.g. the Overwrite
   header is "F" and lockroot href elements would not contain
   any whitespace.  The line return appearing in this document the state of the destination resource is only
   for formatting.

8.11.7  Example - Refreshing a Write Lock

      >>Request

        LOCK /workspace/webdav/proposal.doc HTTP/1.1
        Host: example.com
        Timeout: Infinite, Second-4100000000
        Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
        Authorization: Digest username="ejw",
           realm="ejw@example.com", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

      >>Response

        HTTP/1.1 200 OK
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <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:e71d4fae-5dec-22d6-fea5-
        00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href>http://example.com/workspace/webdav
                 /proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop> non-null.

   423 (Locked) - The source or the destination resource, or some
   resource within the source or destination collection, was locked.
   This request would refresh response SHOULD contain the lock, attempting to reset 'missing-lock-token' precondition
   element.

   502 (Bad Gateway) - This may occur when the timeout
   to destination is on another
   server and the new value specified in destination server refuses to accept the timeout header.  Notice that resource.
   This could also occur when the
   client asked for an infinite time out but destination is on another sub-section
   of the same server choose namespace.

8.10.5  Examples

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being moved to ignore the request.  In this example,
   location http://www.ics.uci.edu/users/f/fielding/index.html.  The
   contents of the nonce, response, and opaque fields destination resource would have not been calculated in overwritten if
   the Authorization request header.

8.11.8  Example - Multi-Resource Lock Request destination resource had been non-null.  In this case, since
   there was nothing at the destination resource, the response code is
   201 (Created).

   MOVE of a Non-Collection

      >>Request

        LOCK /webdav/

        MOVE /~fielding/index.html HTTP/1.1
        Host: example.com
        Timeout: Infinite, Second-4100000000
        Depth: infinity
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx
        Authorization: Digest username="ejw",
           realm="ejw@example.com", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

        <?xml version="1.0" encoding="utf-8" ?>
        <D:lockinfo xmlns:D="DAV:">
         <D:locktype><D:write/></D:locktype>
         <D:lockscope><D:exclusive/></D:lockscope>
         <D:owner>
           <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
         </D:owner>
        </D:lockinfo> www.ics.uci.edu
        Destination: http://www.ics.uci.edu/users/f/fielding/index.html

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:">
         <D:response>
           <D:href>http://example.com/webdav/secret</D:href>
           <D:status>HTTP/1.1 403 Forbidden</D:status>
         </D:response>
         <D:response>
           <D:href>http://example.com/webdav/</D:href>
           <D:propstat>
             <D:prop><D:lockdiscovery/></D:prop>
             <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>
   This example shows a request for an exclusive write lock on 201 Created
        Location: http://www.ics.uci.edu/users/f/fielding/index.html
   MOVE of a
   collection and all its children. Collection

      >>Request

        MOVE /container/ HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/othercontainer/
        Overwrite: F
        If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
            (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <d:multistatus xmlns:d='DAV:'>
         <d:response>
           <d:href>http://www.example.com/othercontainer/C2/</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
         </d:response>
        </d:multistatus>

   In this request, example the client has
   specified that it desires an infinite length lock, if available,
   otherwise submitted a timeout number of 4.1 billion seconds, if available.  The
   request entity body contains lock tokens with
   the contact information request.  A lock token will need to be submitted for every
   resource, both source and destination, anywhere in the
   principal taking out scope of the lock, in
   method, that is locked.  In this case a web page URL.

   The error is a 403 (Forbidden) response on the proper lock token was not
   submitted for the destination
   http://www.example.com/othercontainer/C2/.  This means that the
   resource http://
   example.com/webdav/secret.  Because this resource /container/C2/ could not be
   locked, moved.  Because there was an
   error moving /container/C2/, none of the resources /container/C2's members were locked.  Note also that the
   lockdiscovery property
   moved.  However no errors were listed for those members due to the Request-URI
   error minimization rules.  User agent authentication has been included as
   required.  In this example the lockdiscovery property is empty which
   means that there are no outstanding locks on previously
   occurred via a mechanism outside the resource.

   In this example, scope of the nonce, response, and opaque fields have not been
   calculated HTTP protocol, in the Authorization request header.

8.12  UNLOCK
   an underlying transport layer.

8.11  LOCK Method

   The UNLOCK method removes the lock identified by following sections describe the LOCK method, which is used to
   take out a lock token in of any access type and to refresh an existing lock.
   These sections on the Lock-Token request header.  The Request-URI MUST identify a
   resource within LOCK method describe only those semantics that
   are specific to the scope LOCK method and are independent of the lock.  The If header is not needed
   to provide access
   type of the lock token although servers SHOULD still evaluate being requested.

   Any resource which supports the
   If header LOCK method MUST, at minimum, support
   the XML request and treat it as a conditional header.

   For a successful response formats defined herein.

   A LOCK method invocation to this method, the server MUST remove the an unlocked resource creates a lock from on
   the resource identified by the Request-URI and from all
   other resources included in the lock.

   If all resources Request-URI, which have been locked under becomes the submitted lock
   token can not be unlocked then root of
   the UNLOCK request MUST fail.

   A successful response lock.  Lock method requests to create a new lock MUST have a XML
   request body which contains an UNLOCK method does not mean that the
   resource is necessarily unlocked.  It means that the specific owner XML element and other
   information for this lock
   corresponding to request.  The server MUST preserve the specified token no longer exists.

   Any DAV compliant resource which supports
   information provided by the LOCK method MUST
   support client in the owner field when the UNLOCK method.

8.12.1  Status Codes

   204 (No Content) - Normal success response

   400 (Bad Request) - No lock token was provided (see
   'missing-lock-token' precondition), or
   information is requested.  The LOCK request was made to MAY have a
   Request-URI Timeout
   header.

   Clients MUST assume that was not within the scope locks may arbitrarily disappear at any time,
   regardless of the lock (see
   'requesturi-must-match-lock-token' precondition).

   403 (Forbidden) - value given in the Timeout header.  The currently authenticated principal does not have
   permission to remove Timeout
   header only indicates the lock (the server SHOULD use behavior of the
   'need-privileges' precondition element).

   412 (Precondition Failed) - The resource was server if extraordinary
   circumstances do not locked.

8.12.2  Example

      >>Request

        UNLOCK /workspace/webdav/info.doc HTTP/1.1
        Host: example.com
        Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
        Authorization: Digest username="ejw",
           realm="ejw@example.com", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

      >>Response

        HTTP/1.1 204 No Content

   In this occur.  For example, the a sufficiently privileged
   user may remove a lock identified by at any time or the lock token
   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
   successfully removed from system may crash in such a
   way that it loses the resource http://example.com/workspace/
   webdav/info.doc.  If this lock included more than just one resource, record of the lock's existence.

   When a new lock is removed from all resources included in created, the lock.  The 204
   (No Content) status code is used instead LOCK response:

      MUST contain a body with the value of 200 (OK) because there is
   no response entity body.

   In this example, the nonce, response, and opaque fields have not been
   calculated lockdiscovery property
      in a prop XML element.

      MUST include the Authorization request header.

9.  HTTP Headers for Distributed Authoring

   All DAV headers follow Lock-Token response header with the same basic formatting rules as HTTP
   headers.  This includes rules like line continuation and how token
      associated with the new lock.

8.11.1  Refreshing Locks

   A lock is refreshed by sending a LOCK request without a body to
   combine (or separate) multiple instances a
   resource within the scope of the same header using
   commas.

9.1  DAV Header

      DAV             = "DAV" ":" #( compliance-code )
      compliance-code = ( "1" | "2" | "bis" | extend )
      extend          = Coded-URL | lock.  A LOCK request to refresh a
   lock must specify which lock to refresh by using the Lock-Token
   header with a single lock token (only one lock may be refreshed at a
   time).  This general-header appearing in request MUST NOT contain a body, but it may contain a
   Timeout header.  A server MAY accept the response indicates that Timeout header to change the
   resource supports
   duration remaining on the DAV schema and protocol as specified.  All DAV
   compliant resources lock to the new value.  A server MUST return
   ignore the DAV Depth header on all OPTIONS
   responses.

   The value is a comma-separated list of all compliance class
   identifiers that the resource supports.  Class identifiers may be
   Coded-URLs or tokens (as defined by [RFC2616]).  Identifiers can
   appear in any order.  Identifiers that are standardized through LOCK refresh, and the
   IETF RFC process are tokens, but other identifiers client SHOULD be Coded-
   URLs to encourage uniqueness.

   A resource must show class 1 compliance if it shows class 2 or "bis"
   compliance.  In general, support for one compliance class does not
   entail support for any other.  Please refer to section 16 for more
   details on compliance classes defined in this specification.

   This NOT
   send the Depth header must also appear on responses to OPTIONS requests to the
   special '*' Request-URI a LOCK refresh as defined in HTTP/1.1.  In this case it
   means that the repository supports server will not
   convert the lock or confirm the depth.

   If the resource has other (shared) locks, those locks are unaffected
   by a lock refresh.  Additionally, those locks do not prevent the
   named features lock from being refreshed.

   Note that in at least
   some internal namespaces.

   As an optional request header, this header allows RFC2518, clients were indicated through the client example in
   the text to
   advertise compliance with named features.  Clients need not advertise
   1, 2 or bis because a WebDAV server currently doesn't need that
   information use the If header to decide how specify what lock to respond refresh (rather
   than the Lock-Token header).  Servers are encouraged to requests defined in continue to
   support this
   specification or in HTTP/1.1.  However, future extensions may define
   client compliance codes.  When used as a request header, well as the DAV Lock-Token header.

   Note that the Lock-Token header MAY affect caching so this is not be returned in the response
   for a successful refresh LOCK request, but the LOCK response body
   MUST contain the new value for the lockdiscovery body.

8.11.2  Depth and Locking

   The Depth header SHOULD may be used with the LOCK method.  Values other than
   0 or infinity MUST NOT be used with the Depth header on all
   GET requests.

9.2 a LOCK
   method.  All resources that support the LOCK method MUST support the
   Depth Header header.

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

   The header of value 0 means to just lock the resource specified
   by the Request-URI.

   If the Depth request header is used set to infinity then the resource specified in
   the Request-URI along with methods executed on resources
   which could potentially have all its internal members members, all the way down
   the hierarchy, are to indicate whether be locked.  A successful result MUST return a
   single lock token which represents all the
   method resources that have been
   locked.  If an UNLOCK is to successfully executed on this token, all
   associated resources are unlocked.  If the lock cannot be applied only granted to
   all resources, a 207 (Multi-Status) status code MUST be returned with
   a response entity body containing a multistatus XML element
   describing which resource(s) prevented the resource ("Depth: 0"), to lock from being granted.
   Hence, partial success is not an option.  Either the
   resource and its immediate children, ("Depth: 1"), entire hierarchy
   is locked or the resource
   and all its progeny ("Depth: infinity").

   The no resources are locked.

   If no Depth header is only supported if submitted on a method's definition
   explicitly provides for such support.

   The following rules are LOCK request then the default behavior for any request
   MUST act as if a "Depth:infinity" had been submitted.

8.11.3  Locking Unmapped URLs

   A successful LOCK method MUST result in the creation of an empty
   resource which is locked (and which is not a collection), when a
   resource did not previously exist at that
   supports URL.  Later on, the Depth header.  A method lock
   may override these defaults by
   defining different behavior go away but the empty resource remains.  Empty resources MUST
   then appear in PROPFIND responses including that URL in its definition.

   Methods which support the Depth response
   scope.  A server MUST respond successfully to a GET request to an
   empty resource, either by using a 204 No Content response, or by
   using 200 OK with a Content-Length header indicating zero length and
   no Content-Type.

8.11.4  Lock Compatibility Table

   The table below describes the behavior that occurs when a lock
   request is made on a resource.

        Current State   Shared Lock Request   Exclusive Lock Request
      ----------------------------------------------------------------
        None            True                  True
        Shared Lock     True                  False
        Exclusive Lock  False                 False*

   Legend: True = lock may choose not be granted.  False = lock MUST NOT be
   granted. *=It is illegal for a principal to support all request the same lock
   twice.

   The current lock state of a resource is given in the header's values leftmost column,
   and may define, on a case by case basis, lock requests are listed in the
   behavior first row.  The intersection of a
   row and column gives the method if result of a Depth header is not present. lock request.  For example, the MOVE method only supports "Depth: infinity" and if a
   Depth header
   shared lock is not present will act as if a "Depth: infinity" header
   had been applied.

   Clients MUST NOT rely upon methods executing on members of their
   hierarchies in any particular order or held on the execution being atomic
   unless the particular method explicitly provides such guarantees.

   Upon execution, a method with a Depth header will perform as much of
   its assigned task as possible and then return a response specifying
   what it was able to accomplish resource, and what it failed to do.

   So, for example, an attempt to COPY a hierarchy may result in some of exclusive lock is
   requested, the members being copied table entry is "false", indicating the lock must not
   be granted.

8.11.5  LOCK responses

   200 (OK) - The lock request succeeded and some not.

   Any headers on the value of the
   lockdiscovery property is included in the body.

   409 (Conflict) - A resource cannot be created at the destination
   until one or more intermediate collections have been created.  The
   server MUST NOT create those intermediate collections automatically.

   423 (Locked) - The resource is locked already.  For consistency's
   sake, this response SHOULD contain the 'missing-lock-token'
   precondition element.

   h 400 (Bad Request), with 'request-uri-must-match-lock-token'
   precondition - The LOCK request was made with a method Lock-Token header,
   indicating that has a defined interaction with the Depth
   header MUST be applied client wishes to all resources in refresh the scope of given lock.
   However, the method
   except where alternative behavior is explicitly defined.  For
   example, an If-Match header will have its value applied against every
   resource in Request-URI did not fall within the method's scope and will cause of the method to fail if lock
   identified by the header fails to match.

   If token.  The lock may have a resource, source scope that does not
   include the Request-URI, or destination, within the scope of lock could have disappeared, or the method
   with
   token may be invalid.

   424 (Failed Dependency) - This may appear inside a Depth header is locked in such 207 response to a way as
   LOCK request, to prevent indicate that a resource could not be locked because
   of a failure on another resource.

8.11.6  Example - Simple Lock Request

    >>Request

      LOCK /workspace/webdav/proposal.doc HTTP/1.1
      Host: example.com
      Timeout: Infinite, Second-4100000000
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx
      Authorization: Digest username="ejw",
         realm="ejw@example.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

      <?xml version="1.0" encoding="utf-8" ?>
      <D:lockinfo xmlns:D='DAV:'>
       <D:lockscope><D:exclusive/></D:lockscope>
       <D:locktype><D:write/></D:locktype>
       <D:owner>
         <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
       </D:owner>
      </D:lockinfo>

    >>Response

      HTTP/1.1 200 OK
      Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:prop xmlns:D="DAV:">
       <D:lockdiscovery>
         <D:activelock>
           <D:locktype><D:write/></D:locktype>
           <D:lockscope><D:exclusive/></D:lockscope>
           <D:depth>infinity</D:depth>
           <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:e71d4fae-5dec-22d6-fea5-
      00a0c91e6be4</D:href>
           </D:locktoken>
           <D:lockroot>
             <D:href>http://example.com/workspace/webdav
               /proposal.doc</D:href>
           </D:lockroot>
         </D:activelock>
       </D:lockdiscovery>
      </D:prop>

   This example shows the successful execution creation of the method, then the an exclusive write lock token for that
   on resource http://example.com/workspace/webdav/proposal.doc.  The
   resource MUST be submitted with http://www.ics.uci.edu/~ejw/contact.html contains contact
   information for the request in owner of the If request header. lock.  The Depth header only specifies the behavior of server has an activity-
   based timeout policy in place on this resource, which causes the method with
   regards lock
   to internal children.  If a resource does not have internal
   children then the Depth header MUST automatically be ignored.

   Please note, however, that it is always an error to submit a value
   for the Depth header removed after 1 week (604800 seconds).  Note that is not allowed by the method's definition.
   Thus submitting a "Depth: 1" on a COPY, even if
   the resource does not nonce, response, and opaque fields have internal members, will result in a 400 (Bad Request).  The
   method should fail not because the resource doesn't have internal
   members, but because of the illegal value been calculated in
   the header.

9.3  Destination Header

   Destination = "Destination" ":" ( absoluteURI )

   The Destination Authorization request header specifies the URI which identifies a
   destination resource for methods such as COPY and MOVE, which take
   two URIs as parameters. header.

   Note that the absoluteURI production is
   defined locktoken and lockroot href elements would not contain
   any whitespace.  The line return appearing in RFC2396 [6].

   If the Destination value this document is an absolute URI, it may name a different
   server (or different port or scheme).  If the source server cannot
   attempt only
   for formatting.

8.11.7  Example - Refreshing a copy to the remote server, it MUST fail the Write Lock

    >>Request

      LOCK /workspace/webdav/proposal.doc HTTP/1.1
      Host: example.com
      Timeout: Infinite, Second-4100000000
      Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
      Authorization: Digest username="ejw",
         realm="ejw@example.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

    >>Response

      HTTP/1.1 200 OK
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <D:prop xmlns:D="DAV:">
       <D:lockdiscovery>
         <D:activelock>
           <D:locktype><D:write/></D:locktype>
           <D:lockscope><D:exclusive/></D:lockscope>
           <D:depth>infinity</D:depth>
           <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:e71d4fae-5dec-22d6-fea5-
      00a0c91e6be4</D:href>
           </D:locktoken>
           <D:lockroot>
             <D:href>http://example.com/workspace/webdav
               /proposal.doc</D:href>
           </D:lockroot>
         </D:activelock>
       </D:lockdiscovery>
      </D:prop>

   This request with a
   502 (Bad Gateway) response.  Servers MAY attempt would refresh the lock, attempting to copy reset the resource timeout
   to the remote server using PUT/PROPPATCH or another mechanism.

9.4  Force-Authentication Header

   Force-Authentication = "Force-Authentication" ":" Method

   The Force-Authentication request header is used with new value specified in the OPTIONS
   method to specify timeout header.  Notice that the
   client wants to be challenged asked for
   authentication credentials an infinite time out but the server choose to ignore
   the resource identified by request.  In this example, the
   Request-URI.  If present on nonce, response, and opaque fields
   have not been calculated in the Authorization request header.

8.11.8  Example - Multi-Resource Lock Request

      >>Request

        LOCK /webdav/ HTTP/1.1
        Host: example.com
        Timeout: Infinite, Second-4100000000
        Depth: infinity
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx
        Authorization: Digest username="ejw",
           realm="ejw@example.com", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

        <?xml version="1.0" encoding="utf-8" ?>
        <D:lockinfo xmlns:D="DAV:">
         <D:locktype><D:write/></D:locktype>
         <D:lockscope><D:exclusive/></D:lockscope>
         <D:owner>
           <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
         </D:owner>
        </D:lockinfo>

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:">
         <D:response>
           <D:href>http://example.com/webdav/secret</D:href>
           <D:status>HTTP/1.1 403 Forbidden</D:status>
         </D:response>
         <D:response>
           <D:href>http://example.com/webdav/</D:href>
           <D:propstat>
             <D:prop><D:lockdiscovery/></D:prop>
             <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>
   This example shows a request to for an exclusive write lock on a WebDAV-compliant resource,
   collection and all its children.  In this request, the server MUST respond with either 401 (Unauthorized) or 501 (Not
   Implemented) status code. client has
   specified that it desires an infinite length lock, if available,
   otherwise a timeout of 4.1 billion seconds, if available.  The Method value is used
   request entity body contains the contact information for the client to
   indicate what method it intends to use first on
   principal taking out the resource
   identified lock, in the Request-URI.

9.5  If Header

      If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
      No-tag-list = List
      Tagged-list = Resource 1*List
      Resource = Coded-URL
      List = #( "(" List | Clause ")" )
      Clause = ["Not"] State-token | State-token
      State-token = Coded-URL  | "[" entity-tag "]"
      Coded-URL = "<" absoluteURI ">" this case a web page URL.

   The If request header error is intended to have similar functionality to a 403 (Forbidden) response on the If- Match header defined in section 14.24 resource
   http://example.com/webdav/secret.  Because this resource could not be
   locked, none of RFC2616 [8].
   However the If header is intended resources were locked.  Note also that the
   lockdiscovery property for use with any URI which
   represents state information, referred to as a state token, about a
   resource as well the Request-URI has been included as ETags.  A typical
   required.  In this example of a state token is a
   lock token, and lock tokens are the only state tokens defined in this
   specification.  The <DAV:no-lock> state token lockdiscovery property is a special token empty which
   means that
   must never match an actual valid lock token.  The purpose of this is
   described in section 9.5.5.

   The If header's purpose is to describe a series of state lists.  If
   the state of there are no outstanding locks on the resource to which resource.

   In this example, the header is applied does nonce, response, and opaque fields have not
   match any of been
   calculated in the Authorization request header.

8.12  UNLOCK Method

   The UNLOCK method removes the specified state lists then lock identified by the lock token in
   the Lock-Token request header.  The Request-URI MUST fail
   with identify a 412 (Precondition Failed).  If one of the described state
   lists matches
   resource within the state scope of the resource then the request may succeed. lock.  The server must parse the If header when it appears on any request,
   evaluate all the clauses, and if the conditional evaluates to false,
   fail the request.

   Note that the absoluteURI production is defined in RFC2396 [6].

   RFC2518 originally defined not needed
   to provide the If header without comma separators.
   This oversight meant that lock token although servers SHOULD still evaluate the
   If header couldn't be divided up among
   multiple lines according and treat it as a conditional header.

   For a successful response to this method, the HTTP header manipulation rules.
   Servers supporting "bis" server MUST be able to accept commas in If header
   values.  If remove the header has commas between tokens or clauses,
   lock from the
   header can be evaluated simply resource identified by removing the commas Request-URI and proceeding
   with from all
   other resources included in the evaluation rules.

9.5.1  No-tag-list Production

   The No-tag-list production describes a series of state tokens and
   ETags. lock.

   If multiple No-tag-list productions are used then one only
   needs to match the state of the resource for all resources which have been locked under the method to submitted lock
   token can not be allowed
   to continue.  All untagged tokens apply to the resource identified in unlocked then the Request-URI.

   Example - no-tag-list production

        If: (<opaquelocktoken:a-write-lock-token> ["I am an ETag"]), (["I
        am another ETag"])

   The previous header would require UNLOCK request MUST fail.

   A successful response to an UNLOCK method does not mean that the
   resource identified in is necessarily unlocked.  It means that the
   Request-URI be locked with specific lock
   corresponding to the specified lock token and in no longer exists.

   Any DAV compliant resource which supports the state
   identified by LOCK method MUST
   support the "I am UNLOCK method.

8.12.1  Status Codes

   204 (No Content) - Normal success response (rather than 200 OK, since
   200 OK would imply a response body, and an ETag" ETag UNLOCK success response
   does not normally contain a body)

   400 (Bad Request) - No lock token was provided (see 'missing-lock-
   token' precondition), or in the state identified by
   the second ETag "I am another ETag".  To put the matter more plainly
   one can think of the previous If header as being in the form (or (and
   <opaquelocktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am
   another ETag"])).

9.5.2  Tagged-list Production

   The tagged-list production scopes request was made to a list production.  That is, it
   specifies Request-URI that was
   not within the lists following scope of the resource specification only
   apply lock (see 'requesturi-must-match-lock-
   token' precondition).

   403 (Forbidden) - The currently authenticated principal does not have
   permission to remove the specified resource.  The scope of lock (the server SHOULD use the 'need-
   privileges' precondition element).

   412 (Precondition Failed) - The resource
   production begins with was not locked.

8.12.2  Example

    >>Request

      UNLOCK /workspace/webdav/info.doc HTTP/1.1
      Host: example.com
      Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
      Authorization: Digest username="ejw",
         realm="ejw@example.com", nonce="...",
         uri="/workspace/webdav/proposal.doc",
         response="...", opaque="..."

    >>Response

      HTTP/1.1 204 No Content

   In this example, the list production immediately following lock identified by the
   resource production and ends with lock token
   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
   successfully removed from the next resource production, if
   any.  All clauses must be evaluated.
   http://example.com/workspace/webdav/info.doc.  If this lock included
   more than just one resource, the state of the resource
   named lock is removed from all resources
   included in the tag does not match any lock.  The 204 (No Content) status code is used
   instead of 200 (OK) because there is no response entity body.

   In this example, the associated state lists
   then nonce, response, and opaque fields have not been
   calculated in the Authorization request MUST fail with a 412 (Precondition Failed).

   The same URI MUST NOT appear more than once in a resource production
   in an If header.

   Example - Tagged List If header

        COPY /resource1 HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/resource2
        If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
        token> [W/"A weak ETag"]), (["strong ETag"]),
        <http://www.bar.bar/random>(["another strong ETag"])

   In this example http://www.example.com/resource1 is being copied to
   http://www.example.com/resource2.  When

9.  HTTP Headers for Distributed Authoring

   All DAV headers follow the method is first applied same basic formatting rules as HTTP
   headers.  This includes rules like line continuation and how to http://www.example.com/resource1, resource1 must be
   combine (or separate) multiple instances of the same header using
   commas.

9.1  DAV Header

      DAV             = "DAV" ":" #( compliance-code )
      compliance-code = ( "1" | "2" | "bis" | extend )
      extend          = Coded-URL | token

   This general-header appearing in the state
   specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
   (["strong ETag"])", response indicates that is, it either must be locked with a lock
   token of "locktoken:a-write-lock-token" the
   resource supports the DAV schema and have a weak entity tag W/
   "A weak ETag" or it must have a strong entity tag "strong ETag".

   That protocol as specified.  All DAV
   compliant resources MUST return the DAV header on all OPTIONS
   responses.

   The value is the only success condition since a comma-separated list of all compliance class
   identifiers that the resource http://
   www.bar.bar/random never has supports.  Class identifiers may be
   Coded-URLs or tokens (as defined by [RFC2616]).  Identifiers can
   appear in any order.  Identifiers that are standardized through the method applied to it (the only
   IETF RFC process are tokens, but other identifiers SHOULD be Coded-
   URLs to encourage uniqueness.

   A resource listed in the If header) and http://www.example.com/
   resource2 is not listed in the If header.

9.5.3  Not Production

   Every state token or ETag is either current, and hence describes the
   state of a resource, must show class 1 compliance if it shows class 2 or is not current, and "bis"
   compliance.  In general, support for one compliance class does not describe the
   state of a resource.  The boolean operation of matching a state token
   or ETag
   entail support for any other.  Please refer to the current state of a resource thus resolves section 16 for more
   details on compliance classes defined in this specification.

   This header must also appear on responses to a true or
   false value.  The "Not" production is used OPTIONS requests to reverse the
   special '*' Request-URI as defined in HTTP/1.1.  In this case it
   means that value.
   The scope of the not production is repository supports the state-token named features in at least
   some internal namespaces.

   As an optional request header, this header allows the client to
   advertise compliance with named features.  Clients need not advertise
   1, 2 or entity-tag
   immediately following it.

        If: (Not <locktoken:write1> <locktoken:write2>) bis because a WebDAV server currently doesn't need that
   information to decide how to respond to requests defined in this
   specification or in HTTP/1.1.  However, future extensions may define
   client compliance codes.  When submitted with used as a request, request header, the DAV
   header MAY affect caching so this If header requires that all
   operand resources must not be locked with locktoken:write1 and must SHOULD NOT be locked with locktoken:write2. used on all
   GET requests.

9.2  Depth Header

      Depth = "Depth" ":" ("0" | "1" | "infinity")
   The Not production Depth request header is particularly useful used with methods executed on resources
   which could potentially have internal members to indicate whether the "<DAV:no-lock>"
   state token.  The clause "Not <DAV:no-lock>" must evaluate
   method is to be applied only to true.
   Thus, any "OR" statement containing the clause "Not <DAV:no-lock>"
   must also evaluate resource ("Depth: 0"), to true.

9.5.4  Matching Function

   When performing If header processing, the definition of a matching
   state token
   resource and its immediate children, ("Depth: 1"), or entity tag the resource
   and all its progeny ("Depth: infinity").

   The Depth header is as follows.

   Identifying only supported if a resource: method's definition
   explicitly provides for such support.

   The resource is identified by following rules are the URI along
   with default behavior for any method that
   supports the token, in tagged list production, or Depth header.  A method may override these defaults by the Request-URI in
   untagged list production.

   Matching entity tag: Where the entity tag matches an entity tag
   associated with the identified resource.

   Matching state token: Where there is an exact match between the state
   token
   defining different behavior in its definition.

   Methods which support the If Depth header and any state token on the identified
   resource.  A lock state token is considered may choose not to match if support all
   of the resource
   is anywhere in header's values and may define, on a case by case basis, the scope
   behavior of the lock.

   Example - Matching lock tokens with collection locks

        DELETE /specs/rfc2518.txt HTTP/1.1
        Host: www.example.com
        If: <http://www.example.com/specs/> (<locktoken:a-write-lock-token>) method if a Depth header is not present.  For this
   example, the lock token must be compared to the identified
   resource, which MOVE method only supports "Depth: infinity" and if a
   Depth header is the 'specs' collection identified by the URL not present will act as if a "Depth: infinity" header
   had been applied.

   Clients MUST NOT rely upon methods executing on members of their
   hierarchies in any particular order or on the tagged list production.  If execution being atomic
   unless the 'specs' collection is not locked
   or has particular method explicitly provides such guarantees.

   Upon execution, a lock method with a different token, the request MUST fail.  If the
   'specs' collection is locked (depth infinity) with that lock token,
   then this request could succeed, both because the If Depth header evaluates will perform as much of
   its assigned task as possible and then return a response specifying
   what it was able to true, accomplish and because the lock token what it failed to do.

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

   Any headers on a method that has been provided.  Alternatively, a request where
   the 'rfc2518.txt' URL is associated defined interaction with the lock token Depth
   header MUST be applied to all resources in the scope of the method
   except where alternative behavior is explicitly defined.  For
   example, an If-Match header will have its value applied against every
   resource in the If
   header could also succeed.

9.5.5  If Header method's scope and Non-DAV Aware Proxies

   Non-DAV aware proxies will not honor cause the If header, since they will
   not understand method to fail if
   the If header, and HTTP requires non-understood
   headers header fails to be ignored.  When communicating with HTTP/1.1 proxies, match.

   If a resource, source or destination, within the
   "Cache-Control: no-cache" request scope of the method
   with a Depth header MUST be used so is locked in such a way as to prevent the proxy from improperly trying to service
   successful execution of the request from
   its cache.  When dealing with HTTP/1.0 proxies method, then the "Pragma: no-
   cache" request header lock token for that
   resource MUST be used for submitted with the same reason.

9.6  Lock-Token Header

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

   The Lock-Token request in the If request header.

   The Depth header is used with only specifies the UNLOCK method to
   identify behavior of the lock method with
   regards to be removed.  The lock token in internal children.  If a resource does not have internal
   children then the Lock-Token
   request Depth header MUST identify be ignored.

   Please note, however, that it is always an error to submit a lock value
   for the Depth header that contains is not allowed by the method's definition.
   Thus submitting a "Depth: 1" on a COPY, even if the resource
   identified by Request-URI as does not
   have internal members, will result in a member. 400 (Bad Request).  The Lock-Token response header is used with the LOCK
   method to
   indicate should fail not because the lock token created as a result resource doesn't have internal
   members, but because of a successful LOCK
   request to create a new lock.

9.7  Overwrite the illegal value in the header.

9.3  Destination Header

   Overwrite

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

   The Overwrite Destination request header specifies whether the server should
   overwrite the state of URI which identifies a non-null
   destination resource during a for methods such as COPY
   or MOVE.  A value of "F" states and MOVE, which take
   two URIs as parameters.  Note that the server must not perform the
   COPY or MOVE operation if the state of the destination resource absoluteURI production is
   non-null.
   defined in RFC2396 [5].

   If the overwrite header Destination value is not included in an absolute URI, it may name a COPY different
   server (or different port or MOVE
   request then scheme).  If the resource MUST treat source server cannot
   attempt a copy to the request as if remote server, it has an
   overwrite header of value "T".  While MUST fail the Overwrite header appears request with a
   502 (Bad Gateway) response.  Servers MAY attempt to
   duplicate copy the functionality of resource
   to the If-Match: * remote server using PUT/PROPPATCH or another mechanism.

9.4  Force-Authentication Header

   Force-Authentication = "Force-Authentication" ":" Method

   The Force-Authentication request header of HTTP/1.1,
   If-Match applies only is used with the OPTIONS
   method to specify that the Request-URI, and not client wants to be challenged for
   authentication credentials to the Destination
   of a COPY or MOVE. resource identified by the Request-
   URI.  If present on a COPY or MOVE is not performed due request to a WebDAV-compliant resource, the
   server MUST respond with either 401 (Unauthorized) or 501 (Not
   Implemented) status code.  The Method value of is used for the Overwrite
   header, client to
   indicate what method it intends to use first on the method MUST fail with a 412 (Precondition Failed) status
   code.

   All DAV compliant resources MUST support resource
   identified in the Overwrite header.

9.8  Timeout Request Request-URI.

9.5  If Header

      TimeOut

      If = "Timeout" "If" ":" 1#TimeType
      TimeType ( 1*No-tag-list | 1*Tagged-list)
      No-tag-list = ("Second-" DAVTimeOutVal List
      Tagged-list = Resource 1*List
      Resource = Coded-URL
      List = #( "(" List | "Infinite")
      DAVTimeOutVal Clause ")" )
      Clause = 1*digit

   Clients may include Timeout ["Not"] State-token | State-token
      State-token = Coded-URL  | "[" entity-tag "]"
      Coded-URL = "<" absoluteURI ">"

   The If request headers in their LOCK requests.
   However, the server header is not required intended to honor or even consider these
   requests.  Clients MUST NOT submit a Timeout request have similar functionality to
   the If-Match header defined in section 14.24 of RFC2616 [7].  However
   the If header is intended for use with any
   method other than URI which represents state
   information, referred to as a LOCK method.

   Timeout response values MUST use state token, about a Second value or Infinite.

   The "Second" TimeType specifies the number of seconds that will
   elapse between granting resource as well
   as ETags.  A typical example of the a state token is a lock at the server, token, and
   lock tokens are the automatic
   removal of the lock. only state tokens defined in this specification.
   The timeout value for TimeType "Second" MUST
   NOT be greater than 2^32-1. <DAV:no-lock> state token is a special token that must never
   match an actual valid lock token.  The timeout counter MUST be restarted if purpose of this is described
   in section 9.5.5.

   The If header's purpose is to describe a refresh LOCK request series of state lists.  If
   the state of the resource to which the header is
   successful.  The timeout counter SHOULD NOT be restarted at applied does not
   match any other
   time.

   If of the timeout expires specified state lists then the lock may be lost.  Specifically, if request MUST fail
   with a 412 (Precondition Failed).  If one of the server wishes to harvest described state
   lists matches the lock upon time-out, state of the server
   SHOULD act as if an UNLOCK method was executed by resource then the request may succeed.

   The server must parse the If header when it appears on any request,
   evaluate all the
   resource using clauses, and if the lock token of conditional evaluates to false,
   fail the timed-out lock, performed with
   its override authority.  Thus logs should be updated with request.

   Note that the
   disposition of absoluteURI production is defined in RFC2396 [5].

   RFC2518 originally defined the lock, notifications should be sent, etc., just as
   they would If header without comma separators.
   This oversight meant that the If header couldn't be for an UNLOCK request.

   Servers are advised divided up among
   multiple lines according to pay close attention the HTTP header manipulation rules.
   Servers supporting "bis" MUST be able to accept commas in If header
   values.  If the values submitted by
   clients, as they will header has commas between tokens or clauses, the
   header can be indicative of evaluated simply by removing the type of activity commas and proceeding
   with the
   client intends to perform.  For example, an applet running in a
   browser may need to lock evaluation rules.

9.5.1  No-tag-list Production

   The No-tag-list production describes a resource, but because series of state tokens and
   ETags.  If multiple No-tag-list productions are used then one only
   needs to match the instability state of the environment within which the applet is running, resource for the applet may method to be turned off without warning.  As a result, the applet is likely allowed
   to continue.  All untagged tokens apply to
   ask for a relatively small timeout value so that if the applet dies, resource identified in
   the lock can be quickly harvested.  However, a document management
   system is likely to ask for Request-URI.

   Example - no-tag-list production

      If: (<opaquelocktoken:a-write-lock-token> ["I am an extremely long timeout because its
   user may be planning on going off-line.

   A client MUST NOT assume ETag"]), (["I
      am another ETag"])

   The previous header would require that just because the time-out has expired the lock has been lost.  Likewise, a client MUST NOT assume that just
   because resource identified in the time-out has not expired,
   Request-URI be locked with the specified lock still exists (and for
   this reason, clients are strongly advised to use ETags as well).

10.  Status Code Extensions to HTTP/1.1

   The following status codes are added to those defined token and in HTTP/1.1
   RFC2616 [8].

10.1  102 Processing

   The 102 (Processing) status code is the state
   identified by the "I am an interim response used to
   inform ETag" ETag or in the client that state identified by
   the server has accepted second ETag "I am another ETag".  To put the complete request,
   but has not yet completed it.  This status code SHOULD only matter more plainly
   one can think of the previous If header as being in the form (or (and
   <opaquelocktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am
   another ETag"])).

9.5.2  Tagged-list Production

   The tagged-list production may be sent
   when used instead of the server has no-tag-list
   production, in order to scope each token to a reasonable expectation specific resource.
   That is, it specifies that the request will
   take significant time to complete.  As guidance, if a method is
   taking longer than 20 seconds (a reasonable, but arbitrary value) lists following the resource
   specification only apply to
   process the server SHOULD return a 102 (Processing) response. specified resource.  The
   server MUST send a final response after the request has been
   completed.

   Methods can potentially take a long period scope of time to process,
   especially methods that support the Depth header.  In such cases
   resource production begins with the
   client may time-out list production immediately
   following the connection while waiting for a response.  To
   prevent this resource production and ends with the server may return a 102 (Processing) status code to
   indicate to next resource
   production, if any.  All clauses must be evaluated.  If the client that state of
   the server is still processing resource named in the
   method.

10.2  207 Multi-Status

   The 207 (Multi-Status) status code provides status for multiple
   independent operations (see Section 12 for more information).

10.3  422 Unprocessable Entity tag does not match any of the associated
   state lists then the request MUST fail with a 412 (Precondition
   Failed).  The 422 (Unprocessable Entity) status code means tagged-list production MUST NOT be used together with
   the server
   understands no-tag-list production, either in the content type of same If header or in a
   continuation.

   The same URI MUST NOT appear more than once in a resource production
   in an If header.

   Example - Tagged List If header

        COPY /resource1 HTTP/1.1
        Host: www.example.com
        Destination: http://www.example.com/resource2
        If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
        token> [W/"A weak ETag"]), (["strong ETag"]),
        <http://www.bar.bar/random>(["another strong ETag"])

   In this example http://www.example.com/resource1 is being copied to
   http://www.example.com/resource2.  When the request entity (hence a
   415(Unsupported Media Type) status code method is inappropriate), and first applied
   to http://www.example.com/resource1, resource1 must be in the
   syntax state
   specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
   (["strong ETag"])", that is, it either must be locked with a lock
   token of the request "locktoken:a-write-lock-token" and have a weak entity is correct (thus tag
   W/"A weak ETag" or it must have a 400 (Bad Request)
   status code strong entity tag "strong ETag".

   That is inappropriate) but was unable to process the contained
   instructions.  For example, this error only success condition may occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous XML instructions.

10.4  423 Locked

   The 423 (Locked) status code means since the source or destination resource
   of a
   http://www.bar.bar/random never has the method is locked.  This response SHOULD contain applied to it (the
   only other resource listed in the
   'missing-lock-token' element If header) and corresponding href
   http://www.example.com/resource2 is not listed in the error
   body.

10.5  424 Failed Dependency

   The 424 (Failed Dependency) status code means that If header.

9.5.3  Not Production

   Every state token or ETag is either current, and hence describes the method could
   state of a resource, or is not be performed on current, and does not describe the resource because
   state of a resource.  The boolean operation of matching a state token
   or ETag to the requested action
   depended on another action and current state of a resource thus resolves to a true or
   false value.  The "Not" production is used to reverse that action failed.  For example, if a
   command in a PROPPATCH method fails then, at minimum, the rest value.
   The scope of the
   commands will also fail with 424 (Failed Dependency).

10.6  507 Insufficient Storage

   The 507 (Insufficient Storage) status code means not production is the method could state-token or entity-tag
   immediately following it.

        If: (Not <locktoken:write1> <locktoken:write2>)

   When submitted with a request, this If header requires that all
   operand resources must not be performed on the resource because the server locked with locktoken:write1 and must
   be locked with locktoken:write2.

   The Not production is unable to store particularly useful with the representation needed "<DAV:no-lock>"
   state token.  The clause "Not <DAV:no-lock>" must evaluate to successfully complete true.
   Thus, any "OR" statement containing the request.  This
   condition is considered clause "Not <DAV:no-lock>"
   must also evaluate to be temporary. true.

9.5.4  Matching Function

   When performing If header processing, the request which
   received this status code was the result definition of a user action, the
   request MUST NOT be repeated until it matching
   state token or entity tag is requested by as follows.

   Identifying a separate user
   action.

11.  Use of HTTP Status Codes

11.1  301 Moved Permanently

   Any WebDAV request may be redirected using this status code.

11.2  302 Found

   Any WebDAV request may be redirected using this status code.

11.3  400 Bad Request

   This code may be used if:

   o resource:  The resource is identified by the Host header URI along
   with the token, in tagged list production, or by the Request-URI in
   untagged list production.

   Matching entity tag: Where the entity tag matches an entity tag
   associated with the identified resource.

   Matching state token: Where there is missing an exact match between the state
   token in any request
   o  The protocol version is HTTP/1.0
   o  Any the If header and any state token on the identified
   resource.  A lock state token is improperly formatted
   o  The request method line is improperly formatted

11.4  403 Forbidden

   To be used considered to match if the server does not ever accept this method on this
   kind resource
   is anywhere in the scope of resource. the lock.

   Example - Matching lock tokens with collection locks

    DELETE /specs/rfc2518.txt HTTP/1.1
    Host: www.example.com
    If: <http://www.example.com/specs/> (<locktoken:a-write-lock-token>)

   For this example, if a PUT the lock token must be compared to the identified
   resource, which is the 'specs' collection identified by the URL in
   the tagged list production.  If the 'specs' collection is not accepted on locked
   or has a
   collection.

11.5  409 Conflict

   The 409 Conflict is most typically returned when lock with a method different token, the request MUST fail.  If the
   'specs' collection is locked (depth infinity) with that
   attempts lock token,
   then this request could succeed, both because the If header evaluates
   to create a new resource must fail, true, and because one of the
   collections that lock token for the lock affecting the
   affected resource depends on does not exist.  However, other
   types of conflicts are defined in specifications extending RFC2518.
   Therefore, this can be returned in response to all methods.

11.6  414 Request-URI Too Long

   This status code has been provided.  Alternatively, a request where
   the 'rfc2518.txt' URL is used associated with the lock token in the If
   header could also succeed.

9.5.5  If Header and Non-DAV Aware Proxies

   Non-DAV aware proxies will not honor the If header, since they will
   not understand the If header, and HTTP 1.1 only for Request-URIs, because
   full URIs arenȔt requires non-understood
   headers to be ignored.  When communicating with HTTP/1.1 proxies, the
   "Cache-Control: no-cache" request header MUST be used in other headers.  WebDAV specifies full URLs
   in other headers, therefore this error may so as to
   prevent the proxy from improperly trying to service the request from
   its cache.  When dealing with HTTP/1.0 proxies the "Pragma: no-
   cache" request header MUST be used if for the URI same reason.

9.6  Lock-Token Header

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

   The Lock-Token request header is too
   long in other locations as well.  This status code may be used in
   response to any with the UNLOCK method in this specification.

12.  Multi-Status Response to
   identify the lock to be removed.  The default 207 (Multi-Status) response body is lock token in the Lock-Token
   request header MUST identify a text/xml or
   application/xml HTTP entity lock that contains the resource
   identified by Request-URI as a single XML element called
   multistatus, which contains a set of XML elements called member.

   The Lock-Token response
   which contain 200, 300, 400, and 500 series status codes generated
   during header is used with the LOCK method invocation.  100 series status codes SHOULD NOT be
   recorded in to
   indicate the lock token created as a response XML element.  The 207 status code itself MUST
   NOT be considered result of a success response, it is only completely successful if all response elements inside contain success status
   codes. LOCK
   request to create a new lock.

9.7  Overwrite Header

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

   The body Overwrite request header specifies whether the server should
   overwrite the state of a 207 Multi-Status response MUST contain non-null destination resource during a URL associated
   with each specific status code, so COPY
   or MOVE.  A value of "F" states that the client can tell whether server must not perform the error occurred with
   COPY or MOVE operation if the state of the source resource, destination resource is
   non-null.  If the overwrite header is not included in a COPY or
   some other MOVE
   request then the resource in MUST treat the scope request as if it has an
   overwrite header of value "T".  While the request.  URLs for
   collections appearing in Overwrite header appears to
   duplicate the results SHOULD end in functionality of the If-Match: * header of HTTP/1.1,
   If-Match applies only to the Request-URI, and not to the Destination
   of a '/' character.

   When COPY or MOVE.

   If a Multi-Status body COPY or MOVE is returned in response not performed due to a PROPFIND or
   another request the value of the Overwrite
   header, the method MUST fail with a single scope, all URLs appearing 412 (Precondition Failed) status
   code.

   All DAV compliant resources MUST support the Overwrite header.

9.8  Timeout Request Header

      TimeOut = "Timeout" ":" 1#TimeType
      TimeType = ("Second-" DAVTimeOutVal | "Infinite")
      DAVTimeOutVal = 1*digit

   Clients may include Timeout request headers in their LOCK requests.
   However, the body
   must be equal server is not required to honor or inside even consider these
   requests.  Clients MUST NOT submit a Timeout request header with any
   method other than a LOCK method.

   Timeout response values MUST use a Second value or Infinite.

   The "Second" TimeType specifies the number of seconds that will
   elapse between granting of the request-URI, thus lock at the URLs MAY server, and the automatic
   removal of the lock.  The timeout value for TimeType "Second" MUST
   NOT be
   absolute or MAY greater than 2^32-1.

   The timeout counter MUST be relative.

   o restarted if a refresh LOCK request is
   successful.  The timeout counter SHOULD NOT be restarted at any other
   time.

   If the URLs are absolute, timeout expires then the lock may be lost.  Specifically, if
   the server MUST ensure that wishes to harvest the
      URLs have lock upon time-out, the same prefix (scheme, host, port, and path) server
   SHOULD act as if an UNLOCK method was executed by the
      URL of server on the requested
   resource (which may be using the same as lock token of the
      Request-URI or may timed-out lock, performed with
   its override authority.  Thus logs should be updated with the corrected in the response Location
      header).
   o  If
   disposition of the URLs are relative, they MUST lock, notifications should be resolved against the
      Location header, if present, or sent, etc., just as second choice against the
      Request-URI.

   When a Multi-Status body is returned in response to MOVE or COPY,
   relative URIs resolution is ambiguous (the request had both a source
   and a destination URL).  Thus, URLs appearing in the responses to
   MOVE or COPY SHOULD
   they would be absolute and fully-qualified URLs.

12.1  Responses requiring Location in Multi-Status

   The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take
   a Location header for an UNLOCK request.

   Servers are advised to pay close attention to indicate where the client should make the
   request.  The Multi-Status response syntax values submitted by
   clients, as defined in RFC2518 did
   not allow for they will be indicative of the Location header information type of activity the
   client intends to be included in perform.  For example, an
   unambiguous way, so servers MAY choose not to use these status codes applet running in Multi-Status responses.  If a clients receives this status code in
   Multi-Status,
   browser may need to lock a resource, but because of the client MAY reissue instability
   of the request to environment within which the individual
   resource, so that applet is running, the server can issue a response with a Location
   header for each resource.

   Additionally, this specification defines applet may
   be turned off without warning.  As a new element that servers
   MAY use in result, the response element applet is likely to provide
   ask for a location relatively small timeout value in
   Multi-Status (see Section 13.29).

13.  XML Element Definitions

   In this section, the final line of each section gives so that if the element
   type declaration using applet dies,
   the format defined in XML [11].  The "Value"
   field, where present, specifies further restrictions lock can be quickly harvested.  However, a document management
   system is likely to ask for an extremely long timeout because its
   user may be planning on going off-line.

   A client MUST NOT assume that just because the allowable
   contents of the XML element using BNF (i.e., to further restrict time-out has expired
   the
   values of lock has been lost.  Likewise, a PCDATA element).  The "Extensibility" field discusses how client MUST NOT assume that just
   because the element may be extended in time-out has not expired, the future (or lock still exists (and for
   this reason, clients are strongly advised to use ETags as well).

10.  Status Code Extensions to HTTP/1.1

   The following status codes are added to those defined in existing extensions HTTP/1.1
   RFC2616 [7].

10.1  102 Processing

   The 102 (Processing) status code is an interim response used to WebDAV.

   All of
   inform the elements defined here may be extended by client that the addition of
   attributes and child elements server has accepted the complete request,
   but has not defined in this specification.

13.1  activelock XML Element

   Name:  activelock
   Namespace:  DAV:
   Purpose:  Describes a lock on a resource.
   Extensibility:  MAY be extended with additional child elements or
      attributes which yet completed it.  This status code SHOULD only be ignored if not recognized.

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?, lockroot)>

13.2  depth XML Element

   Name:  depth
   Namespace:  DAV:
   Purpose:  The value of sent
   when the Depth header.
   Value:  "0" | "1" | "infinity"
   Extensibility:  MAY be extended with attributes which SHOULD be
      ignored.

   <!ELEMENT depth (#PCDATA) >

13.3  locktoken XML Element

   Name:  locktoken
   Namespace:  DAV:
   Purpose:  The lock token associated with server has a lock.
   Description:  The href contains reasonable expectation that the request will
   take significant time to complete.  As guidance, if a single lock token URI which refers method is
   taking longer than 20 seconds (a reasonable, but arbitrary value) to
   process the lock (i.e., the OpaqueLockToken-URI production in section
      6.4).
   Extensibility:  MAY be extended with additional child elements or
      attributes which server SHOULD be ignored if not recognized.

   <!ELEMENT locktoken (href) >

13.4  lockroot XML Element

   Name:  lockroot
   Namespace:  DAV:
   Purpose:  Contains return a 102 (Processing) response.  The
   server MUST send a final response after the root URL request has been
   completed.

   Methods can potentially take a long period of time to process,
   especially methods that support the lock, which is the URL through
      which Depth header.  In such cases the resource was addressed in
   client may time-out the LOCK request.
   Description:  The href contains connection while waiting for a URL with response.  To
   prevent this the address of server may return a 102 (Processing) status code to
   indicate to the root of client that the lock.  The server SHOULD include this in all lockdiscovery
      property values and is still processing the response to LOCK requests.
   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT lockroot (href) >

13.5  timeout XML Element

   Name:  timeout
   Namespace:  DAV:
   Purpose:
   method.

10.2  207 Multi-Status

   The number of seconds remaining before a lock expires.
   Value:  TimeType (defined in 207 (Multi-Status) status code provides status for multiple
   independent operations (see Section 9.8).
   Extensibility:  MAY be extended with attributes which SHOULD be
      ignored.

   <!ELEMENT timeout (#PCDATA) >

13.6  collection XML Element

   Name:  collection
   Namespace:  DAV:
   Purpose:  Identifies the associated resource as a collection. 12 for more information).

10.3  422 Unprocessable Entity

   The
      resourcetype property of a collection resource MUST contain this
      element.  It is normally empty but extensions may add
      sub-elements.
   Extensibility:  MAY be extended with child elements or attributes
      which SHOULD be ignored if not recognized.

   <!ELEMENT collection EMPTY >

13.7  href XML Element

   Name:  href
   Namespace:  DAV:
   Purpose:  Identifies 422 (Unprocessable Entity) status code means the server
   understands the content type of the element as a URI.  In many
      situations, this URI MUST be a HTTP URI, and furthermore, it MUST
      identify request entity (hence a WebDAV resource.  There
   415(Unsupported Media Type) status code is one exception to this
      general rule in inappropriate), and the lockdiscovery property, where
   syntax of the lock token
      (which request entity is correct (thus a URI 400 (Bad Request)
   status code is inappropriate) but was unable to process the contained
   instructions.  For example, this error condition may not be occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous XML instructions.

10.4  423 Locked

   The 423 (Locked) status code means the source or destination resource
   of a HTTP URI) method is inside the href
      element.  Other specifications locked.  This response SHOULD be explicit if contain the href 'missing-
   lock-token' element is to contain non-HTTP URIs.
   Value:  URI (See section 3.2.1 of RFC2616 [8])
   Extensibility:  MAY be extended with attributes which SHOULD be
      ignored.

   <!ELEMENT and corresponding href (#PCDATA)>

13.8  lockentry XML Element

   Name:  lockentry
   Namespace:  DAV:
   Purpose:  Defines in the types of locks error body.

10.5  424 Failed Dependency

   The 424 (Failed Dependency) status code means that can be used with the
      resource.
   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD method could
   not be ignored performed on the resource because the requested action
   depended on another action and that action failed.  For example, if not recognized.

   <!ELEMENT lockentry (lockscope, locktype) >

13.9  lockinfo XML Element

   Name:  lockinfo
   Namespace:  DAV:
   Purpose: a
   command in a PROPPATCH method fails then, at minimum, the rest of the
   commands will also fail with 424 (Failed Dependency).

10.6  507 Insufficient Storage

   The lockinfo XML element 507 (Insufficient Storage) status code means the method could not
   be performed on the resource because the server is used with a LOCK method unable to
      specify store
   the type of lock representation needed to successfully complete the client wishes request.  This
   condition is considered to have created.
   Extensibility:  MAY be extended with additional child elements or
      attributes temporary.  If the request which SHOULD be ignored if not recognized.

   <!ELEMENT lockinfo (lockscope, locktype, owner?)  >

13.10  lockscope XML Element

   Name:  lockscope
   Namespace:  DAV:
   Purpose:  Specifies whether a lock is an exclusive lock, or
   received this status code was the result of a shared
      lock.
   Extensibility:  SHOULD user action, the
   request MUST NOT be extended with child elements.  MAY repeated until it is requested by a separate user
   action.

11.  Use of HTTP Status Codes

   These HTTP codes are not redefined, but this section serves as a
   reminder that these HTTP codes may be
      extended with attributes which SHOULD used in responses to WebDAV
   methods and clients must be ignored.

   <!ELEMENT lockscope (exclusive | shared) >

13.11  exclusive XML Element

   Name:  exclusive
   Namespace:  DAV:
   Purpose:  Specifies an exclusive lock
   Extensibility:  Normally empty, but MAY appropriately prepared to handle them.

11.1  301 Moved Permanently

   Any WebDAV request may be extended with additional
      child elements or attributes which SHOULD redirected using this status code.

11.2  302 Found

   Any WebDAV request may be ignored if not
      recognized.

   <!ELEMENT exclusive EMPTY >

13.12  shared XML Element

   Name:  shared
   Namespace:  DAV:
   Purpose:  Specifies a shared lock
   Extensibility:  Normally empty, but MAY redirected using this status code.

11.3  400 Bad Request

   This code may be extended with additional
      child elements or attributes which SHOULD used if:

   o  the Host header is missing in any request

   o  The protocol version is HTTP/1.0

   o  Any header is improperly formatted

   o  The request method line is improperly formatted

11.4  403 Forbidden

   To be ignored used if not
      recognized.

   <!ELEMENT shared EMPTY >

13.13  locktype XML Element

   Name:  locktype
   Namespace:  DAV:
   Purpose:  Specifies the access type server does not ever accept this method on this
   kind of resource.  For example, if a lock.  At present, this
      specification only defines PUT is not accepted on a
   collection.

11.5  409 Conflict

   The 409 Conflict is most typically returned when a method that
   attempts to create a new resource must fail, because one lock type, of the write lock.
   Extensibility:  MAY
   collections that resource depends on does not exist.  However, other
   types of conflicts are defined in specifications extending RFC2518.
   Therefore, this can be extended with additional child elements returned in response to all methods.

11.6  412 Precondition Failed

   Any request may contain a conditional header defined in HTTP (If-
   Match, If-Modified-Since, etc.) or
      attributes which SHOULD the "If" conditional header
   defined in this specification.  If the request contains a conditional
   header, and if that condition fails to hold, then this error code may
   be ignored returned.  This status code is not typically appropriate if the
   client did not recognized.

   <!ELEMENT locktype (write) >

13.14  write XML Element

   Name:  write
   Namespace:  DAV:
   Purpose:  Specifies include a write lock.
   Extensibility:  Normally empty, but MAY be extended with additional
      child elements or attributes which SHOULD conditional header in the request.

11.7  414 Request-URI Too Long

   This status code is used in HTTP 1.1 only for Request-URIs, because
   full URIs arenit used in other headers.  WebDAV specifies full URLs
   in other headers, therefore this error may be ignored used if not
      recognized.

   <!ELEMENT write EMPTY >

13.15  multistatus XML Element

   Name:  multistatus
   Namespace:  DAV:
   Purpose:  Contains multiple response messages.
   Description The responsedescription at the top level URI is too
   long in other locations as well.  This status code may be used in
   response to
      provide a general message describing the overarching nature of the
      response.  If any method in this value specification.

11.8  503 Service Unavailable

   This status code is available an application may use it
      instead of presenting particularly useful to respond to requests that
   the individual server considers a denial-of-service attack, such as excessively
   large PROPFIND depth infinity requests or requests in quick
   succession.

12.  Multi-Status Response

   The default 207 (Multi-Status) response descriptions
      contained within the responses.
   Extensibility:  MAY be extended with additional child elements body is a text/xml or
      attributes
   application/xml HTTP entity that contains a single XML element called
   multistatus, which contains a set of XML elements called response
   which contain 200, 300, 400, and 500 series status codes generated
   during the method invocation. 100 series status codes SHOULD NOT be ignored if not recognized.

   <!ELEMENT multistatus (response+, responsedescription?)  >

13.16
   recorded in a response XML Element

   Name:  locktype
   Namespace:  DAV:
   Purpose:  Holds element.  The 207 status code itself MUST
   NOT be considered a single success response, it is only completely
   successful if all response describing the effect elements inside contain success status
   codes.

   The body of a method
      on resource and/or its properties.
   Description:  A particular href 207 Multi-Status response MUST NOT appear more than once as contain a URL associated
   with each specific status code, so that the client can tell whether
   the error occurred with the source resource, destination resource or
   some other resource in the
      child scope of the request.  URLs for
   collections appearing in the results SHOULD end in a response XML element under '/' character.

   When a multistatus XML element.
      This requirement Multi-Status body is necessary returned in order to keep processing costs
      for a response to linear time.  Essentially, this prevents having
      to search a PROPFIND or
   another request with a single scope, all URLs appearing in order the body
   must be equal to group together all or inside the responses by href.
      There are, however, no requirements regarding ordering based on
      href values.
   Extensibility: request-URI, thus the URLs MAY be extended with additional child elements
   absolute or
      attributes which SHOULD MAY be ignored if not recognized.

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription? , location?) >

13.17  propstat XML Element

   Name:  propstat
   Namespace:  DAV:
   Purpose:  Groups together a prop and status element that is
      associated with a particular href element.
   Description:   The propstat XML element relative.

   o  If the URLs are absolute, then the server MUST contain one prop XML
      element ensure that the
      URLs have the same prefix (scheme, host, port, and one status XML element.  The contents path) as the
      URL of the prop XML
      element requested resource (which may be the same as the
      Request-URI or may be the corrected in the response Location
      header).

   o  If the URLs are relative, they MUST only list be resolved against the names of properties to which
      Location header, if present, or as second choice against the result
      Request-URI.

   When a Multi-Status body is returned in response to MOVE or COPY,
   relative URIs resolution is ambiguous (the request had both a source
   and a destination URL).  Thus, URLs appearing in the status element applies.
   Extensibility:  MAY be extended with additional child elements responses to
   MOVE or
      attributes which COPY SHOULD be ignored if not recognized.

   <!ELEMENT propstat (prop, status, responsedescription?) >

13.18  status XML Element

   Name:  status
   Namespace:  DAV:
   Purpose:  Holds a single HTTP status-line
   Value:  status-line (status-line absolute and fully-qualified URLs.

12.1  Responses requiring Location in Multi-Status

   The 300-303, 305 and 307 responses defined in RFC2616 [8]
   Extensibility:  MAY be extended with attributes which SHOULD be
      ignored.

   <!ELEMENT status (#PCDATA) >

13.19  responsedescription XML Element

   Name:  responsedescription
   Namespace:  DAV:
   Purpose:  Contains HTTP 1.1 normally take
   a message that can be displayed Location header to indicate where the user
      explaining client should make the nature of
   request.  The Multi-Status response syntax as defined in RFC2518 did
   not allow for the response.
   Description:  This XML element provides Location header information suitable to be
      presented included in an
   unambiguous way, so servers MAY choose not to use these status codes
   in Multi-Status responses.  If a user.
   Extensibility: clients receives this status code in
   Multi-Status, the client MAY be extended reissue the request to the individual
   resource, so that the server can issue a response with attributes which SHOULD be
      ignored.

   <!ELEMENT responsedescription (#PCDATA) >

13.20  owner a Location
   header for each resource.

   Additionally, this specification defines a new element that servers
   MAY use in the response element to provide a location value in Multi-
   Status (see Section 13.29).

13.  XML Element

   Name:  owner
   Namespace:  DAV:
   Purpose:  Provides information about Definitions

   In this section, the principal taking out a lock.
   Description final line of each section gives the element
   type declaration using the format defined in XML [11].  The owner "Value"
   field, where present, specifies further restrictions on the allowable
   contents of the XML element provides information sufficient for
      either directly contacting a principal (such as a telephone number
      or Email URI), or for discovering the principal (such as using BNF (i.e., to further restrict the URL
   values of a homepage) who owns a lock.  This information is provided by PCDATA element).  The "Extensibility" field discusses how
   the client, and element may only be altered by the server if extended in the owner
      value provided by future (or in existing extensions
   to WebDAV.

   All of the client is empty.
   Extensibility MAY elements defined here may be extended with child elements, mixed content,
      text content or attributes.  Structured content, for example one
      or more <href> by the addition of
   attributes and child elements containing URLs, is RECOMMENDED.

   <!ELEMENT owner ANY

13.21  prop not defined in this specification.

13.1  activelock XML element Element

   Name:  prop  activelock

   Namespace:  DAV:

   Purpose:  Contains properties related to a resource.
   Description The prop XML element is  Describes a generic container for
      properties defined lock on resources.  All elements inside a prop XML
      element MUST define properties related to the resource.  No other
      elements may be used inside of a prop element.

   Extensibility

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.  Any child element

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?, lockroot)>

13.2  depth XML Element

   Name:  depth

   Namespace:  DAV:

   Purpose:  The value of this element must the Depth header.

   Value:  "0" | "1" | "infinity"

   Extensibility:  MAY be
      considered to extended with attributes which SHOULD be a property name, however these are not restricted
      to the property names defined in this document or other standards.
      ignored.

   <!ELEMENT prop ANY

13.22  propertyupdate depth (#PCDATA) >

13.3  locktoken XML element Element
   Name:  propertyupdate  locktoken

   Namespace:  DAV:

   Purpose:  Contains a request to alter the properties on  The lock token associated with a resource. lock.

   Description:  This XML element is  The href contains a container for the information
      required single lock token URI which refers
      to modify the properties on lock (i.e., the resource.  This XML
      element is multi-valued. OpaqueLockToken-URI production in section
      6.4).

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT propertyupdate (remove | set)+ locktoken (href) >

13.23  remove

13.4  lockroot XML element Element

   Name:  remove  lockroot

   Namespace:  DAV:

   Purpose:  Lists the DAV properties to be removed from a resource.
   Description:  Remove instructs that the properties specified in prop
      should be removed.  Specifying  Contains the removal root URL of a property that does
      not exist the lock, which is not an error.  All the XML elements URL through
      which the resource was addressed in the LOCK request.

   Description:  The href contains a prop XML
      element inside URL with the address of a remove XML element MUST be empty, as only the
      names root of properties
      the lock.  The server SHOULD include this in all lockdiscovery
      property values and the response to be removed are required. LOCK requests.

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT remove (prop) lockroot (href) >

13.24  set

13.5  timeout XML element Element

   Name:  set  timeout

   Namespace:  DAV:

   Purpose:  Lists the DAV property values to be set for a resource.
   Description:  The set XML element MUST contain only a prop XML
      element.  The elements contained by the prop XML element inside
      the set XML element MUST specify the name and value number of properties
      that are set on seconds remaining before a lock expires.

   Value:  TimeType (defined in Section 9.8).

   Extensibility:  MAY be extended with attributes which SHOULD be
      ignored.

      <!ELEMENT timeout (#PCDATA) >

13.6  collection XML Element

   Name:  collection

   Namespace:  DAV:

   Purpose:  Identifies the associated resource identified by Request-URI.  If as a collection.  The
      resourcetype property already exists then its value is replaced.  Language
      tagging information appearing in the scope of the prop element (in
      the "xml:lang" attribute, if present) MUST be persistently stored
      along with the property, and a collection resource MUST be subsequently retrievable
      using PROPFIND. contain this
      element.  It is normally empty but extensions may add sub-
      elements.

   Extensibility:  MAY be extended with additional child elements or attributes
      which SHOULD be ignored if not recognized.

   <!ELEMENT set (prop) collection EMPTY >

13.25  propfind

13.7  href XML Element

   Name:  propfind  href

   Namespace:  DAV:

   Purpose:  Specifies  Identifies the properties to content of the element as a URI.  In many
      situations, this URI MUST be returned from a PROPFIND
      method.  Four special elements are specified for use with
      propfind: prop, dead-props, allprop HTTP URI, and propname.  If prop is used
      inside propfind furthermore, it MUST NOT
      identify a WebDAV resource.  There is one exception to this
      general rule in the lockdiscovery property, where the lock token
      (which is a URI but may not be a HTTP URI) is inside the href
      element.  Other specifications SHOULD be explicit if the href
      element is to contain property values. non-HTTP URIs.

   Value:  URI (See section 3.2.1 of RFC2616 [7])

   Extensibility:  MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized, as long as
      it still contains one of the required elements.
      ignored.

      <!ELEMENT propfind (prop | dead-props | propname | allprop) >

13.26  allprop href (#PCDATA)>

13.8  lockentry XML Element

   Name:  allprop  lockentry

   Namespace:  DAV:

   Purpose:  The allprop XML element specifies that all names and values
      of dead properties and the live properties defined by this
      document existing on  Defines the resource are to types of locks that can be returned. used with the
      resource.

   Extensibility:  Normally empty, but  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT allprop EMPTY lockentry (lockscope, locktype) >

13.27  propname

13.9  lockinfo XML Element

   Name:  propname  lockinfo

   Namespace:  DAV:

   Purpose:  The propname lockinfo XML element specifies that only is used with a list LOCK method to
      specify the type of
      property names on lock the resource is client wishes to be returned. have created.

   Extensibility:  Normally empty, but  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT propname EMPTY lockinfo (lockscope, locktype, owner?)  >

13.28  dead-props

13.10  lockscope XML Element

   Name:  dead-props  lockscope

   Namespace:  DAV:

   Purpose:  The dead-props XML element specifies that all dead
      properties, names and values, should be returned in the response.  Specifies whether a lock is an exclusive lock, or a shared
      lock.

   Extensibility:  Normally empty, but MAY  SHOULD NOT be extended with additional child elements or elements.  MAY be
      extended with attributes which SHOULD be ignored if not
      recognized. ignored.

     <!ELEMENT dead-props EMPTY lockscope (exclusive | shared) >

13.29  location

13.11  exclusive XML Element
   Name:  location  exclusive

   Namespace:  DAV:

   Purpose:  In normal responses (not Multi-Status), some status codes
      go along with a Location header.  When these status codes are used
      in a Multi-Status response, this element is used instead.
   Description:  Contains a single href element with the same URI that
      would be used in a Location header.  Specifies an exclusive lock

   Extensibility:  Normally empty, but MAY be extended with additional
      child elements or attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT location (href) exclusive EMPTY >

13.30  error

13.12  shared XML Element

   Name:  error  shared

   Namespace:  DAV:

   Purpose:  Error responses, particularly 403 Forbidden and 409
      Conflict, sometimes need more information to indicate what went
      wrong.  When an error response contains a body in WebDAV, the body
      is in XML with the root element 'error'.  The 'error' tag SHOULD
      include a standard error tag defined in this specification or
      another specification.  The 'error' tag MAY include custom error
      tags (in custom namespaces) which a client can safely ignore.
   Description:  Contains any XML element  Specifies a shared lock

   Extensibility:  Fully extensible  Normally empty, but MAY be extended with additional
      child elements or attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT error ANY shared EMPTY >

14.  DAV Properties

   For DAV properties, the name of the property is also the same as the
   name of the

13.13  locktype XML element that contains its value.  In the section
   below, the final line of each section gives Element

   Name:  locktype

   Namespace:  DAV:

   Purpose:  Specifies the element access type
   declaration using the format defined in XML [11].  The "Value" field,
   where present, specifies further restrictions on the allowable
   contents of the XML element using BNF (i.e., to further restrict the
   values of a PCDATA element).  Note that a resource may have lock.  At present, this
      specification only defines one
   value for a property of a given name, so lock type, the property may only show
   up once in PROPFIND responses write lock.

   Extensibility:  MAY be extended with additional child elements or PROPPATCH requests.

   Some property values are calculated by the server and it is not
   appropriate to allow client changes, thus they are protected.
   Existing server implementations already have different sets of
   RFC2518 properties protected, but clients can have some expectations
      attributes which properties are normally protected.  The value of a protected
   property may not SHOULD be changed even by ignored if not recognized.

   <!ELEMENT locktype (write) >

13.14  write XML Element

   Name:  write

   Namespace:  DAV:

   Purpose:  Specifies a user write lock.

   Extensibility:  Normally empty, but MAY be extended with permission to edit
   other properties. additional
      child elements or attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT write EMPTY >

13.15  multistatus XML Element

   Name:  multistatus

   Namespace:  DAV:

   Purpose:  Contains multiple response messages.

   Description The value responsedescription at the top level is used to
      provide a general message describing the overarching nature of the
      response.  If this value is available an unprotected property application may use it
      instead of presenting the individual response descriptions
      contained within the responses.

   Extensibility:  MAY be
   changed by some users extended with appropriate permissions.

14.1  creationdate Property additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT multistatus (response+, responsedescription?)  >

13.16  response XML Element

   Name:  creationdate  locktype

   Namespace:  DAV:

   Purpose:  Records the time and date  Holds a single response describing the effect of a method
      on resource was created.
   Value:  date-time (defined in RFC3339 [9], see the ABNF in section
      5.6.)
   Protected:  MAY be protected.  Some servers allow creationdate to be
      changed to reflect the time the document was created if that is and/or its properties.

   Description:  A particular href MUST NOT appear more meaningful to the user (rather than once as the time it was
      uploaded).  Thus, clients SHOULD NOT use this property in
      synchronization logic (use getetag instead).
   COPY/MOVE behaviour:  This property value SHOULD be kept during
      child of a
      MOVE operation, but is normally re-initialized when response XML element under a resource multistatus XML element.
      This requirement is
      created with a COPY.  It should not be set necessary in order to keep processing costs
      for a COPY.
   Description:  The creationdate property should be defined on response to linear time.  Essentially, this prevents having
      to search in order to group together all DAV
      compliant resources.  If present, it contains a timestamp of the
      moment when the resource was created (i.e., the moment it had
      non-null state). responses by href.
      There are, however, no requirements regarding ordering based on
      href values.

   Extensibility:  MAY contain be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT creationdate (#PCDATA) response (href, ((href*, status)|(propstat+)),
         responsedescription? , location?) >

14.2  displayname Property

13.17  propstat XML Element

   Name:  displayname  propstat

   Namespace:  DAV:

   Purpose:  Provides  Groups together a name for the resource prop and status element that is suitable for
      presentation to a user.
   Value:  Any text
   Protected:  Possibly
   COPY/MOVE behaviour:  This property value SHOULD be preserved in
      local COPY and MOVE operations.  It MAY be attempted to be set in
      a COPY operation to
      associated with a remote server. particular href element.

   Description:   The displayname property should be defined on all DAV
      compliant resources.  If present, the property contains a
      description propstat XML element MUST contain one prop XML
      element and one status XML element.  The contents of the resource that is suitable for presentation prop XML
      element MUST only list the names of properties to a
      user. which the result
      in the status element applies.

   Extensibility:  MAY contain be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT displayname (#PCDATA) propstat (prop, status, responsedescription?) >

14.3  getcontentlanguage Property

13.18  status XML Element

   Name:  getcontentlanguage  status

   Namespace:  DAV:

   Purpose:  Contains the Content-Language header returned by  Holds a GET
      without accept headers single HTTP status-line

   Value:  language-tag (language-tag is  status-line (status-line defined in section 14.13 of RFC2616 [8])
   Protected: [7]

   Extensibility:  MAY be extended with attributes which SHOULD NOT be protected, so
      ignored.

   <!ELEMENT status (#PCDATA) >

13.19  responsedescription XML Element

   Name:  responsedescription

   Namespace:  DAV:

   Purpose:  Contains a message that clients can reset the
      language.
   COPY/MOVE behaviour:  This property value SHOULD be preserved in
      local COPY and MOVE operations.  It SHOULD be attempted displayed to the user
      explaining the nature of the response.

   Description:  This XML element provides information suitable to be set
      in a COPY operation
      presented to a remote server.
   Description:  The getcontentlanguage property MUST be defined on any
      DAV compliant resource that returns the Content-Language header on
      a GET. user.

   Extensibility:  MAY contain be extended with attributes which SHOULD be ignored if not
      recognized.
      ignored.

   <!ELEMENT getcontentlanguage responsedescription (#PCDATA) >

14.4  getcontentlength Property

13.20  owner XML Element

   Name:  getcontentlength  owner

   Namespace:  DAV:

   Purpose:  Contains  Provides information about the Content-Length header returned by principal taking out a GET
      without accept headers.

   Value:  content-length (see section 14.14 of RFC2616 [8])
   Protected:  SHOULD be protected so clients cannot set to misleading
      values
   Description: lock.

   Description The getcontentlength property MUST be defined on any
      DAV compliant resource that returns owner XML element provides information sufficient for
      either directly contacting a principal (such as a telephone number
      or Email URI), or for discovering the Content-Length header in
      response to principal (such as the URL
      of a GET.
   COPY/MOVE behaviour: homepage) who owns a lock.  This property value information is dependent on provided by
      the size of client, and may only be altered by the destination resource, not server if the owner
      value of provided by the property client is empty.

   Extensibility MAY be extended with child elements, mixed content,
      text content or attributes.  Structured content, for example one
      or more <href> child elements containing URLs, is RECOMMENDED.

   <!ELEMENT owner ANY >

13.21  prop XML element

   Name:  prop

   Namespace:  DAV:

   Purpose:  Contains properties related to a resource.

   Description The prop XML element is a generic container for
      properties defined on resources.  All elements inside a prop XML
      element MUST define properties related to the
      source resource.
   Extensibility:  No other
      elements may be used inside of a prop element.

   Extensibility MAY contain be extended with attributes which SHOULD be ignored
      if not recognized.

   <!ELEMENT getcontentlength (#PCDATA) >

14.5  getcontenttype Property

   Name:  getcontenttype
   Namespace:  DAV:
   Purpose:  Contains the Content-Type header returned by a GET without
      accept headers.
   Value:  media-type (defined in section 3.7  Any child element of RFC2616 [8])
   Protected:  SHOULD NOT be protected, so clients may fix this value
   COPY/MOVE behaviour:  This property value SHOULD element must be
      considered to be preserved in
      local COPY and MOVE operations.  In a remote COPY operation that
      is implemented through a PUT request, the PUT request must have property name, however these are not restricted
      to the appropriate Content-Type header.
   Description:  This getcontenttype property MUST be names defined on any DAV
      compliant resource that returns the Content-Type header in
      response to a GET.
   Extensibility:  MAY contain attributes which SHOULD be ignored if not
      recognized. this document or other standards.

   <!ELEMENT getcontenttype (#PCDATA) prop ANY >

14.6  getetag Property

13.22  propertyupdate XML element

   Name:  getetag  propertyupdate

   Namespace:  DAV:

   Purpose:  Contains the ETag header returned by a GET without accept
      headers.
   Value:  entity-tag  (defined in section 3.11 of RFC2616 [8])
   Protected: MUST be protected because this value is created and
      controlled by the server.
   COPY/MOVE behaviour:  This property value is dependent on the final
      state of the destination resource, not the value of request to alter the property properties on the source a resource.

   Description:  The getetag property MUST be defined on any DAV
      compliant resource that returns  This XML element is a container for the Etag header.  Refer information
      required to RFC2616
      for a complete definition of modify the semantics of an ETag.  Note that
      changes in properties or lock state MUST not cause a resourceȔs
      ETag to change. on the resource.  This XML
      element is multi-valued.

   Extensibility:  MAY contain be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT getetag (#PCDATA) propertyupdate (remove | set)+ >

14.7  getlastmodified Property

13.23  remove XML element

   Name:  getlastmodified  remove

   Namespace:  DAV:

   Purpose:  Contains  Lists the Last-Modified header returned by DAV properties to be removed from a GET method
      without accept headers.
   Value:  HTTP-date  (defined resource.

   Description:  Remove instructs that the properties specified in section 3.3.1 of RFC2616 [8])
   Protected:  SHOULD prop
      should be protected because some clients may rely on the
      value for appropriate caching behavior, or on removed.  Specifying the value removal of the
      Last-Modified header to which this property is linked.
   COPY/MOVE behaviour:  This a property value that does
      not exist is dependent on not an error.  All the last
      modified date XML elements in a prop XML
      element inside of a remove XML element MUST be empty, as only the destination resource, not the value
      names of properties to be removed are required.

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT remove (prop) >

13.24  set XML element

   Name:  set

   Namespace:  DAV:

   Purpose:  Lists the DAV property on the source resource.  Note that some server
      implementations use the file system date modified value values to be set for the
      'getlastmodified' value, and this is preserved in a MOVE even when
      the HTTP Last-Modified value SHOULD change.  Thus, clients cannot
      rely on this value for caching and SHOULD use ETags. resource.

   Description:  Note that the last-modified date on a resource SHOULD  The set XML element MUST contain only reflect changes in a prop XML
      element.  The elements contained by the prop XML element inside
      the set XML element MUST specify the body (the GET responses) name and value of properties
      that are set on the
      resource.  A change in resource identified by Request-URI.  If a
      property only SHOULD NOT cause already exists then its value is replaced.  Language
      tagging information appearing in the
      last-modified date to change, because clients MAY rely on scope of the
      last-modified date to know when to overwrite prop element (in
      the existing body.
      The getlastmodified property "xml:lang" attribute, if present) MUST be defined on any DAV compliant
      resource that returns persistently stored
      along with the Last- Modified header in response to a
      GET. property, and MUST be subsequently retrievable
      using PROPFIND.

   Extensibility:  MAY contain be extended with additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT getlastmodified (#PCDATA) set (prop) >

14.8  lockdiscovery Property

13.25  propfind XML Element

   Name:  lockdiscovery  propfind

   Namespace:  DAV:

   Purpose:  Describes  Specifies the active locks on a resource
   Protected:  MUST properties to be protected.  Clients change the list of locks
      through LOCK returned from a PROPFIND
      method.  Four special elements are specified for use with
      propfind: prop, dead-props, allprop and UNLOCK, not through PROPPATCH.
   COPY/MOVE behaviour:  The value of this propname.  If prop is used
      inside propfind it MUST NOT contain property depends on the lock
      state of the destination, values.

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not on the locks recognized, as long as
      it still contains one of the source resource.
      Recall that locks are not moved in a MOVE operation.
   Description:  The lockdiscovery property returns a listing of who has
      a lock, what type required elements.

   <!ELEMENT propfind (prop | dead-props | propname | allprop) >

13.26  allprop XML Element

   Name:  allprop

   Namespace:  DAV:

   Purpose:  The allprop XML element specifies that all names and values
      of lock he has, the timeout type dead properties and the time
      remaining live properties defined by this
      document existing on the timeout, and the associated lock token.  If there resource are no locks, but the server supports locks, the property will to be
      present but contain zero Č½activelockČ” elements.  If there is one
      or more lock, an Č½activelockČ” element appears for each lock on
      the resource. returned.

   Extensibility:  Normally empty, but MAY be extended with additional
      child elements or attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT lockdiscovery (activelock)* allprop EMPTY >

14.8.1  Example - Retrieving the lockdiscovery Property

      >>Request

        PROPFIND /container/ HTTP/1.1
        Host: www.example.com
        Content-Length: xxxx
        Content-Type: text/xml; charset="utf-8"

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D='DAV:'>
         <D:response>
           <D:href>http://www.example.com/container/</D:href>
           <D:propstat>
             <D:prop>
               <D:lockdiscovery>
                <D:activelock>
                 <D:locktype><D:write/></D:locktype>
                 <D:lockscope><D:exclusive/></D:lockscope>
                 <D:depth>0</D:depth>
                 <D:owner>Jane Smith</D:owner>
                 <D:timeout>Infinite</D:timeout>
                 <D:locktoken>
                   <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
        00a0c91a9d76</D:href>
                 </D:locktoken>
                 <D:lockroot>
                   <D:href>http://www.example.com/container/</D:href>
                 </D:lockroot>
                 </D:activelock>
               </D:lockdiscovery>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>

   This resource has a single exclusive write lock on it, with an
   infinite timeout.

14.9  resourcetype Property

13.27  propname XML Element

   Name:  resourcetype  propname

   Namespace:  DAV:

   Purpose:  Specifies the nature of the resource.
   Protected:  SHOULD be protected.  Resource type is generally decided
      through the operation creating the resource (MKCOL vs PUT), not by
      PROPPATCH.
   COPY/MOVE behaviour:  Generally  The propname XML element specifies that only a COPY/MOVE list of a resource results in
      property names on the same type of resource at the destination.  In a remote COPY,
      the source server SHOULD NOT attempt is to set this property.
   Description:  The resourcetype property MUST be defined on all DAV
      compliant resources.  The default value is empty. returned.

   Extensibility:  Normally empty, but MAY be extended with any additional
      child elements or attributes which SHOULD be ignored if not
      recognized.  If the element
      contains the 'collection' child

   <!ELEMENT propname EMPTY >

13.28  dead-props XML Element

   Name:  dead-props

   Namespace:  DAV:

   Purpose:  The dead-props XML element plus additional
      unrecognized elements/attributes, it specifies that all dead
      properties, names and values, should generally be treated
      as a collection.  If returned in the element contains no recognized response.

   Extensibility:  Normally empty, but MAY be extended with additional
      child elements it should or attributes which SHOULD be treated as a non- collection
      WebDAV-compliant resource.

   Example: (fictional example to show extensibility)

               <x:resourcetype xmlns:x="DAV:">
                   <x:collection/>
                   <f:search-results xmlns:f="http://www.example.com/ns"/>
               </x:resourcetype>

14.10  supportedlock Property ignored if not
      recognized.

   <!ELEMENT dead-props EMPTY >

13.29  location XML Element

   Name:  supportedlock  location

   Namespace:  DAV:

   Purpose:  To provide  In normal responses (not Multi-Status), some status codes
      go along with a listing of the lock capabilities supported by
      the resource.
   Protected:  MUST be protected.  Servers determine what lock
      mechanisms Location header.  When these status codes are supported, not clients.
   COPY/MOVE behaviour:  This property value used
      in a Multi-Status response, this element is dependent on the kind of
      locks supported at the destination, not on the value of the
      property at used instead.

   Description:  Contains a single href element with the source resource.  Servers attempting to COPY to same URI that
      would be used in a
      destination should Location header.

   Extensibility:  MAY be extended with additional child elements or
      attributes which SHOULD be ignored if not attempt recognized.

   <!ELEMENT location (href) >

13.30  error XML Element

   Name:  error

   Namespace:  DAV:

   Purpose:  Error responses, particularly 403 Forbidden and 409
      Conflict, sometimes need more information to set this property at the
      destination.
   Description:  The supportedlock property of a resource returns indicate what went
      wrong.  When an error response contains a
      listing of the combinations of scope and access types which may be
      specified body in a lock request on the resource.  Note that WebDAV, the actual
      contents are themselves controlled by access controls so a server body
      is not required to provide information in XML with the root element 'error'.  The 'error' tag SHOULD
      include a standard error tag defined in this specification or
      another specification.  The 'error' tag MAY include custom error
      tags (in custom namespaces) which a client is not
      authorized to see. can safely ignore.

   Description:  Contains any XML element

   Extensibility:  MAY be extended  Fully extensible with any additional child elements or
      attributes which SHOULD be ignored if not recognized.

   <!ELEMENT supportedlock (lockentry)* error ANY >

14.10.1  Example - Retrieving

14.  DAV Properties

   For DAV properties, the name of the property is also the same as the
   name of the supportedlock Property
      >>Request

        PROPFIND  /container/ HTTP/1.1
        Host: www.example.com
        Content-Length: xxxx
        Content-Type: text/xml; charset="utf-8"

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:">
         <D:response>
           <D:href>http://www.example.com/container/</D:href>
           <D:propstat>
             <D:prop>
               <D:supportedlock>
                 <D:lockentry>
                   <D:lockscope><D:exclusive/></D:lockscope>
                   <D:locktype><D:write/></D:locktype>
                 </D:lockentry>
                 <D:lockentry>
                   <D:lockscope><D:shared/></D:lockscope>
                   <D:locktype><D:write/></D:locktype>
                 </D:lockentry>
               </D:supportedlock>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>

15.  Precondition/postcondition XML elements element that contains its value.  In the section
   below, the final line of each section gives the element type
   declaration using the format defined in XML [11].  The numerical status codes used "Value" field,
   where present, specifies further restrictions on the allowable
   contents of the XML element using BNF (i.e., to further restrict the
   values of a PCDATA element).  Note that a resource may have only one
   value for a property of a given name, so the property may only show
   up once in HTTP PROPFIND responses are not
   sufficiently granular or informative for all purposes. PROPPATCH requests.

   Some
   extensions property values are calculated by the server and it is not
   appropriate to HTTP allow client changes, thus they are protected.
   Existing server implementations already have different sets of
   RFC2518 properties protected, but clients can have used the error response body along with some
   status codes in order to provide additiona machine-readable response
   detail.  The machine-readable codes expectations
   which properties are XML elements classified as
   preconditions (generally client error or failure normally protected.  The value of a protected
   property may not be changed even by a user with permission to meet edit
   other properties.  The value of an unprotected property may be
   changed by some users with appropriate permissions.

14.1  creationdate Property

   Name:  creationdate

   Namespace:  DAV:

   Purpose:  Records the
   conditions time and date the resource was created.

   Value:  date-time (defined in order for RFC3339 [8], see the request to ABNF in section
      5.6.)

   Protected:  MAY be considered) and
   postconditions (generally server error or failure protected.  Some servers allow creationdate to respond
   successfully be
      changed to an otherwise valid request).  The precondition or
   postcondition XML element appears inside an 'error' element which is
   the root of reflect the XML body of time the response.  The 'error' root element
   or document was created if that is
      more meaningful to the precondition or postcondition elements MAY contain additional
   XML elements or attributes not defined in this specification.

   XML elements in error response bodies were not used in RFC2518, but
   were introduced in RFC2518bis. user (rather than the time it was
      uploaded).  Thus, clients SHOULD NOT use of these informative
   elements this property in
      synchronization logic (use getetag instead).

   COPY/MOVE behaviour:  This property value SHOULD be kept during a
      MOVE operation, but is RECOMMENDED.  Even if clients do normally re-initialized when a resource is
      created with a COPY.  It should not automatically
   recognize the error bodies they can be quite useful set in
   interoperability testing and debugging.

   Name: external-entities-forbidden
   Namespace: DAV:
   Use with: 403 Forbidden
   Purpose: (precondition) -- a COPY.

   Description:  The creationdate property should be defined on all DAV
      compliant resources.  If the server rejects present, it contains a client request
      because timestamp of the request body contains an external entity,
      moment when the server resource was created (i.e., the moment it had non-
      null state).

   Extensibility:  MAY contain attributes which SHOULD use this error. be ignored if not
      recognized.

   <!ELEMENT external-entities-forbidden EMPTY creationdate (#PCDATA) >

14.2  displayname Property

   Name: requesturi-must-match-lock-token  displayname

   Namespace:  DAV:
   Use with: 400 Bad Request

   Purpose: (precondition) -- A request may include a Lock-Token header
      to identify  Provides a lock name for the purposes of an resource that is suitable for
      presentation to a user.

   Value:  Any text

   Protected:  Possibly

   COPY/MOVE behaviour:  This property value SHOULD be preserved in
      local COPY and MOVE operations.  It MAY be attempted to be set in
      a COPY operation such as
      refresh LOCK or UNLOCK.  However, if the Request-URI doe not fall
      within to a remote server.

   Description:  The displayname property should be defined on all DAV
      compliant resources.  If present, the scope property contains a
      description of the lock identified resource that is suitable for presentation to a
      user.

   Extensibility:  MAY contain attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT displayname (#PCDATA) >

14.3  getcontentlanguage Property

   Name:  getcontentlanguage

   Namespace:  DAV:

   Purpose:  Contains the Content-Language header returned by a GET
      without accept headers

   Value:  language-tag (language-tag is defined in section 14.13 of
      RFC2616 [7])
   Protected:  SHOULD NOT be protected, so that clients can reset the token, the server
      language.

   COPY/MOVE behaviour:  This property value SHOULD use this error.  The lock may have be preserved in
      local COPY and MOVE operations.  It SHOULD be attempted to be set
      in a scope COPY operation to a remote server.

   Description:  The getcontentlanguage property MUST be defined on any
      DAV compliant resource that does not
      include the Request-URI, or the lock could have disappeared, or returns the token may Content-Language header on
      a GET.

   Extensibility:  MAY contain attributes which SHOULD be invalid. ignored if not
      recognized.

   <!ELEMENT requesturi-must-match-lock-token EMPTY getcontentlanguage (#PCDATA) >

14.4  getcontentlength Property

   Name: missing-lock-token  getcontentlength

   Namespace:  DAV:
   Use with: 400 Bad Request

   Purpose: (precondition) -- If  Contains the server rejects Content-Length header returned by a request because
      the request GET
      without accept headers.

   Value:  content-length (see section 14.14 of RFC2616 [7])

   Protected:  SHOULD be protected so clients cannot set to misleading
      values

   Description:  The getcontentlength property MUST have be defined on any
      DAV compliant resource that returns the Content-Length header in
      response to a lock token and GET.

   COPY/MOVE behaviour:  This property value is missing dependent on the size of
      the destination resource, not the lock token
      header or header value (e.g. of the property on an UNLOCK request), the server
      source resource.

   Extensibility:  MAY contain attributes which SHOULD use this error. be ignored if not
      recognized.

   <!ELEMENT missing-lock-token EMPTY getcontentlength (#PCDATA) >

14.5  getcontenttype Property
   Name: live-properties-not-preserved  getcontenttype

   Namespace:  DAV:
   Use with: 409 Conflict

   Purpose: (postcondition) -- The server received an otherwise-valid  Contains the Content-Type header returned by a GET without
      accept headers.

   Value:  media-type (defined in section 3.7 of RFC2616 [7])

   Protected:  SHOULD NOT be protected, so clients may fix this value

   COPY/MOVE behaviour:  This property value SHOULD be preserved in
      local COPY and MOVE or operations.  In a remote COPY operation that
      is implemented through a PUT request, but cannot maintain the live properties with the same behavior at PUT request must have
      the destination.  It may appropriate Content-Type header.

   Description:  This getcontenttype property MUST be defined on any DAV
      compliant resource that returns the server
      only supports some live properties Content-Type header in some parts of the
      repository, or simply has an internal error.

   <!ELEMENT live-properties-not-preserved EMPTY >

   Name: read-only-property
   Namespace: DAV:
   Use with: 403 Forbidden
   Purpose: (precondition) -- The client attempted
      response to set a read-only
      property in a PROPPATCH (such as 'getetag'). GET.

   Extensibility:  MAY contain attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT read-only-property EMPTY getcontenttype (#PCDATA) >

14.6  getetag Property

   Name: propfind-infinite-depth-forbidden  getetag

   Namespace:  DAV:
   Use with: 403 Forbidden

   Purpose: (precondition) --  Contains the ETag header returned by a GET without accept
      headers.

   Value:  entity-tag  (defined in section 3.11 of RFC2616 [7])

   Protected: MUST be protected because this value is created and
      controlled by the server.

   COPY/MOVE behaviour:  This server does property value is dependent on the final
      state of the destination resource, not allow infinite-depth
      PROPFIND requests the value of the property
      on collections.

   <!ELEMENT propfind-infinite-depth-forbidden EMPTY >

   Name: need-privileges
   Namespace: DAV:
   Use with: 403 Forbidden
   Purpose: (precondition) -- the source resource.

   Description:  The currently authenticated user simply
      does not have getetag property MUST be defined on any DAV
      compliant resource that returns the privileges required Etag header.  Refer to do the requested
      operation (e.g.  UNLOCK RFC2616
      for a complete definition of the semantics of an ETag.  Note that
      changes in properties or lock created by someone else). state MUST not cause a resourceis
      ETag to change.

   Extensibility:  MAY contain attributes which SHOULD be ignored if not
      recognized.

   <!ELEMENT need-privileges EMPTY getetag (#PCDATA) >

14.7  getlastmodified Property

   Name: missing-lock-token  getlastmodified

   Namespace:  DAV:
   Use with: 423 Locked

   Purpose: (precondition) -- The request could not succeed because  Contains the Last-Modified header returned by a
      lock token should have been provided. GET method
      without accept headers.

   Value:  rfc1123-date  (defined in section 3.3.1 of RFC2616 [7])

   Protected:  SHOULD be protected because some clients may rely on the
      value for appropriate caching behavior, or on the value of the
      Last-Modified header to which this property is linked.

   COPY/MOVE behaviour:  This element, if present,
      MUST contain property value is dependent on the URL last
      modified date of a locked resource that prevented the
      request.  In cases destination resource, not the value of MOVE, COPY the
      property on the source resource.  Note that some server
      implementations use the file system date modified value for the
      'getlastmodified' value, and DELETE where collection locks
      are involved, it can be difficult this is preserved in a MOVE even when
      the HTTP Last-Modified value SHOULD change.  Thus, clients cannot
      rely on this value for caching and SHOULD use ETags.

   Description:  Note that the last-modified date on a resource SHOULD
      only reflect changes in the body (the GET responses) of the
      resource.  A change in a property only SHOULD NOT cause the client last-
      modified date to find out which
      locked resource made change, because clients MAY rely on the request fail -- but last-
      modified date to know when to overwrite the server is only
      resonsible for returning one such locked resource. existing body.  The server MAY
      return every locked resource that prevented the request from
      succeeding if it knows them all.

   <!ELEMENT missing-lock-token (href+) >

16.  Instructions for Processing XML in DAV

   All DAV compliant resources
      getlastmodified property MUST ignore be defined on any unknown XML element and
   all its children encountered while processing a DAV method compliant
      resource that uses
   XML as its command language.

   This restriction also applies to returns the processing, by clients, of DAV
   property values where unknown XML elements Last- Modified header in response to a
      GET.

   Extensibility:  MAY contain attributes which SHOULD be ignored unless if not
      recognized.

   <!ELEMENT getlastmodified (#PCDATA) >

14.8  lockdiscovery Property

   Name:  lockdiscovery

   Namespace:  DAV:

   Purpose:  Describes the property's schema declares otherwise.

   This restriction does active locks on a resource

   Protected:  MUST be protected.  Clients change the list of locks
      through LOCK and UNLOCK, not apply to setting dead DAV properties through PROPPATCH.

   COPY/MOVE behaviour:  The value of this property depends on the
   server where lock
      state of the server MUST record unknown XML elements.

   Additionally, this restriction does destination, not apply to on the use locks of XML where
   XML happens to be the content source resource.
      Recall that locks are not moved in a MOVE operation.

   Description:  The lockdiscovery property returns a listing of who has
      a lock, what type of lock he has, the timeout type and the time
      remaining on the timeout, and the associated lock token.  If there
      are no locks, but the entity body, for example,
   when used as server supports locks, the body of a PUT.

   Since XML can property will be transported as text/xml or application/xml, a DAV
   server MUST accept DAV method requests with XML parameters
   transported as either text/xml or application/xml, and a DAV client
   MUST accept XML responses using either text/xml
      present but contain zero eactivelocki elements.  If there is one
      or application/xml.

   XML DTD fragments are included more lock, an eactivelocki element appears for all each lock on the XML
      resource.

   Extensibility:  MAY be extended with additional child elements defined in
   this specification.  However, legal XML may not or
      attributes which SHOULD be valid according to
   any DTD due to namespace usage and extension rules, so ignored if not recognized.

   <!ELEMENT lockdiscovery (activelock)* >

14.8.1  Example - Retrieving the DTD is
   only informational.  A recipient of lockdiscovery Property
      >>Request

        PROPFIND /container/ HTTP/1.1
        Host: www.example.com
        Content-Length: xxxx
        Content-Type: text/xml; charset="utf-8"

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D='DAV:'>
         <D:response>
           <D:href>http://www.example.com/container/</D:href>
           <D:propstat>
             <D:prop>
               <D:lockdiscovery>
                <D:activelock>
                 <D:locktype><D:write/></D:locktype>
                 <D:lockscope><D:exclusive/></D:lockscope>
                 <D:depth>0</D:depth>
                 <D:owner>Jane Smith</D:owner>
                 <D:timeout>Infinite</D:timeout>
                 <D:locktoken>
                   <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
        00a0c91a9d76</D:href>
                 </D:locktoken>
                 <D:lockroot>
                   <D:href>http://www.example.com/container/</D:href>
                 </D:lockroot>
                 </D:activelock>
               </D:lockdiscovery>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>

   This resource has a WebDAV message single exclusive write lock on it, with an XML body
   MUST NOT validate
   infinite timeout.

14.9  resourcetype Property

   Name:  resourcetype

   Namespace:  DAV:

   Purpose:  Specifies the XML document according to any hard-coded or
   dynamically-declared DTD.

17.  DAV Compliance Classes

   A DAV compliant resource can advertise several classes nature of compliance.
   A client can discover the compliance classes resource.

   Protected:  SHOULD be protected.  Resource type is generally decided
      through the operation creating the resource (MKCOL vs PUT), not by
      PROPPATCH.

   COPY/MOVE behaviour:  Generally a COPY/MOVE of a resource by
   executing OPTIONS on the resource, and examining results in
      the "DAV" header
   which is returned.  Note particularly that resources are spoken same type of as
   being compliant, rather than servers.  That is because theoretically
   some resources on a server could support different feature sets.
   E.g.  a server could have resource at the destination.  In a sub-repository where an advanced feature
   like remote COPY,
      the source server was supported, even if that feature was not supported on
   all servers.

   Since this document describes extensions SHOULD NOT attempt to the HTTP/1.1 protocol,
   minimally set this property.

   Description:  The resourcetype property MUST be defined on all DAV
      compliant resources, clients, and proxies MUST resources.  The default value is empty.

   Extensibility:  MAY be
   compliant extended with RFC2616 [8].

   A resource that is class 2 compliant must also any child elements or attributes
      which SHOULD be class 1 compliant,
   and ignored if not recognized.  If the element
      contains the 'collection' child element plus additional
      unrecognized elements/attributes, it should generally be treated
      as a resource that is compliant with "bis" must also collection.  If the element contains no recognized child
      elements it should be class 1
   compliant.

17.1  Class 1

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

   Class 1 treated as a non- collection WebDAV-
      compliant resources MUST return, at minimum, resource.

   Example: (fictional example to show extensibility)

       <x:resourcetype xmlns:x="DAV:">
           <x:collection/>
           <f:search-results xmlns:f="http://www.example.com/ns"/>
       </x:resourcetype>

14.10  supportedlock Property

   Name:  supportedlock

   Namespace:  DAV:

   Purpose:  To provide a listing of the value "1" in lock capabilities supported by
      the DAV header resource.

   Protected:  MUST be protected.  Servers determine what lock
      mechanisms are supported, not clients.

   COPY/MOVE behaviour:  This property value is dependent on all responses to the OPTIONS method.

17.2  Class 2

   A class 2 compliant resource MUST meet all class 1 requirements and
   support kind of
      locks supported at the LOCK method, destination, not on the supportedlock property, value of the
   lockdiscovery property,
      property at the Time-Out response header and source resource.  Servers attempting to COPY to a
      destination should not attempt to set this property at the Lock-
   Token request header.  A class "2" compliant
      destination.

   Description:  The supportedlock property of a resource SHOULD also
   support returns a
      listing of the Time-Out request header combinations of scope and access types which may be
      specified in a lock request on the owner XML element.

   Class 2 compliant resources MUST return, at minimum, resource.  Note that the values "1"
   and "2" actual
      contents are themselves controlled by access controls so a server
      is not required to provide information the client is not
      authorized to see.

   Extensibility:  MAY be extended with any child elements or attributes
      which SHOULD be ignored if not recognized.

   <!ELEMENT supportedlock (lockentry)* >

14.10.1  Example - Retrieving the supportedlock Property

      >>Request

        PROPFIND  /container/ HTTP/1.1
        Host: www.example.com
        Content-Length: xxxx
        Content-Type: text/xml; charset="utf-8"

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

      >>Response

        HTTP/1.1 207 Multi-Status
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

        <?xml version="1.0" encoding="utf-8" ?>
        <D:multistatus xmlns:D="DAV:">
         <D:response>
           <D:href>http://www.example.com/container/</D:href>
           <D:propstat>
             <D:prop>
               <D:supportedlock>
                 <D:lockentry>
                   <D:lockscope><D:exclusive/></D:lockscope>
                   <D:locktype><D:write/></D:locktype>
                 </D:lockentry>
                 <D:lockentry>
                   <D:lockscope><D:shared/></D:lockscope>
                   <D:locktype><D:write/></D:locktype>
                 </D:lockentry>
               </D:supportedlock>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
         </D:response>
        </D:multistatus>

15.  Precondition/postcondition XML elements

   The numerical status codes used in the DAV header on all HTTP responses are not
   sufficiently granular or informative for all purposes.  Some
   extensions to HTTP have used the OPTIONS method.

17.3  Class 'bis'

   A resource can explicitly advertise its support error response body along with some
   status codes in order to provide additiona machine-readable response
   detail.  The machine-readable codes are XML elements classified as
   preconditions (generally client error or failure to meet the
   conditions in order for the revisions request to
   RFC2518 made in this document.  In particular, this allows clients be considered) and
   postconditions (generally server error or failure to
   use respond
   successfully to an otherwise valid request).  The precondition or
   postcondition XML element appears inside an 'error' element which is
   the Force-Authentication header on requests.  Class 1 must be
   supported as well.  Class 2 MAY be supported.

   A resource that supports bis MUST support:

   o root of the Force-Authentication header.
   o  Any behavior that it supports, in XML body of the manner specified response.  The 'error' root element
   or the precondition or postcondition elements MAY contain additional
   XML elements or attributes not defined in this
      document, rather than specification.

   XML elements in the manner specified error response bodies were not used in RFC2518, for all
      client requests.  A server MAY use an older behavior for specific
      clients that are discovered to have interoperability problems with
      the requirements of this specification, but MUST NOT
   were introduced in RFC2518bis.  Thus, use an older
      behavior indiscriminately.

   Example:

            DAV: 1, bis

18.  Internationalization Considerations

   In the realm of internationalization, this specification complies
   with these informative
   elements is RECOMMENDED.  Even if clients do not automatically
   recognize the IETF Character Set Policy RFC2277 [8].  In this
   specification, human-readable fields error bodies they can be found either quite useful in
   interoperability testing and debugging.

   Name: external-entities-forbidden

   Namespace: DAV:

   Use with: 403 Forbidden

   Purpose: (precondition) -- If the value
   of server rejects a property, or in client request
      because the request body contains an error message returned in a response entity
   body.  In both cases, external entity, the human-readable content is encoded using
   XML, which has explicit provisions server
      SHOULD use this error.

   <!ELEMENT external-entities-forbidden EMPTY >

   Name: requesturi-must-match-lock-token

   Namespace: DAV:

   Use with: 400 Bad Request

   Purpose: (precondition) -- A request may include a Lock-Token header
      to identify a lock for character set tagging and
   encoding, and requires that XML processors read XML elements encoded,
   at minimum, using the UTF-8 RFC2279 [5] and UTF-16 encodings purposes of an operation such as
      refresh LOCK or UNLOCK.  However, if the
   ISO 10646 multilingual plane.  XML examples in this specification
   demonstrate use of Request-URI doe not fall
      within the charset parameter scope of the Content-Type header,
   as defined in RFC2376 [17], as well as lock identified by the XML declarations which
   provide charset identification information for MIME and XML
   processors.

   XML also provides token, the server
      SHOULD use this error.  The lock may have a language tagging capability for specifying scope that does not
      include the
   language of Request-URI, or the contents of a particular XML element.  The "xml:lang"
   attribute appears on an XML element to identify lock could have disappeared, or
      the token may be invalid.

   <!ELEMENT requesturi-must-match-lock-token EMPTY >

   Name: missing-lock-token

   Namespace: DAV:

   Use with: 400 Bad Request

   Purpose: (precondition) -- If the language of its
   content and attributes.  See XML [11] for definitions of values and
   scoping.

   WebDAV applications MUST support server rejects a request because
      the character set tagging, character
   set encoding, request MUST have a lock token and is missing the language tagging functionality of lock token
      header or header value (e.g. on an UNLOCK request), the XML
   specification.  Implementors server
      SHOULD use this error.  The 'missing-lock-token' element MUST
      contain at least one URL of WebDAV applications are strongly
   encouraged to read "XML Media Types" RFC2376 [17] a locked resource for instruction on which MIME media type to use for XML transport, and on use of a lock
      token was expected.

   <!ELEMENT missing-lock-token href* >

   Name: live-properties-not-preserved

   Namespace: DAV:

   Use with: 409 Conflict

   Purpose: (postcondition) -- The server received an otherwise-valid
      MOVE or COPY request, but cannot maintain the
   charset parameter of live properties with
      the Content-Type header.

   Names used within this specification fall into four categories: names
   of protocol elements such as methods and headers, names of XML
   elements, names of properties, and names of conditions.  Naming of
   protocol elements follows same behavior at the precedent destination.  It may be that the server
      only supports some live properties in some parts of HTTP, using English names
   encoded the
      repository, or simply has an internal error.

   <!ELEMENT live-properties-not-preserved EMPTY >

   Name: read-only-property

   Namespace: DAV:

   Use with: 403 Forbidden

   Purpose: (precondition) -- The client attempted to set a read-only
      property in USASCII for methods and headers.  Since these protocol
   elements are a PROPPATCH (such as 'getetag').

   <!ELEMENT read-only-property EMPTY >

   Name: propfind-infinite-depth-forbidden

   Namespace: DAV:

   Use with: 403 Forbidden

   Purpose: (precondition) -- This server does not visible to users, and are allow infinite-depth
      PROPFIND requests on collections.

   <!ELEMENT propfind-infinite-depth-forbidden EMPTY >

   Name: need-privileges

   Namespace: DAV:

   Use with: 403 Forbidden

   Purpose: (precondition) -- The currently authenticated user simply long token
   identifiers, they do
      does not need to support multiple languages.
   Similarly, have the names of XML elements used in this specification are
   not visible privileges required to the user and hence do the requested
      operation (e.g.  UNLOCK a lock created by someone else).

   <!ELEMENT need-privileges EMPTY >

   Name: missing-lock-token

   Namespace: DAV:

   Use with: 423 Locked

   Purpose: (precondition) -- The request could not need to support multiple
   languages.

   WebDAV property names are qualified XML names (pairs succeed because a
      lock token should have been provided.  This element, if present,
      MUST contain the URL of XML namespace
   name and local name).  Although some applications (e.g., a generic
   property viewer) will display property names directly to their users,
   it is expected locked resource that prevented the typical application will use a fixed set
      request.  In cases of
   properties, MOVE, COPY and will provide a mapping from DELETE where collection locks
      are involved, it can be difficult for the property name client to find out which
      locked resource made the request fail -- but the server is only
      resonsible for returning one such locked resource.  The server MAY
      return every locked resource that prevented the request from
      succeeding if it knows them all.

   <!ELEMENT missing-lock-token (href+) >

16.  Instructions for Processing XML in DAV

   All DAV compliant resources MUST ignore any unknown XML element and
   namespace
   all its children encountered while processing a DAV method that uses
   XML as its command language.

   This restriction also applies to a human-readable field when displaying the processing, by clients, of DAV
   property name values where unknown XML elements SHOULD be ignored unless
   the property's schema declares otherwise.

   This restriction does not apply to a user.  It is only in setting dead DAV properties on the case
   server where the set of properties is server MUST record unknown XML elements.

   Additionally, this restriction does not
   known ahead of time that an application need display a property name
   URI apply to a user.  We recommend that applications provide human-readable
   property names wherever feasible.

   For error reporting, we follow the convention use of HTTP/1.1 status
   codes, including with each status code a short, English description XML where
   XML happens to be the content type of the code (e.g., 423 (Locked)).  While entity body, for example,
   when used as the possibility exists that body of a poorly crafted user agent would display this message to PUT.

   Since XML can be transported as text/xml or application/xml, a user,
   internationalized applications will ignore this message, DAV
   server MUST accept DAV method requests with XML parameters
   transported as either text/xml or application/xml, and display
   an appropriate message in a DAV client
   MUST accept XML responses using either text/xml or application/xml.

   XML DTD fragments are included for all the user's language and character set.

   Since interoperation of clients and servers does not require locale
   information, XML elements defined in
   this specification does specification.  However, legal XML may not specify be valid according to
   any mechanism for
   transmission of this information.

19.  Security Considerations

   This section DTD due to namespace usage and extension rules, so the DTD is provided to detail issues concerning security
   implications
   only informational.  A recipient of which a WebDAV applications need message with an XML body
   MUST NOT validate the XML document according to be aware.

   All any hard-coded or
   dynamically-declared DTD.

17.  DAV Compliance Classes

   A DAV compliant resource can advertise several classes of compliance.
   A client can discover the security considerations compliance classes of HTTP/1.1 (discussed in RFC2616
   [8]) and XML (discussed in RFC2376 [17]) also apply to WebDAV.  In
   addition, a resource by
   executing OPTIONS on the security risks inherent in remote authoring require
   stronger authentication technology, introduce several new privacy
   concerns, resource, and may increase examining the hazards from poor server design.
   These issues "DAV" header
   which is returned.  Note particularly that resources are detailed below.

19.1  Authentication spoken of Clients

   Due to their emphasis as
   being compliant, rather than servers.  That is because theoretically
   some resources on authoring, WebDAV servers need to use
   authentication technology to protect a server could support different feature sets.
   E.g. a server could have a sub-repository where an advanced feature
   like server was supported, even if that feature was not just access supported on
   all servers.

   Since this document describes extensions to the HTTP/1.1 protocol,
   minimally all DAV compliant resources, clients, and proxies MUST be
   compliant with RFC2616 [7].

   A resource that is class 2 compliant must also be class 1 compliant,
   and a network
   resource, but resource that is compliant with "bis" must also be class 1
   compliant.

17.1  Class 1

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

   Class 1 compliant resources MUST return, at minimum, the integrity of value "1" in
   the resource as well.  Furthermore, DAV header on all responses to the introduction of locking functionality requires support for
   authentication. OPTIONS method.

17.2  Class 2

   A password sent in class 2 compliant resource MUST meet all class 1 requirements and
   support the clear over an insecure channel is an
   inadequate means for protecting LOCK method, the accessibility supportedlock property, the
   lockdiscovery property, the Time-Out response header and integrity of a the Lock-
   Token request header.  A class "2" compliant resource as SHOULD also
   support the password may be intercepted.  Since Basic
   authentication for HTTP/1.1 performs essentially clear text
   transmission of a password, Basic authentication MUST NOT be used to
   authenticate a WebDAV client to a server unless Time-Out request header and the connection is
   secure.  Furthermore, a WebDAV server owner XML element.

   Class 2 compliant resources MUST NOT send Basic
   authentication credentials return, at minimum, the values "1"
   and "2" in a WWW-Authenticate the DAV header unless on all responses to the
   connection is secure.  Examples of secure connections include a
   Transport Layer Security (TLS) connection employing a strong cipher
   suite with mutual authentication of client and server, or a
   connection over a network which is physically secure, OPTIONS method.

17.3  Class 'bis'

   A resource can explicitly advertise its support for example, an
   isolated network the revisions to
   RFC2518 made in a building with restricted access.

   WebDAV applications MUST support this document.  In particular, this allows clients to
   use the Digest authentication scheme
   RFC2069 [2].  Since Digest authentication verifies Force-Authentication header on requests.  Class 1 must be
   supported as well.  Class 2 MAY be supported.

   A resource that both parties
   to a communication know a shared secret, a password, without having
   to send supports bis MUST support:

   o  the Force-Authentication header.

   o  Any behavior that secret it supports, in the clear, Digest authentication avoids the
   security problems inherent manner specified in Basic authentication while providing a
   level of authentication which is useful this
      document, rather than in a wide range of scenarios.

19.2  Denial of Service

   Denial of service attacks the manner specified in RFC2518, for all
      client requests.  A server MAY use an older behavior for specific
      clients that are of special concern discovered to WebDAV servers.
   WebDAV plus HTTP enables denial have interoperability problems with
      the requirements of service attacks on every part this specification, but MUST NOT use an older
      behavior indiscriminately.

   Example:

            DAV: 1, bis

18.  Internationalization Considerations

   In the realm of a
   system's resources.

   The underlying storage internationalization, this specification complies
   with the IETF Character Set Policy RFC2277 [7].  In this
   specification, human-readable fields can be attacked by PUTting extremely large
   files.

   Asking found either in the value
   of a property, or in an error message returned in a response entity
   body.  In both cases, the human-readable content is encoded using
   XML, which has explicit provisions for recursive operations on large collections can attack
   processing time.

   Making multiple pipelined requests on multiple connections can attack
   network connections.

   WebDAV servers need to be aware character set tagging and
   encoding, and requires that XML processors read XML elements encoded,
   at minimum, using the UTF-8 RFC2279 [4] and UTF-16 encodings of the possibility
   ISO 10646 multilingual plane.  XML examples in this specification
   demonstrate use of a denial the charset parameter of
   service attack at all levels.

19.3  Security through Obscurity

   WebDAV provides, through the PROPFIND method, Content-Type header,
   as defined in RFC2376 [13], as well as the XML declarations which
   provide charset identification information for MIME and XML
   processors.

   XML also provides a mechanism language tagging capability for listing specifying the member resources
   language of a collection.  This greatly diminishes the
   effectiveness contents of security or privacy techniques that rely only a particular XML element.  The "xml:lang"
   attribute appears on an XML element to identify the
   difficulty language of discovering its
   content and attributes.  See XML [11] for definitions of values and
   scoping.

   WebDAV applications MUST support the names character set tagging, character
   set encoding, and the language tagging functionality of network resources.  Users the XML
   specification.  Implementors of WebDAV servers applications are strongly
   encouraged to use access control techniques to
   prevent unwanted access to resources, rather than depending read "XML Media Types" RFC2376 [13] for instruction on the
   relative obscurity of their resource names.

19.4  Privacy Issues Connected
   which MIME media type to Locks

   When submitting a lock request a user agent may also submit an owner
   XML field giving contact information use for XML transport, and on use of the person taking out the
   lock (for those cases where a person, rather than a robot, is taking
   out
   charset parameter of the lock).  This contact information is stored in a lockdiscovery
   property on Content-Type header.

   Names used within this specification fall into four categories: names
   of protocol elements such as methods and headers, names of XML
   elements, names of properties, and names of conditions.  Naming of
   protocol elements follows the resource, precedent of HTTP, using English names
   encoded in USASCII for methods and can be used by other collaborators headers.  Since these protocol
   elements are not visible to
   begin negotiation over access users, and are simply long token
   identifiers, they do not need to support multiple languages.
   Similarly, the resource.  However, names of XML elements used in many
   cases this contact information can be very private, and should specification are
   not be
   widely disseminated.  Servers SHOULD limit read access visible to the
   lockdiscovery property as appropriate.  Furthermore, user agents
   SHOULD provide control over whether contact information is sent at
   all, and if contact information is sent, control over exactly what
   information is sent.

19.5  Privacy Issues Connected hence do not need to Properties

   Since support multiple
   languages.

   WebDAV property values names are typically used to hold information such as
   the author qualified XML names (pairs of XML namespace
   name and local name).  Although some applications (e.g., a document, there generic
   property viewer) will display property names directly to their users,
   it is the possibility expected that privacy
   concerns could arise stemming the typical application will use a fixed set of
   properties, and will provide a mapping from widespread access the property name and
   namespace to a resource's human-readable field when displaying the property data.  To reduce name
   to a user.  It is only in the risk case where the set of inadvertent release properties is not
   known ahead of private
   information via properties, servers are encouraged to develop access
   control mechanisms time that separate read access an application need display a property name
   URI to a user.  We recommend that applications provide human-readable
   property names wherever feasible.

   For error reporting, we follow the convention of HTTP/1.1 status
   codes, including with each status code a short, English description
   of the resource body and
   read access to code (e.g., 423 (Locked)).  While the resource's properties.  This allows possibility exists that
   a poorly crafted user agent would display this message to
   control a user,
   internationalized applications will ignore this message, and display
   an appropriate message in the dissemination user's language and character set.

   Since interoperation of their property data without overly
   restricting access to the resource's contents.

19.6  Implications clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of XML External Entities

   XML supports a facility known as "external entities", defined in this information.

19.  Security Considerations

   This section 4.2.2 is provided to detail issues concerning security
   implications of XML [11], which instruct an XML processor to
   retrieve and include additional XML.  An external XML entity can be
   used WebDAV applications need to append or modify the document type declaration (DTD)
   associated with an XML document.  An external XML entity can also be
   used to include XML within the content aware.

   All of an XML document.  For non-
   validating XML, such as the XML used security considerations of HTTP/1.1 (discussed in this specification, including
   an external XML entity is not required by XML [11].  However, XML
   [11] does state that an RFC2616
   [7]) and XML processor may, at its discretion, include (discussed in RFC2376 [13]) also apply to WebDAV.  In
   addition, the external XML entity.

   External XML entities have no security risks inherent trustworthiness in remote authoring require
   stronger authentication technology, introduce several new privacy
   concerns, and are
   subject to all may increase the attacks that hazards from poor server design.
   These issues are endemic detailed below.

19.1  Authentication of Clients

   Due to any HTTP GET request.
   Furthermore, it is possible for an external XML entity their emphasis on authoring, WebDAV servers need to modify use
   authentication technology to protect not just access to a network
   resource, but the
   DTD, and hence affect integrity of the final form resource as well.  Furthermore,
   the introduction of an XML document, locking functionality requires support for
   authentication.

   A password sent in the worst
   case significantly modifying its semantics, or exposing clear over an insecure channel is an
   inadequate means for protecting the XML
   processor to accessibility and integrity of a
   resource as the security risks discussed in RFC2376 [17].
   Therefore, implementers must be aware that external XML entities
   should password may be treated as untrustworthy.  If intercepted.  Since Basic
   authentication for HTTP/1.1 performs essentially clear text
   transmission of a server implementor chooses
   not password, Basic authentication MUST NOT be used to handle external XML entities, it SHOULD respond
   authenticate a WebDAV client to requests
   containing external entities with a server unless the precondition defined above
   (external-entities-forbidden).

   There connection is also the scalability risk that would accompany
   secure.  Furthermore, a widely
   deployed application which made use of external XML entities.  In
   this situation, it is possible that there would be significant
   numbers of requests for one external XML entity, potentially
   overloading any WebDAV server which fields requests for the resource
   containing the external XML entity.

19.7  Risks Connected with Lock Tokens

   This specification, MUST NOT send Basic
   authentication credentials in section 6.4, requires a WWW-Authenticate header unless the use
   connection is secure.  Examples of secure connections include a
   Transport Layer Security (TLS) connection employing a strong cipher
   suite with mutual authentication of Universal
   Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
   their uniqueness across space client and time.  UUIDs, as defined in
   ISO-11578 [12], contain server, or a "node" field
   connection over a network which "consists of the IEEE
   address, usually the host address.  For systems is physically secure, for example, an
   isolated network in a building with multiple IEEE
   802 nodes, any available node address can be used." restricted access.

   WebDAV applications MUST support the Digest authentication scheme
   RFC2069 [1].  Since Digest authentication verifies that both parties
   to a WebDAV
   server will issue many locks over its lifetime, communication know a shared secret, a password, without having
   to send that secret in the clear, Digest authentication avoids the implication
   security problems inherent in Basic authentication while providing a
   level of authentication which is
   that it will also be publicly exposing its IEEE 802 address.

   There useful in a wide range of scenarios.

19.2  Denial of Service

   Denial of service attacks are several risks associated with exposure of IEEE 802
   addresses.  Using the IEEE 802 address:

   o  It is possible special concern to track the movement WebDAV servers.
   WebDAV plus HTTP enables denial of hardware from subnet to
      subnet.

   o  It may service attacks on every part of a
   system's resources.

   The underlying storage can be possible attacked by PUTting extremely large
   files.

   Asking for recursive operations on large collections can attack
   processing time.

   Making multiple pipelined requests on multiple connections can attack
   network connections.

   WebDAV servers need to identify the manufacturer be aware of the hardware
      running possibility of a denial of
   service attack at all levels.

19.3  Security through Obscurity

   WebDAV server.
   o  It may be possible to determine provides, through the number of each type of
      computer running WebDAV.

   Section 24.2 of this specification details an alternate PROPFIND method, a mechanism for
   generating listing
   the "node" field member resources of a UUID without using an IEEE 802
   address, which alleviates the risks associated with exposure of IEEE
   802 addresses by using an alternate source of uniqueness.

20.  IANA Considerations collection.  This document defines two namespaces, greatly diminishes the namespace
   effectiveness of property
   names, and security or privacy techniques that rely only on the namespace of WebDAV-specific XML elements used within
   property values.

   The use
   difficulty of XML namespaces means that unique WebDAV property discovering the names and
   XML elements can be quickly defined by any WebDAV user or
   application, without requiring IANA action.

   This specification defines a distinguished set of property names and
   XML elements that are understood by all network resources.  Users of
   WebDAV applications.  The
   property names and XML elements in this specification servers are all in the
   "DAV:" namespace.  In natural language, a property like the
   "creationdate" property in encouraged to use access control techniques to
   prevent unwanted access to resources, rather than depending on the "DAV:" namespace is sometimes referred
   relative obscurity of their resource names.

19.4  Privacy Issues Connected to as "DAV:creationdate" for brevity.

   This specification also defines Locks

   When submitting a URI scheme lock request a user agent may also submit an owner
   XML field giving contact information for the encoding of person taking out the
   lock
   tokens, (for those cases where a person, rather than a robot, is taking
   out the opaquelocktoken URI scheme described lock).  This contact information is stored in section 6.4.

   To ensure correct interoperation based on this specification, IANA
   must reserve a lockdiscovery
   property on the URI namespaces starting with "DAV:" resource, and with
   "opaquelocktoken:" for use can be used by other collaborators to
   begin negotiation over access to the resource.  However, in many
   cases this specification, its revisions, and
   related WebDAV specifications.

21.  Acknowledgements

   A specification such as this thrives on piercing critical review contact information can be very private, and
   withers from apathetic neglect.  The authors gratefully acknowledge
   the contributions of should not be
   widely disseminated.  Servers SHOULD limit read access to the following people, whose insights were so
   valuable
   lockdiscovery property as appropriate.  Furthermore, user agents
   SHOULD provide control over whether contact information is sent at every stage of our work.

   Contributors to RFC2518

   Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
   Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
   Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
   Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
   Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
   Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
   Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
   Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
   Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
   Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
   Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
   Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
   Richard N.  Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
   Fabio Vitali, Gregory Woodhouse,
   all, and Lauren Wood.

   Two if contact information is sent, control over exactly what
   information is sent.

19.5  Privacy Issues Connected to Properties

   Since property values are typically used to hold information such as
   the author of a document, there is the possibility that privacy
   concerns could arise stemming from this list deserve special mention.  The contributions by
   Larry Masinter have been invaluable, both in helping widespread access to a resource's
   property data.  To reduce the formation risk of inadvertent release of private
   information via properties, servers are encouraged to develop access
   control mechanisms that separate read access to the working group resource body and in patiently coaching the authors along
   read access to the
   way.  In so many ways he has set high standards we have toiled resource's properties.  This allows a user to
   meet.  The contributions
   control the dissemination of Judith Slein in clarifying their property data without overly
   restricting access to the
   requirements, and resource's contents.

19.6  Implications of XML External Entities

   XML supports a facility known as "external entities", defined in patiently reviewing draft after draft, both
   improved this specification
   section 4.2.2 of XML [11], which instruct an XML processor to
   retrieve and expanded our minds on include additional XML.  An external XML entity can be
   used to append or modify the document
   management.

   We would type declaration (DTD)
   associated with an XML document.  An external XML entity can also like be
   used to thank John Turner for developing include XML within the content of an XML document.  For non-
   validating XML, such as the XML used in this specification, including
   an external XML entity is not required by XML [11].  However, XML
   [11] does state that an XML processor may, at its discretion, include
   the external XML entity.

   External XML DTD.

   The authors of RFC2518 were Yaron Goland, Jim Whitehead, A.  Faizi,
   Steve Carter entities have no inherent trustworthiness and D.  Jensen.  Although their names had are
   subject to be removed
   due all the attacks that are endemic to IETF author count restrictions they can take credit any HTTP GET request.
   Furthermore, it is possible for an external XML entity to modify the
   majority of
   DTD, and hence affect the design final form of WebDAV.

   Additional Contributors to This Specification

   Valuable contributions to RFC2518 bis came from some already named.
   New contributors must also be gratefully acknowledged.  Julian
   Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
   specific text on an XML document, in the list worst
   case significantly modifying its semantics, or exposing the XML
   processor to the security risks discussed in meetings.  Ilya Kirnos supplied text
   for Force-Authentication header.  Joe Hildebrand contributed RFC2376 [13].
   Therefore, implementers must be aware that external XML entities
   should be treated as
   co-chair.

22.  References

22.1  Normative References

   [1]   Noble, B., Nguyen, G., Satyanarayanan, M. and R. Katz, "Mobile
         Network Tracing", RFC 2041, October 1996.

   [2]   Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
         Luotonen, A., Sink, E. and L. Stewart, "An Extension untrustworthy.  If a server implementor chooses
   not to HTTP :
         Digest Access Authentication", RFC 2069, January 1997.

   [3]   Bradner, S., "Key words handle external XML entities, it SHOULD respond to requests
   containing external entities with the precondition defined above
   (external-entities-forbidden).

   There is also the scalability risk that would accompany a widely
   deployed application which made use of external XML entities.  In
   this situation, it is possible that there would be significant
   numbers of requests for one external XML entity, potentially
   overloading any server which fields requests for the resource
   containing the external XML entity.

19.7  Risks Connected with Lock Tokens

   This specification requires the use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [4]   Alvestrand, H., "IETF Policy on Character Sets and Languages",
         BCP 18, RFC 2277, January 1998.

   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [6]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Universal  Unique Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [7]   Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
         "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC
         2518, February 1999.

   [8]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.
   (UUIDs) [9]   Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

   [10]  Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
         REC REC-xml-names-19990114, January 1999.

   [11]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

   [12]  International Organization for Standardization, "Information
         technology - Open Systems Interconnection - Remote Procedure
         Call (RPC)", ISO Standard 11578, 1996.

22.2  Informational References

   [13]  Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

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

   [15]  Slein, J., Vitali, F., Whitehead, E. lock tokens, in order to guarantee their uniqueness
   across space and D. Durand,
         "Requirements time.  The security considerations for UUIDs do not
   apply because WebDAV does not assume that lock tokens are supposed to
   be hard to guess or require integrity.  In addition, UUIDs MAY
   contain a Distributed Authoring and Versioning
         Protocol for IEEE 802 node ID, usually the World Wide Web", RFC 2291, February 1998.

   [16]  Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core
         Metadata for Resource Discovery", RFC 2413, September 1998.

   [17]  Whitehead, E. and M. Makoto, "XML Media Types", RFC 2376, July
         1998.

   [18]  Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead,
         "Versioning Extensions host address.  Since a WebDAV
   server will issue many locks over its lifetime, the use of node IDs
   might cause the WebDAV server to reveal its IEEE 802 address.
   Several risks are related to this:

   o  It is possible to track the movement of hardware from subnet to
      subnet.

   o  It may be possible to identify the manufacturer of the hardware
      running a WebDAV (Web Distributed Authoring server.

   o  It may be possible to determine the number of each type of
      computer running WebDAV.

20.  IANA Considerations

   This document defines two namespaces, the namespace of property
   names, and
         Versioning)", RFC 3253, March 2002.

   [19]  Clemm, G., Reschke, J., Sedlar, E. the namespace of WebDAV-specific XML elements used within
   property values.

   The use of XML namespaces means that unique WebDAV property names and J. Whitehead, "Web
         Distributed Authoring
   XML elements can be quickly defined by any WebDAV user or
   application, without requiring IANA action.

   This specification defines a distinguished set of property names and Versioning (WebDAV) Access Control
         Protocol", RFC 3744, May 2004.

   [20]  Krauskopf, T., Miller, J., Resnick, P.
   XML elements that are understood by all WebDAV applications.  The
   property names and XML elements in this specification are all in the
   "DAV:" namespace.  In natural language, a property like the
   "creationdate" property in the "DAV:" namespace is sometimes referred
   to as "DAV:creationdate" for brevity.

   This specification also defines a URI scheme for the encoding of lock
   tokens, the opaquelocktoken URI scheme described in section 6.4.

   To ensure correct interoperation based on this specification, IANA
   must reserve the URI namespaces starting with "DAV:" and W. Treese, "PICS 1.1
         Label Distribution -- Label Syntax with
   "opaquelocktoken:" for use by this specification, its revisions, and Communication
         Protocols", W3C REC REC-PICS-labels-961031, October 1996.

   [21]  Lagoze, C., "The Warwick Framework:
   related WebDAV specifications.

21.  Acknowledgements

   A Container Architecture
         for Diverse Sets specification such as this thrives on piercing critical review and
   withers from apathetic neglect.  The authors gratefully acknowledge
   the contributions of Metadata", July/August 1996, <http://
         www.dlib.org/dlib/july96/lagoze/07lagoze.html>.

   [22]  Cataloging Distribution Service, Library of Congress,
         Washington, DC, "Network Development and MARC Standards,
         Office, ed. 1994.  "USMARC Format for Bibliographic Data"",
         1994.

Authors' Addresses

   Lisa Dusseault
   Open Source Application Foundation
   2064 Edgewood Dr.
   Palo Alto, CA  94303
   US

   EMail: lisa@osafoundation.org

   Jason L Crawford
   IBM
   P.O.Box 704
   Yorktown Heights, NY  10598
   US

   EMail: nnjason8451@smallcue.com

Appendix A.  Previous Authors' Addresses

   Editors the following people, whose insights were so
   valuable at every stage of our work.

   Contributors to RFC2518

   Y.  Y.  Goland Microsoft Corporation One Microsoft Way Redmond, WA
   98052-6399 Email: yarong@microsoft.com

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

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

   S.  R.  Carter Novell 1555 N.  Technology Way M/S ORM F111 Orem, UT
   84097-2399 Email: srcarter@novell.com

   D.  Jensen Novell 1555

   Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
   Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
   Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
   Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
   Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
   Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
   Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
   Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
   Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
   Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
   Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
   Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
   Richard N.  Technology Way M/S ORM F111 Orem, UT
   84097-2399 Email: dcjensen@novell.com

Appendix B.  Appendices

B.1  Appendix 1 - Notes on Processing XML Elements

B.1.1  Notes on Empty XML Elements

   XML supports two mechanisms for indicating that an XML element does
   not have any content. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
   Fabio Vitali, Gregory Woodhouse, and Lauren Wood.

   Two from this list deserve special mention.  The first is to declare an XML element of contributions by
   Larry Masinter have been invaluable, both in helping the
   form <A></A>.  The second is to declare an XML element formation of
   the form
   <A/>.  The two XML elements are semantically identical.

B.1.2  Notes on Illegal XML Processing

   XML is a flexible data format that makes it easy to submit data that
   appears legal but working group and in fact is not. patiently coaching the authors along the
   way.  In so many ways he has set high standards we have toiled to
   meet.  The philosophy contributions of "Be flexible Judith Slein in
   what you accept clarifying the
   requirements, and strict in what you send" still applies, but it
   must not be applied inappropriately. patiently reviewing draft after draft, both
   improved this specification and expanded our minds on document
   management.

   We would also like to thank John Turner for developing the XML is extremely flexible in
   dealing with issues DTD.

   The authors of white space, element ordering, inserting new
   elements, etc.  This flexibility does not require extension,
   especially not in RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi,
   Steve Carter and D. Jensen.  Although their names had to be removed
   due to IETF author count restrictions they can take credit for the area
   majority of the meaning design of elements.

   There is no kindness WebDAV.

   Additional Contributors to This Specification

   Valuable contributions to RFC2518 bis came from some already named.
   New contributors must also be gratefully acknowledged.  Julian
   Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
   specific text on the list or in accepting illegal combinations of XML
   elements.  At best it will cause an unwanted result meetings.  Ilya Kirnos supplied text
   for Force-Authentication header.  Joe Hildebrand contributed as co-
   chair.

22.  References

22.1  Normative References

   [1]   Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
         Luotonen, A., Sink, E., and at worst it
   can cause real damage.

B.1.3  Example - XML Syntax Error

   The following request body L. Stewart, "An Extension to HTTP :
         Digest Access Authentication", RFC 2069, January 1997.

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

   [3]   Alvestrand, H., "IETF Policy on Character Sets and Languages",
         BCP 18, RFC 2277, January 1998.

   [4]   Yergeau, F., "UTF-8, a PROPFIND method is illegal.

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

   The definition transformation format of the propfind element only allows ISO 10646",
         RFC 2279, January 1998.

   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [6]   Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
         Jensen, "HTTP Extensions for the allprop or
   the propname element, not both.  Thus the above is an error Distributed Authoring -- WEBDAV",
         RFC 2518, February 1999.

   [7]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and must
   be responded to with a 400 (Bad Request).

   Imagine, however, that a server wanted to be "kind" T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [8]   Klyne, G. and decided to
   pick the allprop element as C. Newman, "Date and Time on the true element Internet:
         Timestamps", RFC 3339, July 2002.

   [9]   Leach, P., Mealling, M., and respond to it.  A
   client running over a bandwidth limited line who intended to execute
   a propname would be R. Salz, "A Universally Unique
         IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

   [10]  Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
         W3C REC REC-xml-names-19990114, January 1999.

   [11]  Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

22.2  Informational References

   [12]  Slein, J., Vitali, F., Whitehead, E., and D. Durand,
         "Requirements for a big surprise if the server treated Distributed Authoring and Versioning
         Protocol for the
   command as an allprop.

   Additionally, if a server were lenient World Wide Web", RFC 2291, February 1998.

   [13]  Whitehead, E. and M. Makoto, "XML Media Types", RFC 2376,
         July 1998.

   [14]  Clemm, G., Amsden, J., Ellison, T., Kaler, C., and decided to reply to this
   request, the results would vary randomly from server J.
         Whitehead, "Versioning Extensions to server, with
   some servers executing the allprop directive, WebDAV (Web Distributed
         Authoring and others executing
   the propname directive.  This reduces interoperability rather than
   increasing it.

B.1.4  Example Versioning)", RFC 3253, March 2002.

   [15]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
         Distributed Authoring and Versioning (WebDAV) Access Control
         Protocol", RFC 3744, May 2004.

Authors' Addresses

   Lisa Dusseault
   Open Source Application Foundation
   2064 Edgewood Dr.
   Palo Alto, CA  94303
   US

   Email: lisa@osafoundation.org

   Jason L Crawford
   IBM
   P.O.Box 704
   Yorktown Heights, NY  10598
   US

   Email: nnjason8451@smallcue.com

Appendix A.  Previous Authors' Addresses

   Editors of RFC2518

   Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA
   98052-6399 Email: yarong@microsoft.com

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

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

   S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT
   84097-2399 Email: srcarter@novell.com

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

Appendix B.  Appendices

B.1  Appendix 1 - Unknown Notes on Processing XML Element

   The previous example was illegal because it contained Elements

B.1.1  Notes on Empty XML Elements

   XML supports two elements mechanisms for indicating that were explicitly banned from appearing together in the propfind
   element.  However, XML is an extensible language, so one can imagine
   new elements being defined for use with propfind.  Below XML element does
   not have any content.  The first is to declare an XML element of the
   request body
   form <A></A>.  The second is to declare an XML element of a PROPFIND and, like the previous example, must be
   rejected with a 400 (Bad Request) by form
   <A/>.  The two XML elements are semantically identical.

B.1.2  Notes on Illegal XML Processing

   XML is a server flexible data format that does makes it easy to submit data that
   appears legal but in fact is not.  The philosophy of "Be flexible in
   what you accept and strict in what you send" still applies, but it
   must not
   understand the expired-props element.

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
        xmlns:E="http://www.example.com/standards/props/">
         <E:expired-props/>
        </D:propfind>

   To understand why a 400 (Bad Request) be applied inappropriately.  XML is returned let us look at the
   request body as the server unfamiliar extremely flexible in
   dealing with expired-props sees it.

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
                    xmlns:E="http://www.example.com/standards/props/">
        </D:propfind>

   As the server issues of white space, element ordering, inserting new
   elements, etc.  This flexibility does not understand the expired-props element,
   according to the WebDAV-specific XML processing rules specified require extension,
   especially not in
   Section 16, it must ignore it.  Thus the server sees an empty
   propfind, which by the definition area of the propfind element meaning of elements.

   There is illegal.

   Please note that had the extension been additive it would not
   necessarily have resulted no kindness in a 400 (Bad Request).  For example,
   imagine the accepting illegal combinations of XML
   elements.  At best it will cause an unwanted result and at worst it
   can cause real damage.

B.1.3  Example - XML Syntax Error

   The following request body for a PROPFIND: PROPFIND method is illegal.

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
                    xmlns:E="http://www.example.com/standards/props/">
        <D:propfind xmlns:D="DAV:">
         <D:allprop/>
         <D:propname/>
         <E:leave-out>*boss*</E:leave-out>
        </D:propfind>

   The previous example contains definition of the fictitious propfind element leave-out.  Its
   purpose is to prevent only allows for the return of any property whose name matches allprop or
   the submitted pattern.  If propname element, not both.  Thus the previous example were submitted above is an error and must
   be responded to with a 400 (Bad Request).

   Imagine, however, that a server unfamiliar with leave-out, the only result would wanted to be that "kind" and decided to
   pick the
   leave-out allprop element as the true element would be ignored and respond to it.  A
   client running over a bandwidth limited line who intended to execute
   a propname would be executed.

B.2  Appendix 2: UUID Node Generation

   UUIDs, as defined in ISO-11578 [12], contain a "node" field that
   contains one of the IEEE 802 addresses for a big surprise if the server machine.  As
   noted in section 18, there are several security risks associated with
   exposing a machine's IEEE 802 address.  This section provides an
   alternate mechanism for generating treated the "node" field of a UUID which
   does not employ
   command as an IEEE 802 address.  WebDAV servers MAY use allprop.

   Additionally, if a server were lenient and decided to reply to this
   algorithm for creating
   request, the node field when generating UUIDs.  The
   text in this section is originally results would vary randomly from an Internet-Draft by Paul
   Leach and Rich Salz, who are noted here to properly attribute their
   work.

   The ideal solution is server to obtain a 47 bit cryptographic quality random
   number, server, with
   some servers executing the allprop directive, and use it as others executing
   the low 47 bits of propname directive.  This reduces interoperability rather than
   increasing it.

B.1.4  Example - Unknown XML Element

   The previous example was illegal because it contained two elements
   that were explicitly banned from appearing together in the node ID, propfind
   element.  However, XML is an extensible language, so one can imagine
   new elements being defined for use with propfind.  Below is the most
   significant bit of the first octet
   request body of a PROPFIND and, like the node ID set to 1.  This bit
   is the unicast/multicast bit, which will never be set in IEEE 802
   addresses obtained from network cards; hence, there can never previous example, must be
   rejected with a
   conflict between UUIDs generated 400 (Bad Request) by machines with and without network
   cards.

   If a system server that does not have
   understand the expired-props element.

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
        xmlns:E="http://www.example.com/standards/props/">
         <E:expired-props/>
        </D:propfind>

   To understand why a primitive 400 (Bad Request) is returned let us look at the
   request body as the server unfamiliar with expired-props sees it.

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
                    xmlns:E="http://www.example.com/standards/props/">
        </D:propfind>

   As the server does not understand the expired-props element,
   according to generate cryptographic
   quality random numbers, then in most systems there are usually a
   fairly large number of sources of randomness available from which one
   can be generated.  Such sources are system specific, but often
   include:

   - the percent of memory WebDAV-specific XML processing rules specified in use -
   Section 16, it must ignore it.  Thus the size of main memory in bytes - server sees an empty
   propfind, which by the amount definition of free main memory in bytes - the size of propfind element is illegal.

   Please note that had the paging or
   swap file extension been additive it would not
   necessarily have resulted in bytes - free bytes of paging or swap file - a 400 (Bad Request).  For example,
   imagine the total
   size of user virtual address space in bytes - following request body for a PROPFIND:

        <?xml version="1.0" encoding="utf-8" ?>
        <D:propfind xmlns:D="DAV:"
                    xmlns:E="http://www.example.com/standards/props/">
         <D:propname/>
         <E:leave-out>*boss*</E:leave-out>
        </D:propfind>

   The previous example contains the total available
   user address space bytes - fictitious element leave-out.  Its
   purpose is to prevent the size return of boot disk drive in bytes - the
   free disk space on boot drive in bytes - any property whose name matches
   the current time - submitted pattern.  If the
   amount of time since previous example were submitted to a
   server unfamiliar with leave-out, the system booted - only result would be that the individual sizes of
   files
   leave-out element would be ignored and a propname would be executed.

B.2  Appendix 3: Notes on HTTP Client Compatibility

   The PUT and DELETE methods are defined in various system directories - HTTP and thus may be used
   by HTTP clients, but the creation, last read, responses to PUT and
   modification times of files DELETE have been
   extended in various system directories - the
   utilization factors of various system resources (heap, etc.) -
   current mouse cursor position - current caret position - current
   number of running processes, threads - handles this specification, so some special consideration on
   backward compatibility is worthwhile.

   First, if a PUT or IDs of the desktop
   window and DELETE request includes a header defined in this
   specification (Depth or If), the active window - server can assume the value request comes
   from a WebDAV-compatible client.  The server may even be able to
   track a number of stack pointer requests across a session and know that a client is
   a WebDAV client.  However, this kind of detection may not be
   necessary.

   Since any HTTP client ought to handle unrecognized 400-level and 500-
   level status codes as errors, the
   caller - the process following new status codes should
   not present any issues: 422, 423 and thread ID of caller - various processor
   architecture specific performance counters (instructions executed,
   cache misses, TLB misses)

   (Note that it 507. 424 is precisely also a new status
   code but it appears only in the above kinds of sources body of randomness
   that are used a Multistatus response.  So,
   for example, if a HTTP client attempted to PUT or DELETE a locked
   resource, the 423 Locked response ought to result in a generic error
   presented to seed cryptographic quality random number generators
   on systems without special hardware for their construction.)

   In addition, items such as the computer's name user.

   The 102 Processing response code is new, and indicates that the name of the
   operating system, while not strictly speaking random, will help
   differentiate
   client may wish to extend its normal timeout period.  However, the results from those obtained by other systems.

   The exact algorithm
   choice to generate extend the timeout period is entirely optional, and thus a node ID using these data
   HTTP client receiving a 102 Processing status response may time out
   anyway, with no avoidable adverse effects.

   The 207 Multistatus response is system
   specific, interesting because both the data available and the functions a HTTP client
   issuing a DELETE request to obtain
   them are often very system specific.  However, assuming that one can
   concatenate all the values from a collection might interpret a 207
   response as a success, even though it does not realize the randomness sources into resource
   is a buffer, collection and cannot understand that the DELETE operation might
   have been a cryptographic hash function such as MD5 is available, then
   any 6 bytes complete or partial failure.  Thus, a server MAY choose
   to treat a DELETE of the MD5 hash a collection as an atomic operation, and use
   either 204 No Content in case of success, or some appropriate error
   response (400 or 500 level) depending on what the buffer, with the multicast bit
   (the high bit error was.  This
   approach would maximize backward compatibility.  However, since
   interoperability tests and working group discussions have not turned
   up any instances of the first byte) set will HTTP clients issuing a DELETE request against a
   WebDAV collection, this concern may be an appropriately random
   node ID.

   Other hash functions, more theoretical than
   practical.  Thus, servers MAY instead choose to treat any such as SHA-1, can also be used.  The only
   requirement is that the result be suitably random, in the sense that
   the outputs from a set uniformly distributed inputs are themselves
   uniformly distributed, DELETE
   request as a WebDAV request, and that send a single bit change in the input can 207 Multistatus containing
   more detail about what resources could not be expected to cause half of the output bits to change. deleted.

B.3  Changes

B.3.1  Changes in -01

B.3.2  Changes in -06

   Specified that a successful LOCK request to an unmapped URL creates a
   new, empty locked resource.

   Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token
   header is needed on UNLOCK.

   Added Section 15 on preconditions and postconditions and defined a
   number of preconditions and postconditions.  The 'missing-lock-token'
   precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue.

   Added example of matching lock token to URI in the case of a
   collection lock in the If header section.

   Removed ability for Destination header to take "abs_path" in order to
   keep consistent with other places where client provides URLs (If
   header, href element
   keep consistent with other places where client provides URLs (If
   header, href element in request body)

   Clarified the href element - that it generally contains HTTP URIs but
   not always.

   Attempted to fix the BNF describing the If header to allow commas

   Clarified presence of Depth header on LOCK refresh requests.

B.3.2  Changes in -07

   Added text to "COPY and the Overwrite Header" section to resolve
   issue OVERWRITE_DELETE_ALL_TOO_STRONG.

   Added text to "HTTP URL Namespace Model" section to provide more
   clarification and examples on what consistency means and what is not
   required, to resolve issue CONSISTENCY.

   Resolve DEFINE_PRINCIPAL by importing definition of principal from
   RFC3744.

   Resolve INTEROP_DELETE_AND_MULTISTATUS by adding appendix 3
   discussing backward-compatibility concerns.

   Resolve DATE_FORMAT_GETLASTMODIFIED by allowing only rfc1123-date,
   not HTTP-date for getlastmodified.

   Resolve COPY_INTO_YOURSELF_CLARIFY by adding sentence to first para.
   of COPY section.

   Confirm that WHEN_TO_MULTISTATUS_FOR_DELETE_1 and
   WHEN_TO_MULTISTATUS_FOR_DELETE_2 are resolved and tweak language in
   DELETE section slightly to be clearly consistent.

   More text clarifications to deal with several of the issues in
   LOCK_ISSUES.  This may not completely resolve that set but we need
   feedback from the originator of the issues at this point.

   Resolved COPY_INTO_YOURSELF_CLARIFY with new sentence in Copy For
   Collections section.

   Double checked that LEVEL_OR_CLASS is resolved by using class, not
   level.

   Further work to resolve IF_AND_AUTH and LOCK_SEMANTICS, clarifying
   text on using locks and being authenticated.

   Added notes on use of 503 status response to resolve issue
   PROPFIND_INFINITY

   Removed section on other uses of Metadata (and associated references)

   Added reference to RFC4122 for lock tokens and removed section on
   generating UUIDs

   Explained that even with language variation, a property has only one
   value (section 4.5).

   Added section on lock owner (7.1) and what to do if lock requested by
   unauthenticated user

   Removed section 4.2 -- justification on why to have metadata, not
   needed now

   Removed paragraph in request body)

   Clarified the href element - that it generally contains HTTP URIs section 5.2 about collections with resource type
   "DAV:collection" but which are non-WebDAV compliant -- not always.

   Attempted to fix the BNF describing the If header to allow commas
   Clarified presence of Depth header on LOCK refresh requests.
   implemented.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

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

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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 at
   ietf-ipr@ietf.org.

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

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.