add sabre (1.8.x) via composer in the !@#$ place it wants to be

1 files changed, 5267 insertions, 0 deletions

diff --git a/vendor/sabre/dav/docs/rfc2518.txt b/vendor/sabre/dav/docs/rfc2518.txt
new file mode 100644
index 000000000..81d40387b
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc2518.txt
@@ -0,0 +1,5267 @@
+
+
+
+
+
+
+Network Working Group                                        Y. Goland
+Request for Comments: 2518                                   Microsoft
+Category: Standards Track                                 E. Whitehead
+                                                             UC Irvine
+                                                              A. Faizi
+                                                              Netscape
+                                                             S. Carter
+                                                                Novell
+                                                             D. Jensen
+                                                                Novell
+                                                         February 1999
+
+
+          HTTP Extensions for Distributed Authoring -- WEBDAV
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document specifies 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).
+
+Table of Contents
+
+   ABSTRACT............................................................1
+   1 INTRODUCTION .....................................................5
+   2 NOTATIONAL CONVENTIONS ...........................................7
+   3 TERMINOLOGY ......................................................7
+   4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
+   4.1  The Resource Property Model ...................................8
+   4.2  Existing Metadata Proposals ...................................8
+   4.3  Properties and HTTP Headers ...................................9
+   4.4  Property Values ...............................................9
+   4.5  Property Names ...............................................10
+   4.6  Media Independent Links ......................................10
+   5 COLLECTIONS OF WEB RESOURCES ....................................11
+
+
+
+Goland, et al.              Standards Track                     [Page 1]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   5.1  HTTP URL Namespace Model .....................................11
+   5.2  Collection Resources .........................................11
+   5.3  Creation and Retrieval of Collection Resources ...............12
+   5.4  Source Resources and Output Resources ........................13
+   6 LOCKING .........................................................14
+   6.1  Exclusive Vs. Shared Locks ...................................14
+   6.2  Required Support .............................................16
+   6.3  Lock Tokens ..................................................16
+   6.4  opaquelocktoken Lock Token URI Scheme ........................16
+    6.4.1  Node Field Generation Without the IEEE 802 Address ........17
+   6.5  Lock Capability Discovery ....................................19
+   6.6  Active Lock Discovery ........................................19
+   6.7  Usage Considerations .........................................19
+   7 WRITE LOCK ......................................................20
+   7.1  Methods Restricted by Write Locks ............................20
+   7.2  Write Locks and Lock Tokens ..................................20
+   7.3  Write Locks and Properties ...................................20
+   7.4  Write Locks and Null Resources ...............................21
+   7.5  Write Locks and Collections ..................................21
+   7.6  Write Locks and the If Request Header ........................22
+    7.6.1  Example - Write Lock ......................................22
+   7.7  Write Locks and COPY/MOVE ....................................23
+   7.8  Refreshing Write Locks .......................................23
+   8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
+   8.1  PROPFIND .....................................................24
+    8.1.1  Example - Retrieving Named Properties .....................25
+    8.1.2  Example - Using allprop to Retrieve All Properties ........26
+    8.1.3  Example - Using propname to Retrieve all Property Names ...29
+   8.2  PROPPATCH ....................................................31
+    8.2.1  Status Codes for use with 207 (Multi-Status) ..............31
+    8.2.2  Example - PROPPATCH .......................................32
+   8.3  MKCOL Method .................................................33
+    8.3.1  Request ...................................................33
+    8.3.2  Status Codes ..............................................33
+    8.3.3  Example - MKCOL ...........................................34
+   8.4  GET, HEAD for Collections ....................................34
+   8.5  POST for Collections .........................................35
+   8.6  DELETE .......................................................35
+    8.6.1  DELETE for Non-Collection Resources .......................35
+    8.6.2  DELETE for Collections ....................................36
+   8.7  PUT ..........................................................36
+    8.7.1  PUT for Non-Collection Resources ..........................36
+    8.7.2  PUT for Collections .......................................37
+   8.8  COPY Method ..................................................37
+    8.8.1  COPY for HTTP/1.1 resources ...............................37
+    8.8.2  COPY for Properties .......................................38
+    8.8.3  COPY for Collections ......................................38
+    8.8.4  COPY and the Overwrite Header .............................39
+
+
+
+Goland, et al.              Standards Track                     [Page 2]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+    8.8.5  Status Codes ..............................................39
+    8.8.6  Example - COPY with Overwrite .............................40
+    8.8.7  Example - COPY with No Overwrite ..........................40
+    8.8.8  Example - COPY of a Collection ............................41
+   8.9  MOVE Method ..................................................42
+    8.9.1  MOVE for Properties .......................................42
+    8.9.2  MOVE for Collections ......................................42
+    8.9.3  MOVE and the Overwrite Header .............................43
+    8.9.4  Status Codes ..............................................43
+    8.9.5  Example - MOVE of a Non-Collection ........................44
+    8.9.6  Example - MOVE of a Collection ............................44
+   8.10 LOCK Method ..................................................45
+    8.10.1 Operation .................................................46
+    8.10.2 The Effect of Locks on Properties and Collections .........46
+    8.10.3 Locking Replicated Resources ..............................46
+    8.10.4 Depth and Locking .........................................46
+    8.10.5 Interaction with other Methods ............................47
+    8.10.6 Lock Compatibility Table ..................................47
+    8.10.7 Status Codes ..............................................48
+    8.10.8 Example - Simple Lock Request .............................48
+    8.10.9 Example - Refreshing a Write Lock .........................49
+    8.10.10 Example - Multi-Resource Lock Request ....................50
+   8.11 UNLOCK Method ................................................51
+    8.11.1 Example - UNLOCK ..........................................52
+   9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
+   9.1  DAV Header ...................................................52
+   9.2  Depth Header .................................................52
+   9.3  Destination Header ...........................................54
+   9.4  If Header ....................................................54
+    9.4.1  No-tag-list Production ....................................55
+    9.4.2  Tagged-list Production ....................................55
+    9.4.3  not Production ............................................56
+    9.4.4  Matching Function .........................................56
+    9.4.5  If Header and Non-DAV Compliant Proxies ...................57
+   9.5  Lock-Token Header ............................................57
+   9.6  Overwrite Header .............................................57
+   9.7  Status-URI Response Header ...................................57
+   9.8  Timeout Request Header .......................................58
+   10  STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
+   10.1 102 Processing ...............................................59
+   10.2 207 Multi-Status .............................................59
+   10.3 422 Unprocessable Entity .....................................60
+   10.4 423 Locked ...................................................60
+   10.5 424 Failed Dependency ........................................60
+   10.6 507 Insufficient Storage .....................................60
+   11  MULTI-STATUS RESPONSE .........................................60
+   12  XML ELEMENT DEFINITIONS .......................................61
+   12.1 activelock XML Element .......................................61
+
+
+
+Goland, et al.              Standards Track                     [Page 3]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+    12.1.1 depth XML Element .........................................61
+    12.1.2 locktoken XML Element .....................................61
+    12.1.3 timeout XML Element .......................................61
+   12.2 collection XML Element .......................................62
+   12.3 href XML Element .............................................62
+   12.4 link XML Element .............................................62
+    12.4.1 dst XML Element ...........................................62
+    12.4.2 src XML Element ...........................................62
+   12.5 lockentry XML Element ........................................63
+   12.6 lockinfo XML Element .........................................63
+   12.7 lockscope XML Element ........................................63
+    12.7.1 exclusive XML Element .....................................63
+    12.7.2 shared XML Element ........................................63
+   12.8 locktype XML Element .........................................64
+    12.8.1 write XML Element .........................................64
+   12.9 multistatus XML Element ......................................64
+    12.9.1 response XML Element ......................................64
+    12.9.2 responsedescription XML Element ...........................65
+   12.10 owner XML Element ...........................................65
+   12.11 prop XML element ............................................66
+   12.12 propertybehavior XML element ................................66
+    12.12.1 keepalive XML element ....................................66
+    12.12.2 omit XML element .........................................67
+   12.13 propertyupdate XML element ..................................67
+    12.13.1 remove XML element .......................................67
+    12.13.2 set XML element ..........................................67
+   12.14 propfind XML Element ........................................68
+    12.14.1 allprop XML Element ......................................68
+    12.14.2 propname XML Element .....................................68
+   13  DAV PROPERTIES ................................................68
+   13.1 creationdate Property ........................................69
+   13.2 displayname Property .........................................69
+   13.3 getcontentlanguage Property ..................................69
+   13.4 getcontentlength Property ....................................69
+   13.5 getcontenttype Property ......................................70
+   13.6 getetag Property .............................................70
+   13.7 getlastmodified Property .....................................70
+   13.8 lockdiscovery Property .......................................71
+    13.8.1 Example - Retrieving the lockdiscovery Property ...........71
+   13.9 resourcetype Property ........................................72
+   13.10 source Property .............................................72
+    13.10.1 Example - A source Property ..............................72
+   13.11 supportedlock Property ......................................73
+    13.11.1 Example - Retrieving the supportedlock Property ..........73
+   14  INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
+   15  DAV COMPLIANCE CLASSES ........................................75
+   15.1 Class 1 ......................................................75
+   15.2 Class 2 ......................................................75
+
+
+
+Goland, et al.              Standards Track                     [Page 4]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   16  INTERNATIONALIZATION CONSIDERATIONS ...........................76
+   17  SECURITY CONSIDERATIONS .......................................77
+   17.1 Authentication of Clients ....................................77
+   17.2 Denial of Service ............................................78
+   17.3 Security through Obscurity ...................................78
+   17.4 Privacy Issues Connected to Locks ............................78
+   17.5 Privacy Issues Connected to Properties .......................79
+   17.6 Reduction of Security due to Source Link .....................79
+   17.7 Implications of XML External Entities ........................79
+   17.8 Risks Connected with Lock Tokens .............................80
+   18  IANA CONSIDERATIONS ...........................................80
+   19  INTELLECTUAL PROPERTY .........................................81
+   20  ACKNOWLEDGEMENTS ..............................................82
+   21  REFERENCES ....................................................82
+   21.1 Normative References .........................................82
+   21.2 Informational References .....................................83
+   22  AUTHORS' ADDRESSES ............................................84
+   23  APPENDICES ....................................................86
+   23.1 Appendix 1 - WebDAV Document Type Definition .................86
+   23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
+   23.3 Appendix 3 - Notes on Processing XML Elements ................89
+    23.3.1 Notes on Empty XML Elements ...............................89
+    23.3.2 Notes on Illegal XML Processing ...........................89
+   23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
+    23.4.1 Introduction ..............................................92
+    23.4.2 Meaning of Qualified Names ................................92
+   24  FULL COPYRIGHT STATEMENT ......................................94
+
+
+
+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: The ability to create sets of documents and to retrieve
+   a hierarchical membership listing (like a directory listing in a file
+   system).
+
+
+
+
+
+
+Goland, et al.              Standards Track                     [Page 5]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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 and
+   move Web resources.
+
+   Requirements and rationale for these operations are described in a
+   companion document, "Requirements for a Distributed Authoring and
+   Versioning Protocol for the World Wide Web" [RFC2291].
+
+   The sections below provide a detailed introduction to resource
+   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
+   described in section 8, "HTTP Methods for Distributed Authoring".
+
+   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 Extensible Markup Language (XML) [REC-XML]
+   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. As a rule of thumb,
+   parameters are encoded in XML entity bodies when they have unbounded
+   length, or when they may be shown to a human user and hence require
+   encoding in an ISO 10646 character set.  Otherwise, parameters are
+   encoded within HTTP headers.  Section 9 describes the new HTTP
+   headers used with WebDAV methods.
+
+   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.
+
+   XML elements used in this specification are defined in section 12.
+
+   The XML namespace extension (Appendix 4) 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.
+
+   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.
+   New status codes developed for the WebDAV methods are defined in
+   section 10.  Since some WebDAV methods may operate over many
+
+
+
+Goland, et al.              Standards Track                     [Page 6]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   resources, the Multi-Status response has been introduced to return
+   status information for multiple resources.  The Multi-Status response
+   is described in section 11.
+
+   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. Section 13 defines the properties used within the
+   WebDAV specification.
+
+   Finishing off the specification are sections on what it means to be
+   compliant with this specification (section 15), on
+   internationalization support (section 16), and on security (section
+   17).
+
+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 [RFC2068].  Since
+   this augmented BNF uses the basic production rules provided in
+   section 2.2 of [RFC2068], 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 RFC 2119 [RFC2119].
+
+3  Terminology
+
+   URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
+   respectively. These terms (and the distinction between them) are
+   defined in [RFC2396].
+
+   Collection - A resource that contains a set of URIs, termed member
+   URIs, which identify member resources and meets the requirements in
+   section 5 of this specification.
+
+   Member URI - A URI which is a member of the set of URIs contained by
+   a collection.
+
+   Internal Member URI - A Member URI that is immediately relative to
+   the URI of the collection (the definition of immediately relative is
+   given in section 5.2).
+
+   Property - A name/value pair that contains descriptive information
+   about a resource.
+
+
+
+
+
+Goland, et al.              Standards Track                     [Page 7]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Live Property - 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.
+
+   Null Resource - A resource which responds with a 404 (Not Found) to
+   any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
+   A NULL resource MUST NOT appear as a member of its parent collection.
+
+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 for the discovery
+   of what authors have written which documents.
+
+   The DAV property model consists of name/value pairs.  The name of a
+   property identifies the property's syntax and semantics, and provides
+   an address by which to refer to its syntax and semantics.
+
+   There are two categories 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 [REC-PICS], PICS-NG, XML, Web Collections, and several
+   proposals on representing relationships within HTML. Work on PICS-NG
+
+
+
+Goland, et al.              Standards Track                     [Page 8]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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 Property Values
+
+   The value of a property when expressed in XML MUST be well formed.
+
+   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,
+
+
+
+Goland, et al.              Standards Track                     [Page 9]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   using the "xml:lang" attribute, handles cases where the same
+   character set is employed by multiple human languages.
+
+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 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 [RFC2396], 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.
+
+4.6 Media Independent Links
+
+   Although HTML resources support links to other resources, the Web
+   needs more general support for links between resources of any media
+   type (media types are also known as MIME types, or content types).
+   WebDAV provides such links. A WebDAV link is a special type of
+   property value, formally defined in section 12.4, that allows typed
+   connections to be established between resources of any media type.
+   The property value consists of source and destination Uniform
+   Resource Identifiers (URIs); the property name identifies the link
+   type.
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 10]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+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 [RFC2068] and [RFC2396], 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 URIs and a set of properties, but which may have
+   additional state such as entity bodies returned by GET.  An internal
+   member URI MUST be immediately relative to a base URI of the
+   collection.  That is, the internal member URI is equal to a
+   containing collection's URI 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].
+
+   Any given internal member URI MUST only belong to the collection
+   once, i.e., it is illegal to have multiple instances of the same URI
+   in a collection.  Properties defined on collections behave exactly as
+   do properties on non-collection resources.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 11]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   For all WebDAV compliant resources A and B, identified by URIs U and
+   V, for which U is immediately relative to V, B MUST be a collection
+   that has U as an internal member URI. So, if the resource with URL
+   http://foo.com/bar/blah is WebDAV compliant and if the resource with
+   URL http://foo.com/bar/ is WebDAV compliant then the resource with
+   URL http://foo.com/bar/ must be a collection and must contain URL
+   http://foo.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://foo.com/bar/blah is not WebDAV compliant and the URL
+   http://foo.com/bar/ identifies a collection then URL
+   http://foo.com/bar/blah may or may not be an internal member of the
+   collection with URL http://foo.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 trailing slash is
+   automatically appended.  Due to this, a resource may accept a URI
+   without a trailing "/" to point to a collection. In this case it
+   SHOULD return a content-location header in the response pointing to
+   the URI ending with the "/".  For example, if a client invokes a
+   method on http://foo.bar/blah (no trailing slash), the resource
+   http://foo.bar/blah/ (trailing slash) may respond as if the operation
+   were invoked on it, and should return a content-location header with
+   http://foo.bar/blah/ in it.  In general clients SHOULD use the "/"
+   form of collection names.
+
+   A resource MAY be a collection but not be WebDAV compliant.  That is,
+   the resource may comply with all the rules 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 DAV header containing the value "1" on an OPTIONS response.
+
+5.3 Creation and Retrieval of Collection Resources
+
+   This document specifies the MKCOL method to create new collection
+   resources, rather than using the existing HTTP/1.1 PUT or POST
+   method, for the following reasons:
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 12]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   In HTTP/1.1, the PUT method is defined to store the request body at
+   the location specified by the Request-URI.  While a description
+   format for a collection can readily be constructed for use with PUT,
+   the implications of sending such a description to the server are
+   undesirable.  For example, if a description of a collection that
+   omitted some existing resources were PUT to a server, this might be
+   interpreted as a command to remove those members.  This would extend
+   PUT to perform DELETE functionality, which is undesirable since it
+   changes the semantics of PUT, and makes it difficult to control
+   DELETE functionality with an access control scheme based on methods.
+
+   While the POST method is sufficiently open-ended that a "create a
+   collection" POST command could be constructed, this is undesirable
+   because it would be difficult to separate access control for
+   collection creation from other uses of POST.
+
+   The exact definition of the behavior of GET and PUT on collections is
+   defined later in this document.
+
+5.4 Source Resources and Output Resources
+
+   For many resources, the entity returned by a GET method exactly
+   matches the persistent state of the resource, for example, a GIF file
+   stored on a disk.  For this simple case, the URI at which a resource
+   is accessed is identical to the URI at which the source (the
+   persistent state) of the resource is accessed.  This is also the case
+   for HTML source files that are not processed by the server prior to
+   transmission.
+
+   However, the server can sometimes process HTML resources before they
+   are transmitted as a return entity body.  For example, a server-
+   side-include directive within an HTML file might instruct a server to
+   replace the directive with another value, such as the current date.
+   In this case, what is returned by GET (HTML plus date) differs from
+   the persistent state of the resource (HTML plus directive).
+   Typically there is no way to access the HTML resource containing the
+   unprocessed directive.
+
+   Sometimes the entity returned by GET is the output of a data-
+   producing process that is described by one or more source resources
+   (that may not even have a location 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 a "finger" gateway process that maps part
+   of the namespace of a server into finger requests, such as
+   http://www.foo.bar.org/finger_gateway/user@host.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 13]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   In the absence of distributed authoring capabilities, it is
+   acceptable to have no mapping of source resource(s) to the URI
+   namespace. In fact, preventing access to the source resource(s) has
+   desirable security benefits.  However, if remote editing of the
+   source resource(s) is desired, the source resource(s) should be given
+   a location in the URI namespace.  This source location should not be
+   one of the locations at which the generated output is retrievable,
+   since in general it is impossible for the server to differentiate
+   requests for source resources from requests for process output
+   resources.  There is often a many-to-many relationship between source
+   resources and output resources.
+
+   On WebDAV compliant servers the URI of the source resource(s) may be
+   stored in a link on the output resource with type DAV:source (see
+   section 13.10 for a description of the source link property).
+   Storing the source URIs in links on the output resources places the
+   burden of discovering the source on the authoring client.  Note that
+   the value of a source link is not guaranteed to point to the correct
+   source.  Source links may break or incorrect values may be entered.
+   Also note that not all servers will allow the client to set the
+   source link value.  For example a server which generates source links
+   on the fly for its CGI files will most likely not allow a client to
+   set the source link value.
+
+6  Locking
+
+   The ability to lock a resource provides a mechanism for serializing
+   access to that resource.  Using a lock, an authoring client can
+   provide a reasonable guarantee that another principal will not modify
+   a resource while it is being edited.  In this way, a client can
+   prevent the "lost update" problem.
+
+   This specification allows locks to vary over two client-specified
+   parameters, the number of principals involved (exclusive vs. shared)
+   and the type of access to be granted. This document defines locking
+   for only one access type, write. However, the syntax is extensible,
+   and permits 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.  This is a lock
+   where the access right in question is only granted to a single
+   principal.  The need for this arbitration results from a desire to
+   avoid having to merge results.
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 14]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   However, there are times when the goal of a lock is not to exclude
+   others from exercising an access right but rather to provide a
+   mechanism for principals to indicate that they intend to exercise
+   their access rights.  Shared locks are provided for this case.  A
+   shared lock allows multiple principals to receive a lock.  Hence any
+   principal with appropriate access can get the lock.
+
+   With shared locks there are two trust sets that affect 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 the
+   resource, the set of principals who have taken out a shared lock also
+   must trust each other, creating a (typically) smaller trust set
+   within the access permission write set.
+
+   Starting with every possible principal on the Internet, in most
+   situations the vast majority of these principals will not have write
+   access to a given resource.  Of the small number who do have write
+   access, some principals may decide to guarantee their edits are free
+   from overwrite conflicts by using exclusive write locks.  Others may
+   decide they trust their collaborators will not overwrite their work
+   (the potential set of collaborators being the set of principals who
+   have write permission) and use a shared lock, which informs their
+   collaborators that a principal may be working on the resource.
+
+   The WebDAV extensions to HTTP do not need to provide all of the
+   communications paths necessary for principals to coordinate their
+   activities.  When using shared locks, principals may use any out of
+   band communication channel to coordinate their work (e.g., face-to-
+   face interaction, written notes, post-it notes on the screen,
+   telephone conversation, Email, etc.)  The intent of a shared lock is
+   to let collaborators know who else may be working on a resource.
+
+   Shared locks are included because experience from web distributed
+   authoring systems has indicated that exclusive locks are often too
+   rigid.  An exclusive lock is used 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, for
+   example when a program crashes, or when a lock owner leaves without
+   unlocking a resource.  While both timeouts 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.
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 15]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+6.2 Required Support
+
+   A WebDAV compliant server is not required to support locking in any
+   form.  If the server does support locking it may choose to support
+   any combination of exclusive and shared locks for any access types.
+
+   The reason for this flexibility is that locking policy strikes to the
+   very heart of the 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 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 specification leaves
+   locking as the sole axis of negotiation within WebDAV.
+
+6.3 Lock Tokens
+
+   A lock token is a type of state token, represented as a URI, which
+   identifies a particular lock.  A lock token is returned by every
+   successful LOCK operation in the lockdiscovery property in the
+   response body, and can also be found through lock discovery on a
+   resource.
+
+   Lock token URIs MUST be unique across all resources for all time.
+   This uniqueness constraint allows lock tokens to be submitted across
+   resources and servers without fear of confusion.
+
+   This specification provides a lock token URI scheme called
+   opaquelocktoken that meets the uniqueness requirements.  However
+   resources are free to return any URI scheme so long as it meets the
+   uniqueness requirements.
+
+   Having a lock token provides no special access rights. Anyone can
+   find out anyone else's lock token by performing lock discovery.
+   Locks MUST be enforced based upon whatever authentication mechanism
+   is used by the server, not based on the secrecy of the token values.
+
+6.4 opaquelocktoken Lock Token URI Scheme
+
+   The opaquelocktoken URI scheme is designed to be unique across all
+   resources for all time.  Due to this uniqueness quality, a client may
+   submit an opaque lock token in an If header on a resource other than
+   the one that returned it.
+
+   All resources MUST recognize the opaquelocktoken scheme and, at
+   minimum, recognize that the lock token does not refer to an
+   outstanding lock on the resource.
+
+
+
+Goland, et al.              Standards Track                    [Page 16]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   In order to guarantee uniqueness across all resources for all time
+   the opaquelocktoken requires the use of the Universal Unique
+   Identifier (UUID) mechanism, as described in [ISO-11578].
+
+   Opaquelocktoken generators, however, have a choice of how they create
+   these tokens.  They can either generate a new UUID for every lock
+   token they create or they can create a single UUID  and then add
+   extension characters.  If the second method is selected then the
+   program generating the extensions MUST guarantee that the same
+   extension will never be used twice with the associated UUID.
+
+   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
+   production is the string representation of a UUID, as defined in
+   [ISO-11578]. Note that white space (LWS) is not allowed between
+   elements of this production.
+
+   Extension = path  ; path is defined in section 3.2.1 of RFC 2068
+   [RFC2068]
+
+6.4.1 Node Field Generation Without the IEEE 802 Address
+
+   UUIDs, as defined in [ISO-11578], contain a "node" field that
+   contains one of the IEEE 802 addresses for the server machine.  As
+   noted in section 17.8, there are several security risks associated
+   with exposing a machine's IEEE 802 address. This section provides an
+   alternate mechanism for generating the "node" field of a UUID which
+   does not employ an IEEE 802 address.  WebDAV servers MAY use this
+   algorithm for creating the node field when generating UUIDs.  The
+   text in this section is originally from an Internet-Draft by Paul
+   Leach and Rich Salz, who are noted here to properly attribute their
+   work.
+
+   The ideal solution is to obtain a 47 bit cryptographic quality random
+   number, and use it as the low 47 bits of the node ID, with the most
+   significant bit of the first octet of 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 be a
+   conflict between UUIDs generated by machines with and without network
+   cards.
+
+   If a system does not have a primitive 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:
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 17]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+     - the percent of memory in use
+     - the size of main memory in bytes
+     - the amount of free main memory in bytes
+     - the size of the paging or swap file in bytes
+     - free bytes of paging or swap file
+     - the total size of user virtual address space in bytes
+     - the total available user address space bytes
+     - the size of boot disk drive in bytes
+     - the free disk space on boot drive in bytes
+     - the current time
+     - the amount of time since the system booted
+     - the individual sizes of files in various system directories
+     - the creation, last read, and modification times of files 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 or IDs of the desktop window and the active window
+     - the value of stack pointer of the caller
+     - the process and thread ID of caller
+     - various processor architecture specific performance counters
+       (instructions executed, cache misses, TLB misses)
+
+   (Note that it is precisely the above kinds of sources of randomness
+   that are used to seed cryptographic quality random number generators
+   on systems without special hardware for their construction.)
+
+   In addition, items such as the computer's name and the name of the
+   operating system, while not strictly speaking random, will help
+   differentiate the results from those obtained by other systems.
+
+   The exact algorithm to generate a node ID using these data is system
+   specific, because both the data available and the functions to obtain
+   them are often very system specific. However, assuming that one can
+   concatenate all the values from the randomness sources into a buffer,
+   and that a cryptographic hash function such as MD5 is available, then
+   any 6 bytes of the MD5 hash of the buffer, with the multicast bit
+   (the high bit of the first byte) set will be an appropriately random
+   node ID.
+
+   Other hash functions, 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, and that a single bit change in the input can
+   be expected to cause half of the output bits to change.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 18]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+6.5 Lock Capability Discovery
+
+   Since server lock support is optional, a client trying to lock a
+   resource on a server can either try the lock and 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.
+   Lock capability discovery differs from discovery of supported access
+   control types, since there may be access control types without
+   corresponding lock types.  A client can determine what lock types the
+   server supports by retrieving the supportedlock property.
+
+   Any DAV compliant resource that supports the LOCK method MUST support
+   the supportedlock property.
+
+6.6 Active Lock Discovery
+
+   If another principal locks a resource that a principal wishes to
+   access, it is useful for the second principal 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, and where available, provides their lock token.
+
+   Any DAV compliant resource that supports the LOCK method MUST support
+   the lockdiscovery property.
+
+6.7 Usage Considerations
+
+   Although the locking mechanisms specified here provide some help in
+   preventing lost updates, they cannot guarantee 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 is an HTTP client rather than a WebDAV client,
+   and 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 a GET and begins editing.
+   Client B finishes editing, performs a PUT, then an UNLOCK.
+   Client A performs a PUT, overwriting and losing all 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 that do not
+   comprehend locking.  Second, it cannot require servers to support
+   locking because of the variety of repository implementations, some of
+   which rely on reservations and merging rather than on locking.
+   Finally, being stateless, it cannot enforce a sequence of operations
+   like LOCK / GET / PUT / UNLOCK.
+
+
+
+Goland, et al.              Standards Track                    [Page 19]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   WebDAV servers that support locking can reduce the likelihood 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 and HTTP 1.1 clients from modifying
+   resources.
+
+   WebDAV clients can be good citizens by using a lock / retrieve /
+   write /unlock sequence of operations (at least by default) whenever
+   they interact with a WebDAV server that supports locking.
+
+   HTTP 1.1 clients can 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 to prevent overwrites by
+   implementing client-side procedures requiring locking before
+   modifying WebDAV resources.
+
+7  Write Lock
+
+   This section describes the semantics specific to the write lock type.
+   The write lock is a specific instance of a lock type, and is the only
+   lock type described in this specification.
+
+7.1 Methods Restricted by Write Locks
+
+   A write lock MUST prevent a principal without the lock from
+   successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
+   DELETE, or MKCOL on the locked resource.  All other current methods,
+   GET in particular, function independently of the lock.
+
+   Note, however, that as new methods are created it will be necessary
+   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 the generation of a unique lock token associated with the
+   requesting principal.  Thus if five principals have a shared write
+   lock on the same resource there will 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 a
+   resource it is still possible for the values of live properties to
+   change, even while locked, due to the requirements of their schemas.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 20]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Only dead properties and live properties defined to respect locks are
+   guaranteed not to change while write locked.
+
+7.4 Write Locks and Null Resources
+
+   It is possible to assert a write lock on a null resource in order to
+   lock the name.
+
+   A write locked null resource, referred to as a lock-null resource,
+   MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
+   any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
+   LOCK, and UNLOCK.  A lock-null resource MUST appear as a member of
+   its parent collection.  Additionally the lock-null resource MUST have
+   defined on it all mandatory DAV properties.  Most of these
+   properties, such as all the get* properties, will have no value as a
+   lock-null resource does not support the GET method.  Lock-Null
+   resources MUST have defined values for lockdiscovery and
+   supportedlock properties.
+
+   Until a method such as PUT or MKCOL is successfully executed on the
+   lock-null resource the resource MUST stay in the lock-null state.
+   However, once a PUT or MKCOL is successfully executed on a lock-null
+   resource the resource ceases to be in the lock-null state.
+
+   If the resource is unlocked, for any reason, without a PUT, MKCOL, or
+   similar method having been successfully executed upon it then the
+   resource MUST return to the null state.
+
+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 URIs of the collection by non-lock owners.  As a consequence,
+   when a principal issues a PUT or POST request to create a new
+   resource under a URI which needs to be an internal member of a write
+   locked collection to maintain HTTP namespace consistency, or issues a
+   DELETE to remove a resource which has a URI which is an existing
+   internal member URI of a write locked collection, this request MUST
+   fail if the principal does not have a write lock on the collection.
+
+   However, if a write lock request is issued to a collection containing
+   member URIs identifying resources that are currently locked in a
+   manner which conflicts with the write lock, the request MUST fail
+   with a 423 (Locked) status code.
+
+   If a lock owner causes the URI of a resource to be added as an
+   internal member URI of a locked collection then the new resource MUST
+   be automatically added to the lock.  This is the only mechanism that
+
+
+
+Goland, et al.              Standards Track                    [Page 21]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   allows a resource to be added to a write lock.  Thus, for example, if
+   the collection /a/b/ is write locked and the resource /c is moved to
+   /a/b/c then resource /a/b/c will be added to the write lock.
+
+7.6 Write Locks and the If Request Header
+
+   If a user agent is not required to have knowledge about a lock when
+   requesting an operation 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 of the
+   lock taken out by Program A, yet performs a PUT to the 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 A's credential, is allowed to
+   perform the PUT.  However, had program B known about the lock, it
+   would not have overwritten the resource, preferring instead to
+   present a dialog box describing the conflict to the user.  Due to
+   this scenario, a mechanism is needed to prevent different programs
+   from accidentally ignoring locks taken out by other programs with the
+   same authorization.
+
+   In order to prevent these collisions a lock token MUST be submitted
+   by an authorized principal in the If header for all locked resources
+   that a method may interact with or the method MUST fail.  For
+   example, if a resource is to be moved and both the source and
+   destination are locked then two lock tokens must be submitted, one
+   for the source and the other for the destination.
+
+7.6.1 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 lock on the
+   destination.  This is because the source resource is not modified by
+   a COPY, and hence unaffected by the write lock. In this example, user
+   agent authentication has previously occurred via a mechanism outside
+   the scope of the HTTP protocol, in the underlying transport layer.
+
+
+
+Goland, et al.              Standards Track                    [Page 22]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+7.7 Write Locks and 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 "Depth: infinity",
+   then the resource will be added to the lock.
+
+   A successful MOVE request on a write locked resource MUST NOT move
+   the write lock with the resource. However, the resource is subject to
+   being added to an existing lock at the destination, as specified in
+   section 7.5. For example, if the MOVE makes the resource a child of a
+   collection that is locked with "Depth: infinity", then the 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 scope of the same lock (e.g., within the namespace tree
+   covered by the lock), the moved resource will again be a added to the
+   lock. In both these examples, as specified in section 7.6, an If
+   header must be submitted containing a lock token for both the source
+   and destination.
+
+7.8 Refreshing Write Locks
+
+   A client MUST NOT submit the same write lock request twice.  Note
+   that a client is always aware it is resubmitting the same lock
+   request because it must include the lock token in the If header in
+   order to make the request for a resource that is already locked.
+
+   However, a client may submit a LOCK method with an If header but
+   without a body.  This form of LOCK MUST only be used to "refresh" a
+   lock.  Meaning, at minimum, that any timers associated with the lock
+   MUST be re-set.
+
+   A server may return a 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.
+
+   If an error is received in response to a refresh LOCK request the
+   client SHOULD assume that the lock was not refreshed.
+
+8  HTTP Methods for Distributed Authoring
+
+   The following new HTTP methods use XML as a request and response
+   format.  All DAV compliant clients and resources MUST use XML parsers
+   that are compliant with [REC-XML].  All XML used in either requests
+   or responses MUST be, at minimum, well formed.  If a server receives
+
+
+
+Goland, et al.              Standards Track                    [Page 23]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   ill-formed XML in a request it MUST reject the entire request with a
+   400 (Bad Request).  If a client receives ill-formed XML in a response
+   then it MUST NOT assume anything about the outcome of the executed
+   method and SHOULD treat the server as malfunctioning.
+
+8.1 PROPFIND
+
+   The PROPFIND method retrieves properties defined on the resource
+   identified by the Request-URI, if the resource does not have any
+   internal members, or on the resource identified by the Request-URI
+   and potentially its member resources, if the resource is a collection
+   that has internal member URIs.  All DAV compliant resources MUST
+   support the PROPFIND method and the propfind XML element (section
+   12.14) 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 PROPFIND on a collection resource with internal
+   member URIs.  DAV compliant servers MUST support the "0", "1" and
+   "infinity" behaviors. By default, the PROPFIND method without a Depth
+   header MUST act as if a "Depth: infinity" header was included.
+
+   A client may submit a propfind XML element in the body of the request
+   method describing what information is being requested.  It is
+   possible to request particular property values, all property values,
+   or a list of the names of the resource's properties.  A client may
+   choose not to submit a request body.  An empty PROPFIND request body
+   MUST be treated as a request for the names and values of all
+   properties.
+
+   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
+   properties.
+
+   If there is an error retrieving a property then a proper error result
+   MUST be included in the response.  A request to retrieve the value of
+   a property which does not exist is an error and MUST be noted, if the
+   response uses 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 resource
+   with member URIs MUST include a response XML element for each member
+   URI of the collection, to whatever depth was requested. Each response
+   XML element MUST contain an href XML element that gives the URI of
+   the resource on which the properties in the prop XML element are
+   defined.  Results for a PROPFIND on a collection resource with
+   internal member URIs are returned as a flat list whose order of
+   entries is not significant.
+
+
+
+Goland, et al.              Standards Track                    [Page 24]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   In the case of allprop and propname, if a principal does not have the
+   right to know whether a particular property exists then the property
+   should be silently excluded from the response.
+
+   The results of this method SHOULD NOT be cached.
+
+8.1.1 Example - Retrieving Named Properties
+
+   >>Request
+
+   PROPFIND  /file HTTP/1.1
+   Host: www.foo.bar
+   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.foo.bar/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>
+          <D:href>http://www.foo.bar/file</D:href>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <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>
+
+
+
+Goland, et al.              Standards Track                    [Page 25]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+               <D:status>HTTP/1.1 403 Forbidden</D:status>
+               <D:responsedescription> The user does not have access 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 is executed on a non-collection resource
+   http://www.foo.bar/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.1.2 Example - Using allprop to Retrieve All Properties
+
+   >>Request
+
+   PROPFIND  /container/ HTTP/1.1
+   Host: www.foo.bar
+   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:allprop/>
+   </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.foo.bar/container/</D:href>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox>
+                         <R:BoxType>Box type A</R:BoxType>
+                    </R:bigbox>
+                    <R:author>
+
+
+
+Goland, et al.              Standards Track                    [Page 26]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+                         <R:Name>Hadrian</R:Name>
+                    </R:author>
+                    <D:creationdate>
+                         1997-12-01T17:42:21-08:00
+                    </D:creationdate>
+                    <D:displayname>
+                         Example collection
+                    </D:displayname>
+                    <D:resourcetype><D:collection/></D:resourcetype>
+                    <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:response>
+          <D:href>http://www.foo.bar/container/front.html</D:href>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox>
+                         <R:BoxType>Box type B</R:BoxType>
+                    </R:bigbox>
+                    <D:creationdate>
+                         1997-12-01T18:27:21-08:00
+                    </D:creationdate>
+                    <D:displayname>
+                         Example HTML resource
+                    </D:displayname>
+                    <D:getcontentlength>
+                         4525
+                    </D:getcontentlength>
+                    <D:getcontenttype>
+                         text/html
+                    </D:getcontenttype>
+                    <D:getetag>
+                         zzyzx
+                    </D:getetag>
+                    <D:getlastmodified>
+                         Monday, 12-Jan-98 09:25:56 GMT
+                    </D:getlastmodified>
+
+
+
+Goland, et al.              Standards Track                    [Page 27]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+                    <D:resourcetype/>
+                    <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>
+
+   In this example, PROPFIND was invoked on the resource
+   http://www.foo.bar/container/ with a Depth header of 1, meaning the
+   request applies to the resource and its children, and a propfind XML
+   element containing the allprop XML element, meaning the request
+   should return the name and value of all properties defined on each
+   resource.
+
+   The resource http://www.foo.bar/container/ has six properties defined
+   on it:
+
+   http://www.foo.bar/boxschema/bigbox,
+   http://www.foo.bar/boxschema/author, DAV:creationdate,
+   DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
+
+   The last four properties are WebDAV-specific, defined in section 13.
+   Since GET is not supported on this resource, the get* properties
+   (e.g., getcontentlength) are not defined on this resource. The DAV-
+   specific properties assert that "container" was created on December
+   1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
+   (creationdate), has a name of "Example collection" (displayname), a
+   collection resource type (resourcetype), and supports exclusive write
+   and shared write locks (supportedlock).
+
+   The resource http://www.foo.bar/container/front.html has nine
+   properties defined on it:
+
+   http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox"
+   property type), DAV:creationdate, DAV:displayname,
+   DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+   DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 28]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   The DAV-specific properties assert that "front.html" was created on
+   December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
+   (creationdate), has a name of "Example HTML resource" (displayname),
+   a content length of 4525 bytes (getcontentlength), a MIME type of
+   "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was
+   last modified on Monday, January 12, 1998, at 09:25:56 GMT
+   (getlastmodified), has an empty resource type, meaning that it is not
+   a collection (resourcetype), and supports both exclusive write and
+   shared write locks (supportedlock).
+
+8.1.3 Example - Using propname to Retrieve all Property Names
+
+   >>Request
+
+   PROPFIND  /container/ HTTP/1.1
+   Host: www.foo.bar
+   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.foo.bar/container/</href>
+          <propstat>
+               <prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox/>
+                    <R:author/>
+                    <creationdate/>
+                    <displayname/>
+                    <resourcetype/>
+                    <supportedlock/>
+               </prop>
+               <status>HTTP/1.1 200 OK</status>
+          </propstat>
+     </response>
+     <response>
+          <href>http://www.foo.bar/container/front.html</href>
+
+
+
+Goland, et al.              Standards Track                    [Page 29]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+          <propstat>
+               <prop xmlns:R="http://www.foo.bar/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 collection resource
+   http://www.foo.bar/container/, with a propfind XML element containing
+   the propname XML element, meaning the name of all properties should
+   be returned.  Since no Depth header is present, it assumes its
+   default value of "infinity", meaning the name of the properties on
+   the collection and all its progeny should be returned.
+
+   Consistent with the previous example, resource
+   http://www.foo.bar/container/ has six properties defined on it,
+   http://www.foo.bar/boxschema/bigbox,
+   http://www.foo.bar/boxschema/author, DAV:creationdate,
+   DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
+
+   The resource http://www.foo.bar/container/index.html, a member of the
+   "container" collection, has nine properties defined on it,
+   http://www.foo.bar/boxschema/bigbox, DAV:creationdate,
+   DAV:displayname, DAV:getcontentlength, DAV:getcontenttype,
+   DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and
+   DAV:supportedlock.
+
+   This example also demonstrates the use of XML namespace scoping, and
+   the default namespace.  Since the "xmlns" attribute does not contain
+   an explicit "shorthand name" (prefix) letter, 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.
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 30]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.2 PROPPATCH
+
+   The PROPPATCH method processes instructions specified in the request
+   body to set and/or remove properties defined on the resource
+   identified by the Request-URI.
+
+   All DAV compliant resources MUST support the PROPPATCH method and
+   MUST process instructions that are specified using the
+   propertyupdate, set, and remove XML elements of the DAV schema.
+   Execution of the directives in this method is, of course, subject to
+   access control constraints.  DAV compliant resources 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 the
+   order instructions are received (i.e., from top to bottom).
+   Instructions MUST either all be executed or none executed. Thus if
+   any error occurs during processing all executed instructions MUST be
+   undone and a proper error result returned. Instruction processing
+   details can be found in the definition of the set and remove
+   instructions in section 12.13.
+
+8.2.1 Status Codes for use with 207 (Multi-Status)
+
+   The following are examples of response codes one would expect to be
+   used in 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 in a 207 (Multi-Status) response.
+
+   200 (OK) - The command succeeded.  As there can be a mixture of sets
+   and removes in a body, a 201 (Created) seems inappropriate.
+
+   403 (Forbidden) - The client, for reasons the server chooses not to
+   specify, cannot alter one of the properties.
+
+   409 (Conflict) - The client has provided a value whose semantics are
+   not appropriate for the property.  This includes trying to set read-
+   only properties.
+
+   423 (Locked) - The specified resource is locked and the client either
+   is not a lock owner or the lock type requires a lock token to be
+   submitted and the client did not submit it.
+
+   507 (Insufficient Storage) - The server did not have sufficient space
+   to record the property.
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 31]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.2.2 Example - PROPPATCH
+
+   >>Request
+
+   PROPPATCH /bar.html HTTP/1.1
+   Host: www.foo.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.foo.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>
+
+
+
+Goland, et al.              Standards Track                    [Page 32]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   In this example, the client requests the server to set the value of
+   the http://www.w3.com/standards/z39.50/Authors property, and to
+   remove the property http://www.w3.com/standards/z39.50/Copyright-
+   Owner.  Since the Copyright-Owner property could not be removed, no
+   property modifications occur.  The 424 (Failed Dependency) status
+   code for the Authors property indicates this action would have
+   succeeded if it were not for the conflict with removing the
+   Copyright-Owner property.
+
+8.3 MKCOL Method
+
+   The MKCOL method is used to create a new collection. All DAV
+   compliant resources MUST support the MKCOL method.
+
+8.3.1 Request
+
+   MKCOL creates a new collection resource at the location specified by
+   the Request-URI.  If the resource identified by the Request-URI is
+   non-null then the 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 method MUST fail with a 409
+   (Conflict) status code.  For example, if a request to create
+   collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists,
+   the request must fail.
+
+   When MKCOL is invoked without a request body, the newly created
+   collection SHOULD have no members.
+
+   A MKCOL request message may contain a message body.  The behavior of
+   a MKCOL request when the body is present is limited to creating
+   collections, members of a collection, bodies of members and
+   properties on the collections or members.  If the server receives a
+   MKCOL request entity type it does not support or understand it MUST
+   respond with a 415 (Unsupported Media Type) status code.  The exact
+   behavior of MKCOL for various request media types is undefined in
+   this document, and will be specified in separate documents.
+
+8.3.2 Status Codes
+
+   Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
+   idempotent semantics.
+
+   201 (Created) - The collection or structured resource was created in
+   its entirety.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 33]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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 can only be executed on a
+   deleted/non-existent resource.
+
+   409 (Conflict) - A collection cannot be made at the Request-URI until
+   one or more intermediate collections have been created.
+
+   415 (Unsupported Media Type)- The server does not support the request
+   type of the body.
+
+   507 (Insufficient Storage) - The resource does not have sufficient
+   space to record the state of the resource after the execution of this
+   method.
+
+8.3.3 Example - MKCOL
+
+   This example creates a collection called /webdisc/xfiles/ on the
+   server www.server.org.
+
+   >>Request
+
+   MKCOL /webdisc/xfiles/ HTTP/1.1
+   Host: www.server.org
+
+   >>Response
+
+   HTTP/1.1 201 Created
+
+8.4 GET, HEAD for Collections
+
+   The semantics of GET are unchanged when applied to a collection,
+   since GET is defined as, "retrieve whatever information (in the form
+   of an entity) is identified by the Request-URI" [RFC2068].  GET when
+   applied to a collection may return the contents of an "index.html"
+   resource, a human-readable view of the contents of the collection, or
+   something else altogether. Hence it is possible that the result of a
+   GET on a collection will bear no correlation to the membership of the
+   collection.
+
+   Similarly, since the definition of HEAD is a GET without a response
+   message body, the semantics of HEAD are unmodified when applied to
+   collection resources.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 34]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.5 POST for Collections
+
+   Since by definition the actual function performed by POST is
+   determined by the server and often depends on the particular
+   resource, the behavior of POST when applied to collections cannot be
+   meaningfully modified because it is largely undefined.  Thus the
+   semantics of POST are unmodified when applied to a collection.
+
+8.6 DELETE
+
+   8.6.1 DELETE for Non-Collection Resources
+
+   If the DELETE method is issued to a non-collection resource whose
+   URIs are an internal member of one or more collections, then during
+   DELETE processing a server MUST remove any URI for the resource
+   identified by the Request-URI from collections which contain it as a
+   member.
+
+8.6.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 collection specified in the Request-URI and
+   all resources identified by its internal member URIs are to be
+   deleted.
+
+   If any resource identified by a member URI cannot be deleted then all
+   of the member's ancestors MUST NOT be deleted, so as to maintain
+   namespace consistency.
+
+   Any headers included with DELETE MUST be applied in processing every
+   resource to be deleted.
+
+   When the DELETE method has completed processing it MUST result in a
+   consistent namespace.
+
+   If an error occurs with a resource other than the resource identified
+   in the Request-URI then the response MUST be a 207 (Multi-Status).
+   424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-
+   Status).  They can be safely left out because the client will know
+   that the ancestors of a resource could not be deleted when the client
+   receives an error for the ancestor's progeny.  Additionally 204 (No
+   Content) errors SHOULD NOT be returned in the 207 (Multi-Status).
+   The reason for this prohibition is that 204 (No Content) is the
+   default success code.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 35]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.6.2.1 Example - DELETE
+
+   >>Request
+
+   DELETE  /container/ HTTP/1.1
+   Host: www.foo.bar
+
+   >>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.foo.bar/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.foo.bar/container/resource3 failed because it is locked,
+   and no lock token was submitted with the request. Consequently, the
+   attempt to delete http://www.foo.bar/container/ also failed. Thus the
+   client knows that the attempt to delete http://www.foo.bar/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.7 PUT
+
+8.7.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 may be
+   recomputed during PUT processing but are not otherwise affected.  For
+   example, if a server recognizes the content type of the request body,
+   it may be able to automatically extract information that could be
+   profitably exposed as properties.
+
+   A PUT that would result in the creation of a resource without an
+   appropriately scoped parent collection MUST fail with a 409
+   (Conflict).
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 36]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.7.2 PUT for Collections
+
+   As defined in the HTTP/1.1 specification [RFC2068], the "PUT method
+   requests that the enclosed entity be stored under the supplied
+   Request-URI."  Since submission of an entity representing a
+   collection would implicitly encode creation and deletion of
+   resources, this specification intentionally does not define a
+   transmission format for creating a collection using PUT.  Instead,
+   the MKCOL method is defined to create collections.
+
+   When the PUT operation creates a new non-collection resource all
+   ancestors MUST already exist.  If all ancestors do not exist, the
+   method MUST fail with a 409 (Conflict) status code.  For example, if
+   resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
+   then the request must fail.
+
+8.8 COPY Method
+
+   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 Destination
+   header MUST be present.  The exact behavior of the COPY method
+   depends on the type of the source resource.
+
+   All WebDAV compliant resources MUST support the COPY method.
+   However, support for the COPY method 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 to be on the same server.
+
+8.8.1 COPY for HTTP/1.1 resources
+
+   When the source resource is not a collection the result of the COPY
+   method is the creation of a new resource at the destination whose
+   state and behavior match that of the source resource as closely as
+   possible.  After a successful COPY invocation, all properties on the
+   source resource MUST be duplicated on the destination resource,
+   subject to modifying headers and XML elements, following the
+   definition for copying properties.  Since the environment at the
+   destination may be different than at the source due to factors
+   outside the scope of control of the server, such as the absence of
+   resources required for correct operation, it may not be possible to
+   completely duplicate the behavior of the resource at the destination.
+   Subsequent alterations to the destination resource will not modify
+   the source resource.  Subsequent alterations to the source resource
+   will not modify the destination resource.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 37]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.8.2. COPY for Properties
+
+   The following section defines how properties on a resource are
+   handled during a COPY operation.
+
+   Live properties SHOULD be duplicated as identically behaving live
+   properties at the destination resource.  If a property cannot be
+   copied live, then its value MUST be duplicated, octet-for-octet, in
+   an identically named, dead property on the destination resource
+   subject to the effects of the propertybehavior XML element.
+
+   The propertybehavior XML element can specify that properties are
+   copied on best effort, that all live properties must be successfully
+   copied or the method must fail, or that a specified list of live
+   properties must be successfully copied or the method must fail. The
+   propertybehavior XML element is defined in section 12.12.
+
+8.8.3 COPY for Collections
+
+   The COPY method on a collection without a Depth header MUST act as if
+   a Depth header with value "infinity" was included.  A client may
+   submit a Depth header on a COPY on a collection with a value of "0"
+   or "infinity".  DAV compliant servers MUST support the "0" and
+   "infinity" Depth header behaviors.
+
+   A COPY of depth infinity instructs that the collection resource
+   identified by the Request-URI is to be copied to the location
+   identified by the URI in the Destination header, and all its internal
+   member resources are to be copied to a location relative to it,
+   recursively through all levels of the collection hierarchy.
+
+   A COPY of "Depth: 0" only instructs that the collection and its
+   properties but not resources identified by its internal member URIs,
+   are to be copied.
+
+   Any headers included with a COPY MUST be applied in processing every
+   resource to be copied with the exception of the Destination header.
+
+   The Destination header only specifies the destination URI for the
+   Request-URI. When applied to members of the collection identified by
+   the Request-URI the value of Destination is to be modified to reflect
+   the current location in the hierarchy.  So, if the Request- URI is
+   /a/ with Host header value http://fun.com/ and the Destination is
+   http://fun.com/b/ then when http://fun.com/a/c/d is processed it must
+   use a Destination of http://fun.com/b/c/d.
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 38]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   When the COPY method has completed processing it MUST have created a
+   consistent namespace at the destination (see section 5.1 for the
+   definition of namespace consistency).  However, if an error occurs
+   while copying an internal collection, the server MUST NOT copy any
+   resources identified by members of this collection (i.e., the server
+   must skip this subtree), as this would create an inconsistent
+   namespace. After detecting an error, the COPY operation SHOULD try to
+   finish as much of the original copy operation as possible (i.e., the
+   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
+   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 server
+   SHOULD try to finish as much of the original copy operation as
+   possible.
+
+   If an error in executing the COPY method occurs with a resource other
+   than the resource identified in the Request-URI then the response
+   MUST be a 207 (Multi-Status).
+
+   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 know that the progeny of a
+   resource could not be copied when the client receives an error for
+   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
+   default success codes.
+
+8.8.4 COPY and the Overwrite Header
+
+   If a resource exists at the destination and the Overwrite header is
+   "T" then prior to performing the copy the server MUST perform a
+   DELETE with "Depth: infinity" on the destination resource.  If the
+   Overwrite header is set to "F" then the operation will fail.
+
+8.8.5 Status Codes
+
+   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 was successfully copied to a
+   pre-existing destination resource.
+
+   403 (Forbidden) _ The source and destination URIs are the same.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 39]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   409 (Conflict) _ A resource cannot be created at the destination
+   until one or more intermediate collections have been created.
+
+   412 (Precondition Failed) - The server was unable to maintain the
+   liveness of the properties listed in the propertybehavior XML element
+   or the Overwrite header is "F" and the state of the destination
+   resource is non-null.
+
+   423 (Locked) - The destination resource was locked.
+
+   502 (Bad Gateway) - This may occur when the destination is on another
+   server and the destination server refuses to accept the resource.
+
+   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.8.6 Example - COPY with Overwrite
+
+   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.
+
+   >>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
+
+8.8.7 Example - COPY with No Overwrite
+
+   The following example shows the same copy operation being performed,
+   but with the Overwrite header set to "F."  A response of 412
+   (Precondition Failed) is returned because the destination resource
+   has a non-null state.
+
+   >>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
+
+
+
+Goland, et al.              Standards Track                    [Page 40]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   >>Response
+
+   HTTP/1.1 412 Precondition Failed
+
+8.8.8 Example - COPY of a Collection
+
+      >>Request
+
+      COPY /container/ HTTP/1.1
+      Host: www.foo.bar
+      Destination: http://www.foo.bar/othercontainer/
+      Depth: infinity
+      Content-Type: text/xml; charset="utf-8"
+      Content-Length: xxxx
+
+      <?xml version="1.0" encoding="utf-8" ?>
+      <d:propertybehavior xmlns:d="DAV:">
+        <d:keepalive>*</d:keepalive>
+      </d:propertybehavior>
+
+      >>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.foo.bar/othercontainer/R2/</d:href>
+             <d:status>HTTP/1.1 412 Precondition Failed</d:status>
+        </d:response>
+      </d:multistatus>
+
+   The Depth header is unnecessary as the default behavior of COPY on a
+   collection is 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, most likely due to a problem with maintaining the liveness of
+   properties (this is specified by the propertybehavior XML element).
+   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
+   error minimization rules given in section 8.8.3.
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 41]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.9 MOVE Method
+
+   The MOVE operation on a non-collection resource is the logical
+   equivalent of a copy (COPY), followed by consistency maintenance
+   processing, followed by a delete of the source, where all three
+   actions are performed atomically.  The consistency maintenance step
+   allows the server to perform updates caused by the move, such as
+   updating all URIs other than the Request-URI which identify the
+   source resource, to point to the new destination resource.
+   Consequently, the Destination header MUST be present on all MOVE
+   methods and MUST follow all COPY requirements for the COPY part of
+   the MOVE method.  All DAV compliant resources MUST support the MOVE
+   method.  However, support for the MOVE method does not guarantee the
+   ability to move a resource to a particular destination.
+
+   For example, separate programs may actually control different sets of
+   resources on the same server.  Therefore, it may not be possible to
+   move a resource within a namespace that appears to belong to the same
+   server.
+
+   If a resource exists at the destination, the destination resource
+   will be DELETEd as a side-effect of the MOVE operation, subject to
+   the restrictions of the Overwrite header.
+
+8.9.1 MOVE for Properties
+
+   The behavior of properties on a MOVE, including the effects of the
+   propertybehavior XML element, MUST be the same as specified in
+   section 8.8.2.
+
+8.9.2 MOVE for Collections
+
+   A MOVE with "Depth: infinity" instructs that the collection
+   identified by the Request-URI be moved to the URI specified in the
+   Destination header, and all resources identified by its internal
+   member URIs are to be moved to locations relative to it, recursively
+   through all levels of the collection hierarchy.
+
+   The MOVE method on a collection MUST act as if a "Depth: infinity"
+   header was used on it.  A client MUST NOT submit a Depth header on a
+   MOVE on a collection with any value but "infinity".
+
+   Any headers included with MOVE MUST be applied in processing every
+   resource to be moved with the exception of the Destination header.
+
+   The behavior of the Destination header is the same as given for COPY
+   on collections.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 42]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   When the MOVE method has completed processing it MUST have created a
+   consistent namespace at both the source and destination (see section
+   5.1 for the definition of namespace consistency). However, if an
+   error occurs while moving an internal collection, the server MUST 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 finish as much of the
+   original move as possible (i.e., the server should still attempt to
+   move other subtrees and the resources identified by their members,
+   that are not descendents of an error-causing collection).  So, for
+   example, if an infinite depth move 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 a non-collection
+   resource as part of an infinite depth move, the server SHOULD try to
+   finish as much of the original move operation as possible.
+
+   If an error occurs with a resource other than the resource identified
+   in the Request-URI then the response MUST be a 207 (Multi-Status).
+
+   The 424 (Failed Dependency) status code SHOULD NOT be returned in the
+   207 (Multi-Status) response from a MOVE method.  These errors can be
+   safely omitted because the client will know that the progeny of a
+   resource could not be moved when the client receives an error for the
+   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
+   default success codes.
+
+8.9.3 MOVE and the Overwrite Header
+
+   If a resource exists at the destination and the Overwrite header is
+   "T" then prior to performing the move the server MUST perform a
+   DELETE with "Depth: infinity" on the destination resource.  If the
+   Overwrite header is set to "F" then the operation will fail.
+
+8.9.4 Status Codes
+
+   201 (Created) - The source resource was successfully moved, and a new
+   resource was created at the destination.
+
+   204 (No Content) - The source resource was successfully moved to a
+   pre-existing destination resource.
+
+   403 (Forbidden) _ The source and destination URIs are the same.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 43]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   409 (Conflict) _ A resource cannot be created at the destination
+   until one or more intermediate collections have been created.
+
+   412 (Precondition Failed) - The server was unable to maintain the
+   liveness of the properties listed in the propertybehavior XML element
+   or the Overwrite header is "F" and the state of the destination
+   resource is non-null.
+
+   423 (Locked) - The source or the destination resource was locked.
+
+   502 (Bad Gateway) - This may occur when the destination is on another
+   server and the destination server refuses to accept the resource.
+
+8.9.5 Example - MOVE of a Non-Collection
+
+   This example shows resource
+   http://www.ics.uci.edu/~fielding/index.html being moved to the
+   location http://www.ics.uci.edu/users/f/fielding/index.html. The
+   contents of the destination resource would have been overwritten if
+   the destination resource had been non-null.  In this case, since
+   there was nothing at the destination resource, the response code is
+   201 (Created).
+
+   >>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
+
+
+8.9.6 Example - MOVE of a Collection
+
+   >>Request
+
+   MOVE /container/ HTTP/1.1
+   Host: www.foo.bar
+   Destination: http://www.foo.bar/othercontainer/
+   Overwrite: F
+   If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
+       (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+
+
+
+
+Goland, et al.              Standards Track                    [Page 44]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <d:propertybehavior xmlns:d='DAV:'>
+     <d:keepalive>*</d:keepalive>
+   </d:propertybehavior>
+
+   >>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.foo.bar/othercontainer/C2/</d:href>
+          <d:status>HTTP/1.1 423 Locked</d:status>
+     </d:response>
+   </d:multistatus>
+
+   In this example the client has submitted a number of lock tokens with
+   the request.  A lock token will need to be submitted for every
+   resource, both source and destination, anywhere in the scope of the
+   method, that is locked.  In this case the proper lock token was not
+   submitted for the destination http://www.foo.bar/othercontainer/C2/.
+   This means that the resource /container/C2/ could not be moved.
+   Because there was an error copying /container/C2/, none of
+   /container/C2's members were copied.  However no errors were listed
+   for those members due to the error minimization rules given in
+   section 8.8.3.  User agent authentication has previously occurred via
+   a mechanism outside the scope of the HTTP protocol, in an underlying
+   transport layer.
+
+8.10 LOCK Method
+
+   The following sections describe the LOCK method, which is used to
+   take out a lock of any access type.  These sections on the LOCK
+   method describe only those semantics that are specific to the LOCK
+   method and are independent of the access type of the lock being
+   requested.
+
+   Any resource which supports the LOCK method MUST, at minimum, support
+   the XML request and response formats defined herein.
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 45]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.10.1 Operation
+
+   A LOCK method invocation creates the lock specified by the lockinfo
+   XML element on the Request-URI.  Lock method requests SHOULD have a
+   XML request body which contains an owner XML element for this lock
+   request, unless this is a refresh request. The LOCK request may have
+   a Timeout header.
+
+   Clients MUST assume that locks may arbitrarily disappear at any time,
+   regardless of the value given in the Timeout header.  The Timeout
+   header only indicates the behavior of the server if "extraordinary"
+   circumstances do not occur.  For example, an administrator may remove
+   a lock at any time or the system may crash in such a way that it
+   loses the record of the lock's existence. The response MUST contain
+   the value of the lockdiscovery property in a prop XML element.
+
+   In order to indicate the lock token associated with a newly created
+   lock, a Lock-Token response header MUST be included in the response
+   for every successful LOCK request for a new lock.  Note that the
+   Lock-Token header would not be returned in the response for a
+   successful refresh LOCK request because a new lock was not created.
+
+8.10.2 The Effect of Locks on Properties and Collections
+
+   The scope of a lock is the entire state of the resource, including
+   its body and associated properties.  As a result, a lock on a
+   resource MUST also lock the resource's properties.
+
+   For collections, a lock also affects the ability to add or remove
+   members.  The nature of the effect depends upon the type of access
+   control involved.
+
+8.10.3 Locking Replicated Resources
+
+   A resource may be made available through more than one URI. However
+   locks apply to resources, not URIs. Therefore a LOCK request on a
+   resource MUST NOT succeed if can not be honored by all the URIs
+   through which the resource is addressable.
+
+8.10.4 Depth and Locking
+
+   The Depth header may be used with the LOCK method.  Values other than
+   0 or infinity MUST NOT be used with the Depth header on a LOCK
+   method.  All resources that support the LOCK method MUST support the
+   Depth header.
+
+   A Depth header of value 0 means to just lock the resource specified
+   by the Request-URI.
+
+
+
+Goland, et al.              Standards Track                    [Page 46]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   If the Depth header is set to infinity then the resource specified in
+   the Request-URI along with all its internal members, all the way down
+   the hierarchy, are to be locked.  A successful result MUST return a
+   single lock token which represents all the resources that have been
+   locked.  If an UNLOCK is successfully executed on this token, all
+   associated resources are unlocked.  If the lock cannot be granted to
+   all resources, a 409 (Conflict) status code MUST be returned with a
+   response entity body containing 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 a "Depth:infinity" had been submitted.
+
+8.10.5 Interaction with other Methods
+
+   The interaction of a LOCK with various methods is dependent upon the
+   lock type.  However, independent of lock type, a successful DELETE of
+   a resource MUST cause all of its locks to be removed.
+
+8.10.6 Lock Compatibility Table
+
+   The table below describes the behavior that occurs when a lock
+   request is made on a resource.
+
+   Current lock state/  |   Shared Lock   |   Exclusive
+   Lock request         |                 |   Lock
+   =====================+=================+==============
+   None                 |   True          |   True
+   ---------------------+-----------------+--------------
+   Shared Lock          |   True          |   False
+   ---------------------+-----------------+--------------
+   Exclusive Lock       |   False         |   False*
+   ------------------------------------------------------
+
+   Legend: True = lock may be granted.  False = lock MUST NOT be
+   granted. *=It is illegal for a principal to request the same lock
+   twice.
+
+   The current lock state of a resource is given in the leftmost column,
+   and lock requests are listed in the first row.  The intersection of a
+   row and column gives the result of a lock request.  For example, if a
+   shared lock is held on a resource, and an exclusive lock is
+   requested, the table entry is "false", indicating the lock must not
+   be granted.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 47]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.10.7 Status Codes
+
+   200 (OK) - The lock request succeeded and the value of the
+   lockdiscovery property is included in the body.
+
+   412 (Precondition Failed) - The included lock token was not
+   enforceable on this resource or the server could not satisfy the
+   request in the lockinfo XML element.
+
+   423 (Locked) - The resource is locked, so the method has been
+   rejected.
+
+8.10.8 Example - Simple Lock Request
+
+   >>Request
+
+   LOCK /workspace/webdav/proposal.doc HTTP/1.1
+   Host: webdav.sb.aol.com
+   Timeout: Infinite, Second-4100000000
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   Authorization: Digest username="ejw",
+      realm="ejw@webdav.sb.aol.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
+   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>
+
+
+
+Goland, et al.              Standards Track                    [Page 48]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+               <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:activelock>
+     </D:lockdiscovery>
+   </D:prop>
+
+   This example shows the successful creation of an exclusive write lock
+   on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
+   The resource http://www.ics.uci.edu/~ejw/contact.html contains
+   contact information for the owner of the lock.  The server has an
+   activity-based timeout policy in place on this resource, which causes
+   the lock to automatically be removed after 1 week (604800 seconds).
+   Note that the nonce, response, and opaque fields have not been
+   calculated in the Authorization request header.
+
+8.10.9 Example - Refreshing a Write Lock
+
+   >>Request
+
+   LOCK /workspace/webdav/proposal.doc HTTP/1.1
+   Host: webdav.sb.aol.com
+   Timeout: Infinite, Second-4100000000
+   If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
+   Authorization: Digest username="ejw",
+      realm="ejw@webdav.sb.aol.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>
+
+
+
+Goland, et al.              Standards Track                    [Page 49]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+               <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:activelock>
+     </D:lockdiscovery>
+   </D:prop>
+
+   This request would refresh the lock, resetting any time outs.  Notice
+   that the client asked for an infinite time out but the server choose
+   to ignore the request. In this example, the nonce, response, and
+   opaque fields have not been calculated in the Authorization request
+   header.
+
+8.10.10 Example - Multi-Resource Lock Request
+
+   >>Request
+
+   LOCK /webdav/ HTTP/1.1
+   Host: webdav.sb.aol.com
+   Timeout: Infinite, Second-4100000000
+   Depth: infinity
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   Authorization: Digest username="ejw",
+      realm="ejw@webdav.sb.aol.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
+
+
+
+Goland, et al.              Standards Track                    [Page 50]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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://webdav.sb.aol.com/webdav/secret</D:href>
+          <D:status>HTTP/1.1 403 Forbidden</D:status>
+     </D:response>
+     <D:response>
+          <D:href>http://webdav.sb.aol.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 a
+   collection and all its children.  In this request, the client has
+   specified that it desires an infinite length lock, if available,
+   otherwise a timeout of 4.1 billion seconds, if available. The request
+   entity body contains the contact information for the principal taking
+   out the lock, in this case a web page URL.
+
+   The error is a 403 (Forbidden) response on the resource
+   http://webdav.sb.aol.com/webdav/secret.  Because this resource could
+   not be locked, none of the resources were locked.  Note also that the
+   lockdiscovery property for the Request-URI has been included as
+   required.  In this example the lockdiscovery property is empty which
+   means that there are no outstanding locks on the resource.
+
+   In this example, the nonce, response, and opaque fields have not been
+   calculated in the Authorization request header.
+
+8.11 UNLOCK Method
+
+   The UNLOCK method removes the lock identified by the lock token in
+   the Lock-Token request header from the Request-URI, and all other
+   resources included in the lock.  If all resources which have been
+   locked under the submitted lock token can not be unlocked then the
+   UNLOCK request MUST fail.
+
+   Any DAV compliant resource which supports the LOCK method MUST
+   support the UNLOCK method.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 51]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+8.11.1 Example - UNLOCK
+
+   >>Request
+
+   UNLOCK /workspace/webdav/info.doc HTTP/1.1
+   Host: webdav.sb.aol.com
+   Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
+   Authorization: Digest username="ejw",
+      realm="ejw@webdav.sb.aol.com", nonce="...",
+      uri="/workspace/webdav/proposal.doc",
+      response="...", opaque="..."
+
+   >>Response
+
+   HTTP/1.1 204 No Content
+
+   In this example, the lock identified by the lock token
+   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
+   successfully removed from the resource
+   http://webdav.sb.aol.com/workspace/webdav/info.doc.  If this lock
+   included more than just one resource, the lock is removed from all
+   resources included in the lock.  The 204 (No Content) status code is
+   used instead of 200 (OK) because there is no response entity body.
+
+   In this example, the nonce, response, and opaque fields have not been
+   calculated in the Authorization request header.
+
+9  HTTP Headers for Distributed Authoring
+
+9.1 DAV Header
+
+   DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
+
+   This header indicates that the resource supports the DAV schema and
+   protocol as specified. All DAV compliant resources MUST return the
+   DAV header on all OPTIONS responses.
+
+   The value is a list of all compliance classes that the resource
+   supports.  Note that above a comma has already been added to the 2.
+   This is because a resource can not be level 2 compliant unless it is
+   also level 1 compliant. Please refer to section 15 for more details.
+   In general, however, support for one compliance class does not entail
+   support for any other.
+
+9.2 Depth Header
+
+   Depth = "Depth" ":" ("0" | "1" | "infinity")
+
+
+
+
+Goland, et al.              Standards Track                    [Page 52]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   The Depth header is used with methods executed on resources which
+   could potentially have internal members to indicate whether the
+   method is to be applied only to the resource ("Depth: 0"), to the
+   resource and its immediate children, ("Depth: 1"), or the resource
+   and all its progeny ("Depth: infinity").
+
+   The Depth header is only supported if a method's definition
+   explicitly provides for such support.
+
+   The following rules are the default behavior for any method that
+   supports the Depth header. A method may override these defaults by
+   defining different behavior in its definition.
+
+   Methods which support the Depth header may choose not to support all
+   of the header's values and may define, on a case by case basis, the
+   behavior of the method if a Depth header is not present. For example,
+   the MOVE method only supports "Depth: infinity" and if a Depth header
+   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 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 and what it failed to do.
+
+   So, for example, an attempt to COPY a hierarchy may result in some of
+   the members being copied and some not.
+
+   Any headers on a method that has a defined interaction with the 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 method's scope and will cause the method to fail if the header
+   fails to match.
+
+   If a resource, source or destination, within the scope of the method
+   with a Depth header is locked in such a way as to prevent the
+   successful execution of the method, then the lock token for that
+   resource MUST be submitted with the request in the If request header.
+
+   The Depth header only specifies the behavior of the method with
+   regards to internal children.  If a resource does not have internal
+   children then the Depth header MUST be ignored.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 53]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Please note, however, that it is always an error to submit a value
+   for the Depth header that is not allowed by the method's definition.
+   Thus submitting a "Depth: 1" on a COPY, even if the resource does not
+   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 in the header.
+
+9.3 Destination Header
+
+   Destination = "Destination" ":" absoluteURI
+
+   The Destination header specifies the URI which identifies a
+   destination resource for methods such as COPY and MOVE, which take
+   two URIs as parameters.  Note that the absoluteURI production is
+   defined in [RFC2396].
+
+9.4 If Header
+
+   If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
+   No-tag-list = List
+   Tagged-list = Resource 1*List
+   Resource = Coded-URL
+   List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
+   State-token = Coded-URL
+   Coded-URL = "<" absoluteURI ">"
+
+   The If header is intended to have similar functionality to the If-
+   Match header defined in section 14.25 of [RFC2068].  However the If
+   header is intended for use with any URI which represents state
+   information, referred to as a state token, about a resource as well
+   as ETags.  A typical example of a state token is a lock token, and
+   lock tokens are the only state tokens defined in this specification.
+
+   All DAV compliant resources MUST honor the If header.
+
+   The If header's purpose is to describe a series of state lists.  If
+   the state of the resource to which the header is applied does not
+   match any of the specified state lists then the request MUST fail
+   with a 412 (Precondition Failed).  If one of the described state
+   lists matches the state of the resource then the request may succeed.
+
+   Note that the absoluteURI production is defined in [RFC2396].
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 54]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+9.4.1 No-tag-list Production
+
+   The No-tag-list production describes a series of state tokens and
+   ETags.  If multiple No-tag-list productions are used then one only
+   needs to match the state of the resource for the method to be allowed
+   to continue.
+
+   If a method, due to the presence of a Depth or Destination header, is
+   applied to multiple resources then the No-tag-list production MUST be
+   applied to each resource the method is applied to.
+
+9.4.1.1 Example - No-tag-list If Header
+
+   If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
+   ETag"])
+
+   The previous header would require that any resources within the scope
+   of the method must either be locked with the specified lock token and
+   in the state identified by the "I am an ETag" ETag 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 <locktoken:a-write-lock-token> ["I am an ETag"]) (and
+   ["I am another ETag"])).
+
+9.4.2 Tagged-list Production
+
+   The tagged-list production scopes a list production.  That is, it
+   specifies that the lists following the resource specification only
+   apply to the specified resource.  The scope of the resource
+   production begins with the list production immediately following the
+   resource production and ends with the next resource production, if
+   any.
+
+   When the If header is applied to a particular resource, the Tagged-
+   list productions MUST be searched to determine if any of the listed
+   resources match the operand resource(s) for the current method.  If
+   none of the resource productions match the current resource then the
+   header MUST be ignored.  If one of the resource productions does
+   match the name of the resource under consideration then the list
+   productions following the resource production MUST be applied to the
+   resource in the manner specified in the previous section.
+
+   The same URI MUST NOT appear more than once in a resource production
+   in an If header.
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 55]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+9.4.2.1 Example - Tagged List If header
+
+   COPY /resource1 HTTP/1.1
+   Host: www.foo.bar
+   Destination: http://www.foo.bar/resource2
+   If: <http://www.foo.bar/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.foo.bar/resource1 is being copied to
+   http://www.foo.bar/resource2.  When the method is first applied to
+   http://www.foo.bar/resource1, resource1 must be in the 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 "locktoken:a-write-lock-token" and have a weak entity tag
+   W/"A weak ETag" or it must have a strong entity tag "strong ETag".
+
+   That is the only success condition since the resource
+   http://www.bar.bar/random never has the method applied to it (the
+   only other resource listed in the If header) and
+   http://www.foo.bar/resource2 is not listed in the If header.
+
+9.4.3 not Production
+
+   Every state token or ETag is either current, and hence describes the
+   state of a resource, or is not current, and does not describe the
+   state of a resource. The boolean operation of matching a state token
+   or ETag to the current state of a resource thus resolves to a true or
+   false value.  The not production is used to reverse that value.  The
+   scope of the not production is the 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 locked with locktoken:write1 and must
+   be locked with locktoken:write2.
+
+9.4.4 Matching Function
+
+   When performing If header processing, the definition of a matching
+   state token or entity tag is as follows.
+
+   Matching entity tag: Where the entity tag matches an entity tag
+   associated with that resource.
+
+   Matching state token: Where there is an exact match between the state
+   token in the If header and any state token on the resource.
+
+
+
+Goland, et al.              Standards Track                    [Page 56]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+9.4.5 If Header and Non-DAV Compliant Proxies
+
+   Non-DAV compliant proxies will not honor the If header, since they
+   will not understand the If header, and HTTP requires non-understood
+   headers to be ignored.  When communicating with HTTP/1.1 proxies, the
+   "Cache-Control: no-cache" request header MUST be used 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 for the same reason.
+
+9.5 Lock-Token Header
+
+   Lock-Token = "Lock-Token" ":" Coded-URL
+
+   The Lock-Token request header is used with the UNLOCK method to
+   identify the lock to be removed.  The lock token in the Lock-Token
+   request header MUST identify a lock that contains the resource
+   identified by Request-URI as a member.
+
+   The Lock-Token response header is used with the LOCK method to
+   indicate the lock token created as a result of a successful LOCK
+   request to create a new lock.
+
+9.6 Overwrite Header
+
+   Overwrite = "Overwrite" ":" ("T" | "F")
+
+   The Overwrite header specifies whether the server should overwrite
+   the state of a non-null destination resource during a COPY or MOVE.
+   A value of "F" states that the server must not perform the COPY or
+   MOVE operation if the state of the destination resource is non-null.
+   If the overwrite header is not included in a COPY or MOVE request
+   then the resource MUST treat the request as if it has an overwrite
+   header of value "T". While the Overwrite header appears to duplicate
+   the 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 COPY
+   or MOVE.
+
+   If a COPY or MOVE is not performed due to the value of the Overwrite
+   header, the method MUST fail with a 412 (Precondition Failed) status
+   code.
+
+   All DAV compliant resources MUST support the Overwrite header.
+
+9.7 Status-URI Response Header
+
+   The Status-URI response header may be used with the 102 (Processing)
+   status code to inform the client as to the status of a method.
+
+
+
+Goland, et al.              Standards Track                    [Page 57]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
+   is defined in 6.1.1 of [RFC2068]
+
+   The URIs listed in the header are source resources which have been
+   affected by the outstanding method.  The status code indicates the
+   resolution of the method on the identified resource.  So, for
+   example, if a MOVE method on a collection is outstanding and a 102
+   (Processing) response with a Status-URI response header is returned,
+   the included URIs will indicate resources that have had move
+   attempted on them and what the result was.
+
+9.8 Timeout Request Header
+
+   TimeOut = "Timeout" ":" 1#TimeType
+   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
+   DAVTimeOutVal = 1*digit
+   Other = "Extend" field-value   ; See section 4.2 of [RFC2068]
+
+   Clients may include Timeout headers in their LOCK requests.  However,
+   the server is not required to honor or even consider these requests.
+   Clients MUST NOT submit a Timeout request header with any method
+   other than a LOCK method.
+
+   A Timeout request header MUST contain at least one TimeType and may
+   contain multiple TimeType entries. The purpose of listing multiple
+   TimeType entries is to indicate multiple different values and value
+   types that are acceptable to the client.  The client lists the
+   TimeType entries in order of preference.
+
+   Timeout response values MUST use a Second value, Infinite, or a
+   TimeType the client has indicated familiarity with.  The server may
+   assume a client is familiar with any TimeType submitted in a Timeout
+   header.
+
+   The "Second" TimeType specifies the number of seconds that will
+   elapse between granting of the lock at the server, and the automatic
+   removal of the lock.  The timeout value for TimeType "Second" MUST
+   NOT be greater than 2^32-1.
+
+   The timeout counter SHOULD be restarted any time an owner of the lock
+   sends a method to any member of the lock, including unsupported
+   methods, or methods which are unsuccessful.  However the lock MUST be
+   refreshed if a refresh LOCK method is successfully received.
+
+   If the timeout expires then the lock may be lost.  Specifically, if
+   the server wishes to harvest the lock upon time-out, the server
+   SHOULD act as if an UNLOCK method was executed by the server on the
+   resource using the lock token of the timed-out lock, performed with
+
+
+
+Goland, et al.              Standards Track                    [Page 58]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   its override authority. Thus logs should be updated with the
+   disposition of the lock, notifications should be sent, etc., just as
+   they would be for an UNLOCK request.
+
+   Servers are advised to pay close attention to the values submitted by
+   clients, as they will be indicative of the type of activity the
+   client intends to perform.  For example, an applet running in a
+   browser may need to lock a resource, but because of the instability
+   of the environment within which the applet is running, the applet may
+   be turned off without warning.  As a result, the applet is likely to
+   ask for a relatively small timeout value so that if the applet dies,
+   the lock can be quickly harvested.  However, a document management
+   system is likely to ask for an extremely long timeout because its
+   user may be planning on going off-line.
+
+   A client MUST NOT assume that just because the time-out has expired
+   the lock has been lost.
+
+10 Status Code Extensions to HTTP/1.1
+
+   The following status codes are added to those defined in HTTP/1.1
+   [RFC2068].
+
+10.1 102 Processing
+
+   The 102 (Processing) status code is an interim response used to
+   inform the client that the server has accepted the complete request,
+   but has not yet completed it.  This status code SHOULD only be sent
+   when the server has a reasonable expectation 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) to process
+   the server SHOULD return a 102 (Processing) response. The server MUST
+   send a final response after the request has been completed.
+
+   Methods can potentially take a long period of time to process,
+   especially methods that support the Depth header.  In such cases the
+   client may time-out the connection while waiting for a response.  To
+   prevent this the server may return a 102 (Processing) status code to
+   indicate to the client that the server is still processing the
+   method.
+
+10.2 207 Multi-Status
+
+   The 207 (Multi-Status) status code provides status for multiple
+   independent operations (see section 11 for more information).
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 59]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+10.3 422 Unprocessable Entity
+
+   The 422 (Unprocessable Entity) status code means the server
+   understands the content type of the request entity (hence a
+   415(Unsupported Media Type) status code is inappropriate), and the
+   syntax of the request entity is correct (thus a 400 (Bad Request)
+   status code is inappropriate) but was unable to process the contained
+   instructions.  For example, this error 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 the source or destination resource
+   of a method is locked.
+
+10.5 424 Failed Dependency
+
+   The 424 (Failed Dependency) status code means that the method could
+   not be performed on the resource because the requested action
+   depended on another action and that action failed.  For example, if 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 507 (Insufficient Storage) status code means the method could not
+   be performed on the resource because the server is unable to store
+   the representation needed to successfully complete the request.  This
+   condition is considered to be temporary.  If the request which
+   received this status code was the result of a user action, the
+   request MUST NOT be repeated until it is requested by a separate user
+   action.
+
+11 Multi-Status Response
+
+   The default 207 (Multi-Status) response body is a text/xml or
+   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
+   recorded in a response XML element.
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 60]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12 XML Element Definitions
+
+   In the section below, the final line of each section gives the
+   element type declaration using the format defined in [REC-XML]. 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).
+
+12.1 activelock XML Element
+
+   Name:       activelock
+   Namespace:  DAV:
+   Purpose:    Describes a lock on a resource.
+
+   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
+   locktoken?) >
+
+12.1.1 depth XML Element
+
+   Name:       depth
+   Namespace:  DAV:
+   Purpose:    The value of the Depth header.
+   Value:      "0" | "1" | "infinity"
+
+   <!ELEMENT depth (#PCDATA) >
+
+12.1.2 locktoken XML Element
+
+   Name:       locktoken
+   Namespace:  DAV:
+   Purpose:    The lock token associated with a lock.
+   Description: The href contains one or more opaque lock token URIs
+   which all refer to the same lock (i.e., the OpaqueLockToken-URI
+   production in section 6.4).
+
+   <!ELEMENT locktoken (href+) >
+
+12.1.3 timeout XML Element
+
+   Name:       timeout
+   Namespace:  DAV:
+   Purpose:    The timeout associated with a lock
+   Value:      TimeType ;Defined in section 9.8
+
+   <!ELEMENT timeout (#PCDATA) >
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 61]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12.2 collection XML Element
+
+   Name:       collection
+   Namespace:  DAV:
+   Purpose:    Identifies the associated resource as a collection. The
+   resourcetype property of a collection resource MUST have this value.
+
+   <!ELEMENT collection EMPTY >
+
+12.3 href XML Element
+
+   Name:       href
+   Namespace:  DAV:
+   Purpose:    Identifies the content of the element as a URI.
+   Value:      URI ; See section 3.2.1 of [RFC2068]
+
+   <!ELEMENT href (#PCDATA)>
+
+12.4 link XML Element
+
+   Name:       link
+   Namespace:  DAV:
+   Purpose:    Identifies the property as a link and contains the source
+   and destination of that link.
+   Description: The link XML element is used to provide the sources and
+   destinations of a link.  The name of the property containing the link
+   XML element provides the type of the link.  Link is a multi-valued
+   element, so multiple links may be used together to indicate multiple
+   links with the same type.  The values in the href XML elements inside
+   the src and dst XML elements of the link XML element MUST NOT be
+   rejected if they point to resources which do not exist.
+
+   <!ELEMENT link (src+, dst+) >
+
+12.4.1 dst XML Element
+
+   Name:       dst
+   Namespace:  DAV:
+   Purpose:    Indicates the destination of a link
+   Value:      URI
+
+   <!ELEMENT dst (#PCDATA) >
+
+12.4.2 src XML Element
+
+   Name:       src
+   Namespace:  DAV:
+   Purpose:    Indicates the source of a link.
+
+
+
+Goland, et al.              Standards Track                    [Page 62]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Value:      URI
+
+   <!ELEMENT src (#PCDATA) >
+
+12.5 lockentry XML Element
+
+   Name:       lockentry
+   Namespace:  DAV:
+   Purpose:    Defines the types of locks that can be used with the
+   resource.
+
+   <!ELEMENT lockentry (lockscope, locktype) >
+
+12.6 lockinfo XML Element
+
+   Name:       lockinfo
+   Namespace:  DAV:
+   Purpose:    The lockinfo XML element is used with a LOCK method to
+   specify the type of lock the client wishes to have created.
+
+   <!ELEMENT lockinfo (lockscope, locktype, owner?) >
+
+12.7 lockscope XML Element
+
+   Name:       lockscope
+   Namespace:  DAV:
+   Purpose:    Specifies whether a lock is an exclusive lock, or a
+   shared lock.
+
+   <!ELEMENT lockscope (exclusive | shared) >
+
+12.7.1 exclusive XML Element
+
+   Name:       exclusive
+   Namespace:  DAV:
+   Purpose:    Specifies an exclusive lock
+
+   <!ELEMENT exclusive EMPTY >
+
+12.7.2 shared XML Element
+
+   Name:       shared
+   Namespace:  DAV:
+   Purpose:    Specifies a shared lock
+
+   <!ELEMENT shared EMPTY >
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 63]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12.8 locktype XML Element
+
+   Name:       locktype
+   Namespace:  DAV:
+   Purpose:    Specifies the access type of a lock.  At present, this
+   specification only defines one lock type, the write lock.
+
+   <!ELEMENT locktype (write) >
+
+12.8.1 write XML Element
+
+   Name:       write
+   Namespace:  DAV:
+   Purpose:    Specifies a write lock.
+
+   <!ELEMENT write EMPTY >
+
+12.9 multistatus XML Element
+
+   Name:       multistatus
+   Namespace:  DAV:
+   Purpose:    Contains multiple response messages.
+   Description: The 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 application may use it
+   instead of presenting the individual response descriptions contained
+   within the responses.
+
+   <!ELEMENT multistatus (response+, responsedescription?) >
+
+12.9.1 response XML Element
+
+   Name:       response
+   Namespace:  DAV:
+   Purpose:    Holds a single response describing the effect of a
+   method on resource and/or its properties.
+   Description: A particular href MUST NOT appear more than once as the
+   child of a response XML element under a multistatus XML element.
+   This requirement is necessary in order to keep processing costs for a
+   response to linear time.  Essentially, this prevents having to search
+   in order to group together all the responses by href.  There are,
+   however, no requirements regarding ordering based on href values.
+
+   <!ELEMENT response (href, ((href*, status)|(propstat+)),
+   responsedescription?) >
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 64]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12.9.1.1  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 MUST contain one prop XML
+   element and one status XML element.  The contents of the prop XML
+   element MUST only list the names of properties to which the result in
+   the status element applies.
+
+   <!ELEMENT propstat (prop, status, responsedescription?) >
+
+12.9.1.2  status XML Element
+
+   Name:       status
+   Namespace:  DAV:
+   Purpose:    Holds a single HTTP status-line
+   Value:      status-line   ;status-line defined in [RFC2068]
+
+   <!ELEMENT status (#PCDATA) >
+
+12.9.2 responsedescription XML Element
+
+   Name:       responsedescription
+   Namespace:  DAV:
+   Purpose:    Contains a message that can be displayed to the user
+   explaining the nature of the response.
+   Description: This XML element provides information suitable to be
+   presented to a user.
+
+   <!ELEMENT responsedescription (#PCDATA) >
+
+12.10 owner XML Element
+
+   Name:       owner
+   Namespace:  DAV:
+   Purpose:    Provides information about the principal taking out a
+   lock.
+   Description: The owner XML element provides information sufficient
+   for either directly contacting a principal (such as a telephone
+   number or Email URI), or for discovering the principal (such as the
+   URL of a homepage) who owns a lock.
+
+   <!ELEMENT owner ANY>
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 65]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12.11 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 resource.  No other
+   elements may be used inside of a prop element.
+
+   <!ELEMENT prop ANY>
+
+12.12 propertybehavior XML element
+
+   Name:       propertybehavior Namespace:  DAV:  Purpose:    Specifies
+   how properties are handled during a COPY or MOVE.
+   Description: The propertybehavior XML element specifies how
+   properties are handled during a COPY or MOVE.  If this XML element is
+   not included in the request body then the server is expected to act
+   as defined by the default property handling behavior of the
+   associated method.  All WebDAV compliant resources MUST support the
+   propertybehavior XML element.
+
+   <!ELEMENT propertybehavior (omit | keepalive) >
+
+12.12.1 keepalive XML element
+
+   Name:       keepalive
+   Namespace:  DAV:
+   Purpose:    Specifies requirements for the copying/moving of live
+   properties.
+   Description: If a list of URIs is included as the value of keepalive
+   then the named properties MUST be "live" after they are copied
+   (moved) to the destination resource of a COPY (or MOVE).  If the
+   value "*" is given for the keepalive XML element, this designates
+   that all live properties on the source resource MUST be live on the
+   destination.  If the requirements specified by the keepalive element
+   can not be honored then the method MUST fail with a 412 (Precondition
+   Failed).  All DAV compliant resources MUST support the keepalive XML
+   element for use with the COPY and MOVE methods.
+   Value:      "*" ; #PCDATA value can only be "*"
+
+   <!ELEMENT keepalive (#PCDATA | href+) >
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 66]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+12.12.2 omit XML element
+
+   Name:       omit
+   Namespace:  DAV:
+   Purpose:    The omit XML element instructs the server that it should
+   use best effort to copy properties but a failure to copy a property
+   MUST NOT cause the method to fail.  Description: The default behavior
+   for a COPY or MOVE is to copy/move all properties or fail the method.
+   In certain circumstances, such as when a server copies a resource
+   over another protocol such as FTP, it may not be possible to
+   copy/move the properties associated with the resource. Thus any
+   attempt to copy/move over FTP would always have to fail because
+   properties could not be moved over, even as dead properties.  All DAV
+   compliant resources MUST support the omit XML element on COPY/MOVE
+   methods.
+
+   <!ELEMENT omit EMPTY >
+
+12.13 propertyupdate XML element
+
+   Name:       propertyupdate
+   Namespace:  DAV:
+   Purpose:    Contains a request to alter the properties on a
+   resource.
+   Description: This XML element is a container for the information
+   required to modify the properties on the resource.  This XML element
+   is multi-valued.
+
+   <!ELEMENT propertyupdate (remove | set)+ >
+
+12.13.1 remove XML element
+
+   Name:       remove
+   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 the removal of a property that does
+   not exist is not an error.  All the XML elements in a prop XML
+   element inside of a remove XML element MUST be empty, as only the
+   names of properties to be removed are required.
+
+   <!ELEMENT remove (prop) >
+
+12.13.2 set XML element
+
+   Name:       set
+   Namespace:  DAV:
+   Purpose:    Lists the DAV property values to be set for a resource.
+
+
+
+Goland, et al.              Standards Track                    [Page 67]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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 of properties that
+   are set on the resource identified by Request-URI.  If a property
+   already exists then its value is replaced. Language tagging
+   information in the property's value (in the "xml:lang" attribute, if
+   present) MUST be persistently stored along with the property, and
+   MUST be subsequently retrievable using PROPFIND.
+
+   <!ELEMENT set (prop) >
+
+12.14 propfind XML Element
+
+   Name:       propfind
+   Namespace:  DAV:
+   Purpose:    Specifies the properties to be returned from a PROPFIND
+   method.  Two special elements are specified for use with propfind,
+   allprop and propname.  If prop is used inside propfind it MUST only
+   contain property names, not values.
+
+   <!ELEMENT propfind (allprop | propname | prop) >
+
+12.14.1 allprop XML Element
+
+   Name:       allprop Namespace:  DAV:  Purpose:    The allprop XML
+   element specifies that all property names and values on the resource
+   are to be returned.
+
+   <!ELEMENT allprop EMPTY >
+
+12.14.2 propname XML Element
+
+   Name:       propname Namespace:  DAV:  Purpose:    The propname XML
+   element specifies that only a list of property names on the resource
+   is to be returned.
+
+   <!ELEMENT propname EMPTY >
+
+13 DAV Properties
+
+   For DAV properties, the name of the property is also the same as the
+   name of the XML 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 [REC-XML]. 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).
+
+
+
+
+Goland, et al.              Standards Track                    [Page 68]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+13.1 creationdate Property
+
+   Name:       creationdate
+   Namespace:  DAV:
+   Purpose:    Records the time and date the resource was created.
+   Value:      date-time ; See Appendix 2
+   Description: The creationdate property should be defined on 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).
+
+   <!ELEMENT creationdate (#PCDATA) >
+
+13.2 displayname Property
+
+   Name:       displayname
+   Namespace:  DAV:
+   Purpose:    Provides a name for the resource that is suitable for
+   presentation to a user.
+   Description: The displayname property should be defined on all DAV
+   compliant resources.  If present, the property contains a description
+   of the resource that is suitable for presentation to a user.
+
+   <!ELEMENT displayname (#PCDATA) >
+
+13.3 getcontentlanguage Property
+
+   Name:       getcontentlanguage
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Language header returned by a GET
+   without accept headers
+   Description: The getcontentlanguage property MUST be defined on any
+   DAV compliant resource that returns the Content-Language header on a
+   GET.
+   Value:      language-tag   ;language-tag is defined in section 14.13
+   of [RFC2068]
+
+   <!ELEMENT getcontentlanguage (#PCDATA) >
+
+13.4 getcontentlength Property
+
+   Name:       getcontentlength
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Length header returned by a GET
+   without accept headers.
+   Description: The getcontentlength property MUST be defined on any
+   DAV compliant resource that returns the Content-Length header in
+   response to a GET.
+
+
+
+Goland, et al.              Standards Track                    [Page 69]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Value:      content-length ; see section 14.14 of [RFC2068]
+
+   <!ELEMENT getcontentlength (#PCDATA) >
+
+13.5 getcontenttype Property
+
+   Name:       getcontenttype
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Type header returned by a GET
+   without accept headers.
+   Description: This getcontenttype property MUST be defined on any DAV
+   compliant resource that returns the Content-Type header in response
+   to a GET.
+   Value:      media-type   ; defined in section 3.7 of [RFC2068]
+
+   <!ELEMENT getcontenttype (#PCDATA) >
+
+13.6 getetag Property
+
+   Name:       getetag
+   Namespace:  DAV:
+   Purpose:    Contains the ETag header returned by a GET without
+   accept headers.
+   Description: The getetag property MUST be defined on any DAV
+   compliant resource that returns the Etag header.
+   Value:      entity-tag  ; defined in section 3.11 of [RFC2068]
+
+   <!ELEMENT getetag (#PCDATA) >
+
+13.7 getlastmodified Property
+
+   Name:       getlastmodified
+   Namespace:  DAV:
+   Purpose:    Contains the Last-Modified header returned by a GET
+   method without accept headers.
+   Description: Note that the last-modified date on a resource may
+   reflect changes in any part of the state of the resource, not
+   necessarily just a change to the response to the GET method.  For
+   example, a change in a property may cause the last-modified date to
+   change. The getlastmodified property MUST be defined on any DAV
+   compliant resource that returns the Last-Modified header in response
+   to a GET.
+   Value:      HTTP-date  ; defined in section 3.3.1 of [RFC2068]
+
+   <!ELEMENT getlastmodified (#PCDATA) >
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 70]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+13.8 lockdiscovery Property
+
+   Name:       lockdiscovery
+   Namespace:  DAV:
+   Purpose:    Describes the active locks on a resource
+   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.  The server
+   is free to withhold any or all of this information if the requesting
+   principal does not have sufficient access rights to see the requested
+   data.
+
+   <!ELEMENT lockdiscovery (activelock)* >
+
+13.8.1 Example - Retrieving the lockdiscovery Property
+
+   >>Request
+
+   PROPFIND /container/ HTTP/1.1
+   Host: www.foo.bar
+   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.foo.bar/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>
+
+
+
+Goland, et al.              Standards Track                    [Page 71]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+                                   <D:href>
+               opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
+                                   </D:href>
+                              </D:locktoken>
+                         </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.
+
+13.9 resourcetype Property
+
+   Name:       resourcetype
+   Namespace:  DAV:
+   Purpose:    Specifies the nature of the resource.
+   Description: The resourcetype property MUST be defined on all DAV
+   compliant resources.  The default value is empty.
+
+   <!ELEMENT resourcetype ANY >
+
+13.10 source Property
+
+   Name:       source
+   Namespace:  DAV:
+   Purpose:    The destination of the source link identifies the
+   resource that contains the unprocessed source of the link's source.
+   Description: The source of the link (src) is typically the URI of the
+   output resource on which the link is defined, and there is typically
+   only one destination (dst) of the link, which is the URI where the
+   unprocessed source of the resource may be accessed.  When more than
+   one link destination exists, this specification asserts no policy on
+   ordering.
+
+   <!ELEMENT source (link)* >
+
+13.10.1 Example - A source Property
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
+     <D:source>
+          <D:link>
+               <F:projfiles>Source</F:projfiles>
+               <D:src>http://foo.bar/program</D:src>
+
+
+
+Goland, et al.              Standards Track                    [Page 72]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+               <D:dst>http://foo.bar/src/main.c</D:dst>
+          </D:link>
+          <D:link>
+               <F:projfiles>Library</F:projfiles>
+               <D:src>http://foo.bar/program</D:src>
+               <D:dst>http://foo.bar/src/main.lib</D:dst>
+          </D:link>
+          <D:link>
+               <F:projfiles>Makefile</F:projfiles>
+               <D:src>http://foo.bar/program</D:src>
+               <D:dst>http://foo.bar/src/makefile</D:dst>
+          </D:link>
+     </D:source>
+   </D:prop>
+
+   In this example the resource http://foo.bar/program has a source
+   property that contains three links.  Each link contains three
+   elements, two of which, src and dst, are part of the DAV schema
+   defined in this document, and one which is defined by the schema
+   http://www.foocorp.com/project/ (Source, Library, and Makefile).  A
+   client which only implements the elements in the DAV spec will not
+   understand the foocorp elements and will ignore them, thus seeing the
+   expected source and destination links.  An enhanced client may know
+   about the foocorp elements and be able to present the user with
+   additional information about the links.  This example demonstrates
+   the power of XML markup, allowing element values to be enhanced
+   without breaking older clients.
+
+13.11 supportedlock Property
+
+   Name:       supportedlock
+   Namespace:  DAV:
+   Purpose:    To provide a listing of the lock capabilities supported
+   by the resource.
+   Description: The supportedlock property of a resource returns a
+   listing of the combinations of scope and access types which may be
+   specified in a lock request on the resource.  Note that the actual
+   contents are themselves controlled by access controls so a server is
+   not required to provide information the client is not authorized to
+   see.
+
+   <!ELEMENT supportedlock (lockentry)* >
+
+13.11.1 Example - Retrieving the supportedlock Property
+
+   >>Request
+
+   PROPFIND  /container/ HTTP/1.1
+
+
+
+Goland, et al.              Standards Track                    [Page 73]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Host: www.foo.bar
+   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.foo.bar/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>
+
+14 Instructions for Processing XML in DAV
+
+   All DAV compliant resources MUST ignore any unknown XML element and
+   all its children encountered while processing a DAV method that uses
+   XML as its command language.
+
+   This restriction also applies to the processing, by clients, of DAV
+   property values where unknown XML elements SHOULD be ignored unless
+   the property's schema declares otherwise.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 74]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   This restriction does not apply to setting dead DAV properties on the
+   server where the server MUST record unknown XML elements.
+
+   Additionally, this restriction does not apply to the use of XML where
+   XML happens to be the content type of the entity body, for example,
+   when used as the body of a PUT.
+
+   Since XML can 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 DAV client
+   MUST accept XML responses using either text/xml or application/xml.
+
+15 DAV Compliance Classes
+
+   A DAV compliant resource can choose from two classes of compliance.
+   A client can discover the compliance classes of a resource by
+   executing OPTIONS on the resource, and examining the "DAV" header
+   which is returned.
+
+   Since this document describes extensions to the HTTP/1.1 protocol,
+   minimally all DAV compliant resources, clients, and proxies MUST be
+   compliant with [RFC2068].
+
+   Compliance classes are not necessarily sequential. A resource that is
+   class 2 compliant must also be class 1 compliant; but if additional
+   compliance classes are defined later, a resource that is class 1, 2,
+   and 4 compliant might not be class 3 compliant.  Also note that
+   identifiers other than numbers may be used as compliance class
+   identifiers.
+
+15.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 value "1" in
+   the DAV header on all responses to the OPTIONS method.
+
+15.2 Class 2
+
+   A class 2 compliant resource MUST meet all class 1 requirements and
+   support the LOCK method, the supportedlock property, the
+   lockdiscovery property, the Time-Out response header and the Lock-
+   Token request header.  A class "2" compliant resource SHOULD also
+   support the Time-Out request header and the owner XML element.
+
+   Class 2 compliant resources MUST return, at minimum, the values "1"
+   and "2" in the DAV header on all responses to the OPTIONS method.
+
+
+
+Goland, et al.              Standards Track                    [Page 75]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+16 Internationalization Considerations
+
+   In the realm of internationalization, this specification complies
+   with the IETF Character Set Policy [RFC2277]. In this specification,
+   human-readable fields can be 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 character set tagging and encoding, and
+   requires that XML processors read XML elements encoded, at minimum,
+   using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.
+   XML examples in this specification demonstrate use of the charset
+   parameter of the Content-Type header, as defined in [RFC2376], as
+   well as the XML "encoding" attribute, which together provide charset
+   identification information for MIME and XML processors.
+
+   XML also provides a language tagging capability for specifying the
+   language of the contents of a particular XML element.  XML uses
+   either IANA registered language tags (see [RFC1766]) or ISO 639
+   language tags [ISO-639] in the "xml:lang" attribute of an XML element
+   to identify the language of its content and attributes.
+
+   WebDAV applications MUST support the character set tagging, character
+   set encoding, and the language tagging functionality of the XML
+   specification.  Implementors of WebDAV applications are strongly
+   encouraged to read "XML Media Types" [RFC2376] for instruction on
+   which MIME media type to use for XML transport, and on use of the
+   charset parameter of the Content-Type header.
+
+   Names used within this specification fall into three categories:
+   names of protocol elements such as methods and headers, names of XML
+   elements, and names of properties.  Naming of protocol elements
+   follows the precedent of HTTP, using English names encoded in USASCII
+   for methods and headers.  Since these protocol elements are not
+   visible to users, and are in fact simply long token identifiers, they
+   do not need to support encoding in multiple character sets.
+   Similarly, though the names of XML elements used in this
+   specification are English names encoded in UTF-8, these names are not
+   visible to the user, and hence do not need to support multiple
+   character set encodings.
+
+   The name of a property defined on a resource is a URI.  Although some
+   applications (e.g., a generic property viewer) will display property
+   URIs directly to their users, it is expected that the typical
+   application will use a fixed set of properties, and will provide a
+   mapping from the property name URI to a human-readable field when
+   displaying the property name to a user.  It is only in the case where
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 76]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   the set of properties is not known ahead of time that 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 code (e.g., 423 (Locked)).  While the possibility exists that
+   a poorly crafted user agent would display this message to a user,
+   internationalized applications will ignore this message, and display
+   an appropriate message in the user's language and character set.
+
+   Since interoperation of clients and servers does not require locale
+   information, this specification does not specify any mechanism for
+   transmission of this information.
+
+17 Security Considerations
+
+   This section is provided to detail issues concerning security
+   implications of which WebDAV applications need to be aware.
+
+   All of the security considerations of HTTP/1.1 (discussed in
+   [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In
+   addition, the security risks inherent in remote authoring require
+   stronger authentication technology, introduce several new privacy
+   concerns, and may increase the hazards from poor server design.
+   These issues are detailed below.
+
+17.1 Authentication of Clients
+
+   Due to their emphasis on authoring, WebDAV servers need to use
+   authentication technology to protect not just access to a network
+   resource, but the integrity of the resource as well.  Furthermore,
+   the introduction of locking functionality requires support for
+   authentication.
+
+   A password sent in the clear over an insecure channel is an
+   inadequate means for protecting the accessibility and integrity of a
+   resource as 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 the connection is
+   secure. Furthermore, a WebDAV server MUST NOT send Basic
+   authentication credentials in a WWW-Authenticate header unless 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, for example, an
+   isolated network in a building with restricted access.
+
+
+
+Goland, et al.              Standards Track                    [Page 77]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   WebDAV applications MUST support the Digest authentication scheme
+   [RFC2069]. Since Digest authentication verifies that both parties to
+   a communication know a shared secret, a password, without having to
+   send that secret in the clear, Digest authentication avoids the
+   security problems inherent in Basic authentication while providing a
+   level of authentication which is useful in a wide range of scenarios.
+
+17.2 Denial of Service
+
+   Denial of service attacks are of special concern to WebDAV servers.
+   WebDAV plus HTTP enables denial of service attacks on every part of a
+   system's resources.
+
+   The underlying storage can be 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 be aware of the possibility of a denial of
+   service attack at all levels.
+
+17.3 Security through Obscurity
+
+   WebDAV provides, through the PROPFIND method, a mechanism for listing
+   the member resources of a collection.  This greatly diminishes the
+   effectiveness of security or privacy techniques that rely only on the
+   difficulty of discovering the names of network resources.  Users of
+   WebDAV servers are encouraged to use access control techniques to
+   prevent unwanted access to resources, rather than depending on the
+   relative obscurity of their resource names.
+
+17.4 Privacy Issues Connected to Locks
+
+   When submitting a lock request a user agent may also submit an owner
+   XML field giving contact information for the person taking out the
+   lock (for those cases where a person, rather than a robot, is taking
+   out the lock). This contact information is stored in a lockdiscovery
+   property on the resource, and can be used by other collaborators to
+   begin negotiation over access to the resource.  However, in many
+   cases this contact information can be very private, and should not be
+   widely disseminated.  Servers SHOULD limit read access to the
+   lockdiscovery property as appropriate.  Furthermore, user agents
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 78]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   SHOULD provide control over whether contact information is sent at
+   all, and if contact information is sent, control over exactly what
+   information is sent.
+
+17.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 widespread access to a resource's
+   property data.  To reduce the risk of inadvertent release of private
+   information via properties, servers are encouraged to develop access
+   control mechanisms that separate read access to the resource body and
+   read access to the resource's properties.  This allows a user to
+   control the dissemination of their property data without overly
+   restricting access to the resource's contents.
+
+17.6 Reduction of Security due to Source Link
+
+   HTTP/1.1 warns against providing read access to script code because
+   it may contain sensitive information.  Yet WebDAV, via its source
+   link facility, can potentially provide a URI for script resources so
+   they may be authored.  For HTTP/1.1, a server could reasonably
+   prevent access to source resources due to the predominance of read-
+   only access.  WebDAV, with its emphasis on authoring, encourages read
+   and write access to source resources, and provides the source link
+   facility to identify the source.  This reduces the security benefits
+   of eliminating access to source resources.  Users and administrators
+   of WebDAV servers should be very cautious when allowing remote
+   authoring of scripts, limiting read and write access to the source
+   resources to authorized principals.
+
+17.7 Implications of XML External Entities
+
+   XML supports a facility known as "external entities", defined in
+   section 4.2.2 of [REC-XML], which instruct an XML processor to
+   retrieve and perform an inline include of XML located at a particular
+   URI. An external XML entity can be used 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 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 [REC-XML]. However, [REC-XML] does state that an XML
+   processor may, at its discretion, include the external XML entity.
+
+   External XML entities have no inherent trustworthiness and are
+   subject to all the attacks that are endemic to any HTTP GET request.
+   Furthermore, it is possible for an external XML entity to modify the
+   DTD, and hence affect the final form of an XML document, in the worst
+
+
+
+Goland, et al.              Standards Track                    [Page 79]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   case significantly modifying its semantics, or exposing the XML
+   processor to the security risks discussed in [RFC2376].  Therefore,
+   implementers must be aware that external XML entities should be
+   treated as untrustworthy.
+
+   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.
+
+17.8 Risks Connected with Lock Tokens
+
+   This specification, in section 6.4, requires the use of Universal
+   Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
+   their uniqueness across space and time.  UUIDs, as defined in [ISO-
+   11578], contain a "node" field which "consists of the IEEE address,
+   usually the host address.  For systems with multiple IEEE 802 nodes,
+   any available node address can be used."  Since a WebDAV server will
+   issue many locks over its lifetime, the implication is that it will
+   also be publicly exposing its IEEE 802 address.
+
+   There are several risks associated with exposure of IEEE 802
+   addresses.  Using the IEEE 802 address:
+
+   * It is possible to track the movement of hardware from subnet to
+   subnet.
+
+   * It may be possible to identify the manufacturer of the hardware
+   running a WebDAV server.
+
+   * It may be possible to determine the number of each type of computer
+   running WebDAV.
+
+   Section 6.4.1 of this specification details an alternate mechanism
+   for generating the "node" field 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.
+
+18 IANA Considerations
+
+   This document defines two namespaces, the namespace of property
+   names, and the namespace of WebDAV-specific XML elements used within
+   property values.
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 80]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   URIs are used for both names, for several reasons. Assignment of a
+   URI does not require a request to a central naming authority, and
+   hence allow WebDAV property names and XML elements to be quickly
+   defined by any WebDAV user or application.  URIs also provide a
+   unique address space, ensuring that the distributed users of WebDAV
+   will not have collisions among the property names and XML elements
+   they create.
+
+   This specification defines a distinguished set of property names and
+   XML elements that are understood by all WebDAV applications.  The
+   property names and XML elements in this specification are all derived
+   from the base URI DAV: by adding a suffix to this URI, for example,
+   DAV:creationdate for the "creationdate" property.
+
+   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 with
+   "opaquelocktoken:" for use by this specification, its revisions, and
+   related WebDAV specifications.
+
+19 Intellectual Property
+
+   The following notice is copied from RFC 2026 [RFC2026], section 10.4,
+   and describes the position of the IETF concerning intellectual
+   property claims made against this document.
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use other technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+Goland, et al.              Standards Track                    [Page 81]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+20 Acknowledgements
+
+   A specification such as this thrives on piercing critical review and
+   withers from apathetic neglect.  The authors gratefully acknowledge
+   the contributions of the following people, whose insights were so
+   valuable at every stage of our work.
+
+   Terry Allen, Harald Alvestrand, 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, and Lauren Wood.
+
+   Two from this list deserve special mention.  The contributions by
+   Larry Masinter have been invaluable, both in helping the formation of
+   the working group and in patiently coaching the authors along the
+   way.  In so many ways he has set high standards we have toiled to
+   meet. The contributions of Judith Slein in clarifying the
+   requirements, and in 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 DTD.
+
+21 References
+
+21.1 Normative References
+
+   [RFC1766]       Alvestrand, H., "Tags for the Identification of
+                   Languages", RFC 1766, March 1995.
+
+   [RFC2277]       Alvestrand, H., "IETF Policy on Character Sets and
+                   Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 82]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   [RFC2396]       Berners-Lee, T., Fielding, R. and L. Masinter,
+                   "Uniform Resource Identifiers (URI): Generic Syntax",
+                   RFC 2396, August 1998.
+
+   [REC-XML]       T. Bray, J. Paoli, C. M. Sperberg-McQueen,
+                   "Extensible Markup Language (XML)." World Wide Web
+                   Consortium Recommendation REC-xml-19980210.
+                   http://www.w3.org/TR/1998/REC-xml-19980210.
+
+   [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
+                   XML". World Wide Web Consortium Recommendation REC-
+                   xml-names-19990114.  http://www.w3.org/TR/1999/REC-
+                   xml-names-19990114/
+
+   [RFC2069]       Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
+                   P, Luotonen, A., Sink, E. and L. Stewart, "An
+                   Extension to HTTP :  Digest Access Authentication",
+                   RFC 2069, January 1997.
+
+   [RFC2068]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
+                   T. Berners-Lee, "Hypertext Transfer Protocol --
+                   HTTP/1.1", RFC 2068, January 1997.
+
+   [ISO-639]       ISO (International Organization for Standardization).
+                   ISO 639:1988. "Code for the representation of names
+                   of languages."
+
+   [ISO-8601]      ISO (International Organization for Standardization).
+                   ISO 8601:1988. "Data elements and interchange formats
+                   - Information interchange - Representation of dates
+                   and times."
+
+   [ISO-11578]     ISO (International Organization for Standardization).
+                   ISO/IEC 11578:1996. "Information technology - Open
+                   Systems Interconnection - Remote Procedure Call
+                   (RPC)"
+
+   [RFC2141]       Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [UTF-8]         Yergeau, F., "UTF-8, a transformation format of
+                   Unicode and ISO 10646", RFC 2279, January 1998.
+
+21.2 Informational References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process - Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 83]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   [RFC1807]  Lasher, R. and D. Cohen, "A Format for Bibliographic
+              Records", RFC 1807, June 1995.
+
+   [WF]       C. Lagoze, "The Warwick Framework: A Container
+              Architecture for Diverse Sets of Metadata", D-Lib
+              Magazine, July/August 1996.
+              http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
+
+   [USMARC]   Network Development and MARC Standards, Office, ed. 1994.
+              "USMARC Format for Bibliographic Data", 1994. Washington,
+              DC: Cataloging Distribution Service, Library of Congress.
+
+   [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
+              Label Distribution Label Syntax and Communication
+              Protocols" Version 1.1, World Wide Web Consortium
+              Recommendation REC-PICS-labels-961031.
+              http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
+
+   [RFC2291]  Slein, J., Vitali, F., Whitehead, E. and D. Durand,
+              "Requirements for Distributed Authoring and Versioning
+              Protocol for the World Wide Web", RFC 2291, February 1998.
+
+   [RFC2413]  Weibel, S.,  Kunze, J., Lagoze, C. and M. Wolf, "Dublin
+              Core Metadata for Resource Discovery", RFC 2413, September
+              1998.
+
+   [RFC2376]  Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
+              July 1998.
+
+22 Authors' Addresses
+
+   Y. Y. Goland
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   EMail: yarong@microsoft.com
+
+
+   E. J. Whitehead, Jr.
+   Dept. Of Information and Computer Science
+   University of California, Irvine
+   Irvine, CA 92697-3425
+
+   EMail: ejw@ics.uci.edu
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 84]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 85]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+23 Appendices
+
+23.1 Appendix 1 - WebDAV Document Type Definition
+
+   This section provides a document type definition, following the rules
+   in [REC-XML], for the XML elements used in the protocol stream and in
+   the values of properties. It collects the element definitions given
+   in sections 12 and 13.
+
+   <!DOCTYPE webdav-1.0 [
+
+   <!--============ XML Elements from Section 12 ==================-->
+
+   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
+   locktoken?) >
+
+   <!ELEMENT lockentry (lockscope, locktype) >
+   <!ELEMENT lockinfo (lockscope, locktype, owner?) >
+
+   <!ELEMENT locktype (write) >
+   <!ELEMENT write EMPTY >
+
+   <!ELEMENT lockscope (exclusive | shared) >
+   <!ELEMENT exclusive EMPTY >
+   <!ELEMENT shared EMPTY >
+
+   <!ELEMENT depth (#PCDATA) >
+
+   <!ELEMENT owner ANY >
+
+   <!ELEMENT timeout (#PCDATA) >
+
+   <!ELEMENT locktoken (href+) >
+
+   <!ELEMENT href (#PCDATA) >
+
+   <!ELEMENT link (src+, dst+) >
+   <!ELEMENT dst (#PCDATA) >
+   <!ELEMENT src (#PCDATA) >
+
+   <!ELEMENT multistatus (response+, responsedescription?) >
+
+   <!ELEMENT response (href, ((href*, status)|(propstat+)),
+   responsedescription?) >
+   <!ELEMENT status (#PCDATA) >
+   <!ELEMENT propstat (prop, status, responsedescription?) >
+   <!ELEMENT responsedescription (#PCDATA) >
+
+
+
+
+Goland, et al.              Standards Track                    [Page 86]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   <!ELEMENT prop ANY >
+
+   <!ELEMENT propertybehavior (omit | keepalive) >
+   <!ELEMENT omit EMPTY >
+
+   <!ELEMENT keepalive (#PCDATA | href+) >
+
+   <!ELEMENT propertyupdate (remove | set)+ >
+   <!ELEMENT remove (prop) >
+   <!ELEMENT set (prop) >
+
+   <!ELEMENT propfind (allprop | propname | prop) >
+   <!ELEMENT allprop EMPTY >
+   <!ELEMENT propname EMPTY >
+
+   <!ELEMENT collection EMPTY >
+
+   <!--=========== Property Elements from Section 13 ===============-->
+   <!ELEMENT creationdate (#PCDATA) >
+   <!ELEMENT displayname (#PCDATA) >
+   <!ELEMENT getcontentlanguage (#PCDATA) >
+   <!ELEMENT getcontentlength (#PCDATA) >
+   <!ELEMENT getcontenttype (#PCDATA) >
+   <!ELEMENT getetag (#PCDATA) >
+   <!ELEMENT getlastmodified (#PCDATA) >
+   <!ELEMENT lockdiscovery (activelock)* >
+   <!ELEMENT resourcetype ANY >
+   <!ELEMENT source (link)* >
+   <!ELEMENT supportedlock (lockentry)* >
+   ]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 87]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+23.2 Appendix 2 - ISO 8601 Date and Time Profile
+
+   The creationdate property specifies the use of the ISO 8601 date
+   format [ISO-8601].  This section defines a profile of the ISO 8601
+   date format for use with this specification.  This profile is quoted
+   from an Internet-Draft by Chris Newman, and is mentioned here to
+   properly attribute his work.
+
+   date-time       = full-date "T" full-time
+
+   full-date       = date-fullyear "-" date-month "-" date-mday
+   full-time       = partial-time time-offset
+
+   date-fullyear   = 4DIGIT
+   date-month      = 2DIGIT  ; 01-12
+   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
+   month/year
+   time-hour       = 2DIGIT  ; 00-23
+   time-minute     = 2DIGIT  ; 00-59
+   time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
+   time-secfrac    = "." 1*DIGIT
+   time-numoffset  = ("+" / "-") time-hour ":" time-minute
+   time-offset     = "Z" / time-numoffset
+
+   partial-time    = time-hour ":" time-minute ":" time-second
+                    [time-secfrac]
+
+   Numeric offsets are calculated as local time minus UTC (Coordinated
+   Universal Time).  So the equivalent time in UTC can be determined by
+   subtracting the offset from the local time.  For example, 18:50:00-
+   04:00 is the same time as 22:58:00Z.
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   from an offset of "Z" which implies that UTC is the preferred
+   reference point for the specified time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 88]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+23.3 Appendix 3 - Notes on Processing XML Elements
+
+23.3.1 Notes on Empty XML Elements
+
+   XML supports two mechanisms for indicating that an XML element does
+   not have any content.  The first is to declare an XML element of the
+   form <A></A>.  The second is to declare an XML element of the form
+   <A/>.  The two XML elements are semantically identical.
+
+   It is a violation of the XML specification to use the <A></A> form if
+   the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT
+   A EMPTY>).  If such a statement is included, then the empty element
+   format, <A/> must be used.  If the element is not declared to be
+   EMPTY, then either form <A></A> or <A/> may be used for empty
+   elements.
+
+   23.3.2 Notes on Illegal XML Processing
+
+   XML is a flexible data format that 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 be applied inappropriately.  XML is extremely flexible in
+   dealing with issues of white space, element ordering, inserting new
+   elements, etc.  This flexibility does not require extension,
+   especially not in the area of the meaning of elements.
+
+   There is no kindness in accepting illegal combinations of XML
+   elements.  At best it will cause an unwanted result and at worst it
+   can cause real damage.
+
+23.3.2.1  Example - XML Syntax Error
+
+   The following request body for 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 of the propfind element only allows for the allprop or
+   the propname element, not both.  Thus the above is an error and must
+   be responded to with a 400 (Bad Request).
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 89]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   Imagine, however, that a server wanted to be "kind" and decided to
+   pick the allprop element as the true element and respond to it.  A
+   client running over a bandwidth limited line who intended to execute
+   a propname would be in for a big surprise if the server treated the
+   command as an allprop.
+
+   Additionally, if a server were lenient and decided to reply to this
+   request, the results would vary randomly from server to server, with
+   some servers executing the allprop directive, and others executing
+   the propname directive. This reduces interoperability rather than
+   increasing it.
+
+23.3.2.2  Example - Unknown XML Element
+
+   The previous example was illegal because it contained two elements
+   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 is the
+   request body of a PROPFIND and, like the previous example, must be
+   rejected with a 400 (Bad Request) by a server that does not
+   understand the expired-props element.
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:"
+   xmlns:E="http://www.foo.bar/standards/props/">
+     <E:expired-props/>
+   </D:propfind>
+
+   To understand why a 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.foo.bar/standards/props/">
+   </D:propfind>
+
+   As the server does not understand the expired-props element,
+   according to the WebDAV-specific XML processing rules specified in
+   section 14, it must ignore it.  Thus the server sees an empty
+   propfind, which by the definition of the propfind element is illegal.
+
+   Please note that had the extension been additive it would not
+   necessarily have resulted in a 400 (Bad Request).  For example,
+   imagine the following request body for a PROPFIND:
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:"
+               xmlns:E="http://www.foo.bar/standards/props/">
+
+
+
+Goland, et al.              Standards Track                    [Page 90]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+     <D:propname/>
+     <E:leave-out>*boss*</E:leave-out>
+   </D:propfind>
+
+   The previous example contains the fictitious element leave-out. Its
+   purpose is to prevent the return of any property whose name matches
+   the submitted pattern.  If the previous example were submitted to a
+   server unfamiliar with leave-out, the only result would be that the
+   leave-out element would be ignored and a propname would be executed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 91]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+23.4 Appendix 4 -- XML Namespaces for WebDAV
+
+23.4.1 Introduction
+
+   All DAV compliant systems MUST support the XML namespace extensions
+   as specified in [REC-XML-NAMES].
+
+23.4.2 Meaning of Qualified Names
+
+   [Note to the reader: This section does not appear in [REC-XML-NAMES],
+   but is necessary to avoid ambiguity for WebDAV XML processors.]
+
+   WebDAV compliant XML processors MUST interpret a qualified name as a
+   URI constructed by appending the LocalPart to the namespace name URI.
+
+   Example
+
+   <del:glider xmlns:del="http://www.del.jensen.org/">
+     <del:glidername>
+          Johnny Updraft
+     </del:glidername>
+     <del:glideraccidents/>
+   </del:glider>
+
+   In this example, the qualified element name "del:glider" is
+   interpreted as the URL "http://www.del.jensen.org/glider".
+
+   <bar:glider xmlns:del="http://www.del.jensen.org/">
+     <bar:glidername>
+          Johnny Updraft
+     </bar:glidername>
+     <bar:glideraccidents/>
+   </bar:glider>
+
+   Even though this example is syntactically different from the previous
+   example, it is semantically identical.  Each instance of the
+   namespace name "bar" is replaced with "http://www.del.jensen.org/"
+   and then appended to the local name for each element tag.  The
+   resulting tag names in this example are exactly the same as for the
+   previous example.
+
+   <foo:r xmlns:foo="http://www.del.jensen.org/glide">
+     <foo:rname>
+          Johnny Updraft
+     </foo:rname>
+     <foo:raccidents/>
+   </foo:r>
+
+
+
+
+Goland, et al.              Standards Track                    [Page 92]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+   This example is semantically identical to the two previous ones.
+   Each instance of the namespace name "foo" is replaced with
+   "http://www.del.jensen.org/glide" which is then appended to the local
+   name for each element tag, the resulting tag names are identical to
+   those in the previous examples.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 93]
+
+RFC 2518                         WEBDAV                    February 1999
+
+
+24.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goland, et al.              Standards Track                    [Page 94]
+