Checkpoint commit of work on RDF metastore, DAV handler, and initial experiment with Rubigen
36 files changed, 3633 insertions(+), 145 deletions(-)

M Rakefile
M etc/thingfish.conf-testing
M experiments/rdf-metastore-spike.rb
M lib/thingfish.rb
M lib/thingfish/filestore.rb
M lib/thingfish/filter.rb
M lib/thingfish/handler.rb
M lib/thingfish/handler/default.rb
M lib/thingfish/metastore.rb
M plugins/thingfish-davhandler/README
A => plugins/thingfish-davhandler/docs/rfc2518.html
M plugins/thingfish-davhandler/lib/thingfish/handler/dav.rb
A => plugins/thingfish-davhandler/spec/data/propfind_named_properties.txt
A => plugins/thingfish-davhandler/spec/davhandler_spec.rb
M plugins/thingfish-fsfs/lib/thingfish/filestore/filesystem.rb
M plugins/thingfish-rdfms/lib/thingfish/metastore/rdf.rb
M plugins/thingfish-rdfms/spec/rdfms_spec.rb
M plugins/thingfish-xmlfilter/Rakefile
A => script/destroy
A => script/generate
M spec/defaulthandler_spec.rb
A => spec/generators/filestore_generator_spec.rb
A => spec/generators/filter_generator_spec.rb
A => spec/generators/handler_generator_spec.rb
A => spec/generators/metastore_generator_spec.rb
M spec/lib/constants.rb
A => spec/lib/generator_helpers.rb
M spec/lib/helpers.rb
A => thingfish_generators/filestore/USAGE
A => thingfish_generators/filestore/filestore_generator.rb
A => thingfish_generators/filter/USAGE
A => thingfish_generators/filter/filter_generator.rb
A => thingfish_generators/handler/USAGE
A => thingfish_generators/handler/handler_generator.rb
A => thingfish_generators/metastore/USAGE
A => thingfish_generators/metastore/metastore_generator.rb
M Rakefile +1 -1
 # Plugin constants
 PLUGINDIR        = BASEDIR + 'plugins'
 PLUGINS          = Pathname.glob( PLUGINDIR + '*' ).select {|path| }
-PLUGIN_LIBS      = PLUGINS.collect {|dir| dir + 'lib' }
+PLUGIN_LIBS      = PLUGINS.collect {|dir| dir + 'lib/*.rb' }
 PLUGIN_RAKEFILES = PLUGINS.collect {|dir| dir + 'Rakefile' }
 PLUGIN_SPECFILES = PLUGINS.collect {|dir| Pathname.glob(dir + 'spec/*_spec.rb') }.flatten

M etc/thingfish.conf-testing +0 -1
@@ 25,7 25,6 @@ plugins:
         root: /tmp/thingfish
         name: sqlite3
-        root: /tmp/thingfish
         resource_dir: plugins/thingfish-sqlite3ms/resources
             tag: list

M experiments/rdf-metastore-spike.rb +6 -1
@@ 60,7 60,12 @@ module ThingFish
 	class Metastore
 		def initialize
-			@store = 'memory', 'thingfish' )
+			# @store = 'memory', 'thingfish' )
+			# @store = 'bdb', 'thingfish', '/tmp/tfbdb', true, true )
+			# @store = 'sqlite', '/tmp/thingfish/sqlite-ts.db', 'new=true' )
+			# @store = 'hashes', 'thingfish', "new='yes',write='yes',hash_type='memory',dir='.',contexts='yes'" )
+			@store = 'hashes', 'thingfish', "hash-type='memory',new='yes', dir='.', write='yes',contexts='yes'" )
+			# @store = 'hashes', 'thingfish', "new='yes',hash_type='bdb',dir='/tmp/thingfish'" )
 			@model = @store )

M lib/thingfish.rb +7 -0
@@ 29,6 29,7 @@ end
 require 'logger'
 require 'uuidtools'
+require 'pluginfactory'
 ### Toplevel namespace module

@@ 61,6 62,12 @@ module ThingFish
+	# Hook PluginFactory's logging up to the ThingFish logger
+	PluginFactory.logger_callback = lambda {|level, msg|
+		ThingFish.logger.send( level, msg )
+	}
 	### Reset the global logger object to the default
 	def self::reset_logger
 		self.logger = self.default_logger

M lib/thingfish/filestore.rb +0 -8
@@ 76,14 76,6 @@ class ThingFish::FileStore
-	### PluginFactory interface: Return a sprintf string which describes the naming
-	### convention of plugin gems for this class. The results will be used as an
-	### argument to the 'Kernel::gem' function.
-	def self::rubygem_name_pattern
-		'thingfish-%sfs'
-	end
 	###	I N S T A N C E   M E T H O D S

M lib/thingfish/filter.rb +0 -8
@@ 62,14 62,6 @@ class ThingFish::Filter
-	### PluginFactory interface: Return a sprintf string which describes the naming
-	### convention of plugin gems for this class. The results will be used as an
-	### argument to the 'Kernel::gem' function.
-	def self::rubygem_name_pattern
-		'thingfish-%sfilter'
-	end
 	###	I N S T A N C E   M E T H O D S

M lib/thingfish/handler.rb +0 -8
@@ 66,14 66,6 @@ class ThingFish::Handler
-	### PluginFactory interface: Return a sprintf string which describes the naming
-	### convention of plugin gems for this class. The results will be used as an
-	### argument to the 'Kernel::gem' function.
-	def self::rubygem_name_pattern
-		'thingfish-%shandler'
-	end
 	###	I N S T A N C E   M E T H O D S

M lib/thingfish/handler/default.rb +1 -0
@@ 342,6 342,7 @@ class ThingFish::DefaultHandler < ThingF
 			disposition << %{modification-date="%s"} % [ modtime.rfc822 ]
+		self.log.debug "Setting Content-Disposition to: %p" % [disposition.join('; ')]
 		response.headers[ :content_disposition ] = disposition.join('; ')

M lib/thingfish/metastore.rb +0 -8
@@ 129,14 129,6 @@ class ThingFish::MetaStore
-	### PluginFactory interface: Return a sprintf string which describes the naming
-	### convention of plugin gems for this class. The results will be used as an
-	### argument to the 'Kernel::gem' function.
-	def self::rubygem_name_pattern
-		'thingfish-%sms'
-	end
 	###	I N S T A N C E   M E T H O D S

M plugins/thingfish-davhandler/README +2 -2
@@ 1,7 1,7 @@ 
 == Thingfish::DavHandler
-A handler plugin that adds the ability to mount the ThingFish instance as a WebDAV
+A handler plugin that adds the ability to access a collection of resources in 
+a ThingFish instance via WebDAV (RFC 2518).
 == Authors

A => plugins/thingfish-davhandler/docs/rfc2518.html +2629 -0
@@ 0,0 1,2629 @@ 
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html lang="en"><head profile="">
+      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>HTTP Extensions for Distributed Authoring -- WEBDAV</title>
+   <style type="text/css" title="Xml2Rfc (sans serif)">
+a {
+  text-decoration: none;
+a:hover {
+  text-decoration: underline;
+a:active {
+  text-decoration: underline;
+address {
+  margin-top: 1em;
+  margin-left: 2em;
+  font-style: normal;
+body {
+  color: #000000;
+  font-family: verdana, helvetica, arial, sans-serif;
+  font-size: 10pt;
+cite {
+  font-style: normal;
+dd {
+  margin-right: 2em;
+dl {
+  margin-left: 2em;
+dl.empty dd {
+  margin-top: .5em;
+dl p {
+  margin-left: 0em;
+dt {
+  margin-top: .5em;
+h1 {
+  color: #333333;
+  font-size: 14pt;
+  line-height: 21pt;
+  page-break-after: avoid;
+} {
+  page-break-before: always;
+h1 a {
+  color: #333333;
+h2 {
+  color: #000000;
+  font-size: 12pt;
+  line-height: 15pt;
+  page-break-after: avoid;
+h2 a {
+  color: #000000;
+h3 {
+  color: #000000;
+  font-size: 10pt;
+  page-break-after: avoid;
+h3 a {
+  color: #000000;
+h4 {
+  color: #000000;
+  font-size: 10pt;
+  page-break-after: avoid;
+h4 a {
+  color: #000000;
+h5 {
+  color: #000000;
+  font-size: 10pt;
+  page-break-after: avoid;
+h5 a {
+  color: #000000;
+img {
+  margin-left: 3em;
+li {
+  margin-left: 2em;
+  margin-right: 2em;
+ol {
+  margin-left: 2em;
+  margin-right: 2em;
+ol p {
+  margin-left: 0em;
+p {
+  margin-left: 2em;
+  margin-right: 2em;
+pre {
+  margin-left: 3em;
+  background-color: lightyellow;
+  padding: .25em;
+pre.text2 {
+  border-style: dotted;
+  border-width: 1px;
+  background-color: #f0f0f0;
+  width: 69em;
+pre.inline {
+  background-color: white;
+  padding: 0em;
+pre.text {
+  border-style: dotted;
+  border-width: 1px;
+  background-color: #f8f8f8;
+  width: 69em;
+pre.drawing {
+  border-style: solid;
+  border-width: 1px;
+  background-color: #f8f8f8;
+  padding: 2em;
+table {
+  margin-left: 2em;
+} {
+  vertical-align: top;
+table.full {
+  border-style: outset;
+  border-width: 1px;
+table.headers {
+  border-style: outset;
+  border-width: 1px;
+} td {
+  vertical-align: top;
+table.full td {
+  border-style: inset;
+  border-width: 1px;
+} th {
+  vertical-align: top;
+table.full th {
+  border-style: inset;
+  border-width: 1px;
+table.headers th {
+  border-style: none none inset none;
+  border-width: 1px;
+table.header {
+  width: 95%;
+  font-size: 10pt;
+  color: white;
+} {
+  vertical-align: top;
+td.topnowrap {
+  vertical-align: top;
+  white-space: nowrap; 
+td.header {
+  background-color: gray;
+  width: 50%;
+td.reference {
+  vertical-align: top;
+  white-space: nowrap;
+  padding-right: 1em;
+thead {
+  display:table-header-group;
+ul.toc {
+  list-style: none;
+  margin-left: 1.5em;
+  margin-right: 0em;
+  padding-left: 0em;
+li.tocline0 {
+  line-height: 150%;
+  font-weight: bold;
+  font-size: 10pt;
+  margin-left: 0em;
+  margin-right: 0em;
+li.tocline1 {
+  line-height: normal;
+  font-weight: normal;
+  font-size: 9pt;
+  margin-left: 0em;
+  margin-right: 0em;
+li.tocline2 {
+  font-size: 0pt;
+ul p {
+  margin-left: 0em;
+ul.ind {
+  list-style: none;
+  margin-left: 1.5em;
+  margin-right: 0em;
+  padding-left: 0em;
+li.indline0 {
+  font-weight: bold;
+  line-height: 200%;
+  margin-left: 0em;
+  margin-right: 0em;
+li.indline1 {
+  font-weight: normal;
+  line-height: 150%;
+  margin-left: 0em;
+  margin-right: 0em;
+.bcp14 {
+  font-style: normal;
+  text-transform: lowercase;
+  font-variant: small-caps;
+.comment {
+  background-color: yellow;
+} {
+  text-align: center;
+.error {
+  color: red;
+  font-style: italic;
+  font-weight: bold;
+.figure {
+  font-weight: bold;
+  text-align: center;
+  font-size: 9pt;
+.filename {
+  color: #333333;
+  font-weight: bold;
+  font-size: 12pt;
+  line-height: 21pt;
+  text-align: center;
+.fn {
+  font-weight: bold;
+.hidden {
+  display: none;
+.left {
+  text-align: left;
+.right {
+  text-align: right;
+.title {
+  color: #990000;
+  font-size: 18pt;
+  line-height: 18pt;
+  font-weight: bold;
+  text-align: center;
+  margin-top: 36pt;
+.vcardline {
+  display: block;
+.warning {
+  font-size: 14pt;
+  background-color: yellow;
+@media print {
+  .noprint {
+    display: none;
+  }
+  a {
+    color: black;
+    text-decoration: none;
+  }
+  table.header {
+    width: 90%;
+  }
+  td.header {
+    width: 50%;
+    color: black;
+    background-color: white;
+    vertical-align: top;
+    font-size: 12pt;
+  }
+  ul.toc a::after {
+    content: leader('.') target-counter(attr(href), page);
+  }
+  a.iref {
+    content: target-counter(attr(href), page);
+  }
+  .print2col {
+    column-count: 2;
+    -moz-column-count: 2;
+    column-fill: auto;
+  }
+@page {
+  @top-left {
+       content: "RFC 2518"; 
+  } 
+  @top-right {
+       content: "February 1999"; 
+  } 
+  @top-center {
+       content: "WEBDAV"; 
+  } 
+  @bottom-left {
+       content: "Goland, et al."; 
+  } 
+  @bottom-center {
+       content: "Standards Track"; 
+  } 
+  @bottom-right {
+       content: "[Page " counter(page) "]"; 
+  } 
+@page:first { 
+    @top-left {
+      content: normal;
+    }
+    @top-right {
+      content: normal;
+    }
+    @top-center {
+      content: normal;
+    }
+</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Notational Conventions" href="#rfc.section.2"><link rel="Chapter" title="3 Terminology" href="#rfc.section.3"><link rel="Chapter" title="4 Data Model for Resource Properties" href="#rfc.section.4"><link rel="Chapter" title="5 Collections of Web Resources" href="#rfc.section.5"><link rel="Chapter" title="6 Locking" href="#rfc.section.6"><link rel="Chapter" title="7 Write Lock" href="#rfc.section.7"><link rel="Chapter" title="8 HTTP Methods for Distributed Authoring" href="#rfc.section.8"><link rel="Chapter" title="9 HTTP Headers for Distributed Authoring" href="#rfc.section.9"><link rel="Chapter" title="10 Status Code Extensions to HTTP/1.1" href="#rfc.section.10"><link rel="Chapter" title="11 Multi-Status Response" href="#rfc.section.11"><link rel="Chapter" title="12 XML Element Definitions" href="#rfc.section.12"><link rel="Chapter" title="13 DAV Properties" href="#rfc.section.13"><link rel="Chapter" title="14 Instructions for Processing XML in DAV" href="#rfc.section.14"><link rel="Chapter" title="15 DAV Compliance Classes" href="#rfc.section.15"><link rel="Chapter" title="16 Internationalization Considerations" href="#rfc.section.16"><link rel="Chapter" title="17 Security Considerations" href="#rfc.section.17"><link rel="Chapter" title="18 IANA Considerations" href="#rfc.section.18"><link rel="Chapter" title="19 Intellectual Property" href="#rfc.section.19"><link rel="Chapter" title="20 Acknowledgements" href="#rfc.section.20"><link rel="Chapter" href="#rfc.section.21" title="21 References"><link rel="Appendix" title="23 Appendices" href="#rfc.section.23"><link rel="Alternate" title="Authorative ASCII version" href=""><meta name="generator" content=", Revision 1.341, 2007/07/21 13:59:39, XSLT vendor: SAXON 6.5.3 from Michael Kay"><link rel="schema.DC" href=""><meta name="DC.Creator" content="Goland, Y."><meta name="DC.Creator" content="Whitehead, E."><meta name="DC.Creator" content="Faizi, A."><meta name="DC.Creator" content="Carter, S.R."><meta name="DC.Creator" content="Jensen, D."><meta name="DC.Identifier" content="urn:ietf:rfc:2518"><meta name="DC.Date.Issued" scheme="ISO8601" content="1999-02"><meta name="DC.Description.Abstract" content="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)."></head><body><table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"><tbody><tr><td class="header left">Network Working Group</td><td class="header right">Y. Goland</td></tr><tr><td class="header left">Request for Comments: 2518</td><td class="header right">Microsoft</td></tr><tr><td class="header left">Category: Standards Track</td><td class="header right">E. Whitehead</td></tr><tr><td class="header left"></td><td class="header right">UC Irvine</td></tr><tr><td class="header left"></td><td class="header right">A. Faizi</td></tr><tr><td class="header left"></td><td class="header right">Netscape</td></tr><tr><td class="header left"></td><td class="header right">S.R. Carter</td></tr><tr><td class="header left"></td><td class="header right">D. Jensen</td></tr><tr><td class="header left"></td><td class="header right">Novell</td></tr><tr><td class="header left"></td><td class="header right">February 1999</td></tr></tbody></table><p class="title">HTTP Extensions for Distributed Authoring -- WEBDAV</p><h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>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 &#8220;Internet
+Official Protocol Standards&#8221; (STD 1) for the standardization state and
+status of this protocol. Distribution of this memo is unlimited.</p><h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright  The Internet Society (1999). All Rights Reserved.</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> <p>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).</p> <hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li class="tocline0">1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a></li><li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Notational Conventions</a></li><li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Terminology</a></li><li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="">Data Model for Resource Properties</a><ul class="toc"><li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">The Resource Property Model</a></li><li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Existing Metadata Proposals</a></li><li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.3">Properties and HTTP Headers</a></li><li class="tocline1">4.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.4">Property Values</a></li><li class="tocline1">4.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.5">Property Names</a></li><li class="tocline1">4.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.6">Media Independent Links</a></li></ul></li><li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#collections.of.web.resources">Collections of Web Resources</a><ul class="toc"><li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#http.url.namespace.model">HTTP URL Namespace Model</a></li><li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#collection.resources">Collection Resources</a></li><li class="tocline1">5.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">Creation and Retrieval of Collection Resources</a></li><li class="tocline1">5.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.4">Source Resources and Output Resources</a></li></ul></li><li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#locking">Locking</a><ul class="toc"><li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.1">Exclusive Vs. Shared Locks</a></li><li class="tocline1">6.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.2">Required Support</a></li><li class="tocline1">6.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.3">Lock Tokens</a></li><li class="tocline1">6.4&nbsp;&nbsp;&nbsp;<a href="#opaquelocktoken.lock.token.uri.scheme">opaquelocktoken Lock Token URI Scheme</a><ul class="toc"><li class="tocline1">6.4.1&nbsp;&nbsp;&nbsp;<a href="">Node Field Generation Without the IEEE 802 Address</a></li></ul></li><li class="tocline1">6.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.5">Lock Capability Discovery</a></li><li class="tocline1">6.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.6">Active Lock Discovery</a></li><li class="tocline1">6.7&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.7">Usage Considerations</a></li></ul></li><li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Write Lock</a><ul class="toc"><li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">Methods Restricted by Write Locks</a></li><li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">Write Locks and Lock Tokens</a></li><li class="tocline1">7.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.3">Write Locks and Properties</a></li><li class="tocline1">7.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.4">Write Locks and Null Resources</a></li><li class="tocline1">7.5&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.collections">Write Locks and Collections</a></li><li class="tocline1">7.6&nbsp;&nbsp;&nbsp;<a href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a><ul class="toc"><li class="tocline1">7.6.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.6.1">Example - Write Lock</a></li></ul></li><li class="tocline1">7.7&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.7">Write Locks and COPY/MOVE</a></li><li class="tocline1">7.8&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.8">Refreshing Write Locks</a></li></ul></li><li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a><ul class="toc"><li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPFIND">PROPFIND</a><ul class="toc"><li class="tocline1">8.1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.1">Example - Retrieving Named Properties</a></li><li class="tocline1">8.1.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.2">Example - Using allprop to Retrieve All Properties</a></li><li class="tocline1">8.1.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1.3">Example - Using propname to Retrieve all Property Names</a></li></ul></li><li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#METHOD_PROPPATCH">PROPPATCH</a><ul class="toc"><li class="tocline1">8.2.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2.1">Status Codes for use with 207 (Multi-Status)</a></li><li class="tocline1">8.2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2.2">Example - PROPPATCH</a></li></ul></li><li class="tocline1">8.3&nbsp;&nbsp;&nbsp;<a href="#METHOD_MKCOL">MKCOL Method</a><ul class="toc"><li class="tocline1">8.3.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.1">Request</a></li><li class="tocline1">8.3.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.2">Status Codes</a></li><li class="tocline1">8.3.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.3.3">Example - MKCOL</a></li></ul></li><li class="tocline1">8.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.4">GET, HEAD for Collections</a></li><li class="tocline1">8.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.5">POST for Collections</a></li><li class="tocline1">8.6&nbsp;&nbsp;&nbsp;<a href="#METHOD_DELETE">DELETE</a><ul class="toc"><li class="tocline1">8.6.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.6.1">DELETE for Non-Collection Resources</a></li><li class="tocline1">8.6.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.6.2">DELETE for Collections</a><ul class="toc"><li class="tocline1">;&nbsp;&nbsp;<a href="#rfc.section.">Example - DELETE</a></li></ul></li></ul></li><li class="tocline1">8.7&nbsp;&nbsp;&nbsp;<a href="#METHOD_PUT">PUT</a><ul class="toc"><li class="tocline1">8.7.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.7.1">PUT for Non-Collection Resources</a></li><li class="tocline1">8.7.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.7.2">PUT for Collections</a></li></ul></li><li class="tocline1">8.8&nbsp;&nbsp;&nbsp;<a href="#METHOD_COPY">COPY Method</a><ul class="toc"><li class="tocline1">8.8.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.1">COPY for HTTP/1.1 resources</a></li><li class="tocline1">8.8.2&nbsp;&nbsp;&nbsp;<a href="">COPY for Properties</a></li><li class="tocline1">8.8.3&nbsp;&nbsp;&nbsp;<a href="#copy.for.collections">COPY for Collections</a></li><li class="tocline1">8.8.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.4">COPY and the Overwrite Header</a></li><li class="tocline1">8.8.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.5">Status Codes</a></li><li class="tocline1">8.8.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.6">Example - COPY with Overwrite</a></li><li class="tocline1">8.8.7&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.7">Example - COPY with No Overwrite</a></li><li class="tocline1">8.8.8&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.8.8">Example - COPY of a Collection</a></li></ul></li><li class="tocline1">8.9&nbsp;&nbsp;&nbsp;<a href="#METHOD_MOVE">MOVE Method</a><ul class="toc"><li class="tocline1">8.9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.1">MOVE for Properties</a></li><li class="tocline1">8.9.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.2">MOVE for Collections</a></li><li class="tocline1">8.9.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.3">MOVE and the Overwrite Header</a></li><li class="tocline1">8.9.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.4">Status Codes</a></li><li class="tocline1">8.9.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.5">Example - MOVE of a Non-Collection</a></li><li class="tocline1">8.9.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.9.6">Example - MOVE of a Collection</a></li></ul></li><li class="tocline1">8.10&nbsp;&nbsp;&nbsp;<a href="#METHOD_LOCK">LOCK Method</a><ul class="toc"><li class="tocline1">8.10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.1">Operation</a></li><li class="tocline1">8.10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.2">The Effect of Locks on Properties and Collections</a></li><li class="tocline1">8.10.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.3">Locking Replicated Resources</a></li><li class="tocline1">8.10.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.4">Depth and Locking</a></li><li class="tocline1">8.10.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.5">Interaction with other Methods</a></li><li class="tocline1">8.10.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.6">Lock Compatibility Table</a></li><li class="tocline1">8.10.7&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.7">Status Codes</a></li><li class="tocline1">8.10.8&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.8">Example - Simple Lock Request</a></li><li class="tocline1">8.10.9&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.9">Example - Refreshing a Write Lock</a></li><li class="tocline1">8.10.10&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.10.10">Example - Multi-Resource Lock Request</a></li></ul></li><li class="tocline1">8.11&nbsp;&nbsp;&nbsp;<a href="#METHOD_UNLOCK">UNLOCK Method</a><ul class="toc"><li class="tocline1">8.11.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.11.1">Example - UNLOCK</a></li></ul></li></ul></li><li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a><ul class="toc"><li class="tocline1">9.1&nbsp;&nbsp;&nbsp;<a href="#HEADER_DAV">DAV Header</a></li><li class="tocline1">9.2&nbsp;&nbsp;&nbsp;<a href="#HEADER_Depth">Depth Header</a></li><li class="tocline1">9.3&nbsp;&nbsp;&nbsp;<a href="#HEADER_Destination">Destination Header</a></li><li class="tocline1">9.4&nbsp;&nbsp;&nbsp;<a href="#HEADER_If">If Header</a><ul class="toc"><li class="tocline1">9.4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.1">No-tag-list Production</a><ul class="toc"><li class="tocline1">;&nbsp;&nbsp;<a href="#rfc.section.">Example - No-tag-list If Header</a></li></ul></li><li class="tocline1">9.4.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.2">Tagged-list Production</a><ul class="toc"><li class="tocline1">;&nbsp;&nbsp;<a href="#rfc.section.">Example - Tagged List If header</a></li></ul></li><li class="tocline1">9.4.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.3">not Production</a></li><li class="tocline1">9.4.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.4">Matching Function</a></li><li class="tocline1">9.4.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4.5">If Header and Non-DAV Compliant Proxies</a></li></ul></li><li class="tocline1">9.5&nbsp;&nbsp;&nbsp;<a href="#HEADER_Lock-Token">Lock-Token Header</a></li><li class="tocline1">9.6&nbsp;&nbsp;&nbsp;<a href="#HEADER_Overwrite">Overwrite Header</a></li><li class="tocline1">9.7&nbsp;&nbsp;&nbsp;<a href="#HEADER_Status-URI">Status-URI Response Header</a></li><li class="tocline1">9.8&nbsp;&nbsp;&nbsp;<a href="#HEADER_Timeout">Timeout Request Header</a></li></ul></li><li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="">Status Code Extensions to HTTP/1.1</a><ul class="toc"><li class="tocline1">10.1&nbsp;&nbsp;&nbsp;<a href="#STATUS_102">102 Processing</a></li><li class="tocline1">10.2&nbsp;&nbsp;&nbsp;<a href="#STATUS_207">207 Multi-Status</a></li><li class="tocline1">10.3&nbsp;&nbsp;&nbsp;<a href="#STATUS_422">422 Unprocessable Entity</a></li><li class="tocline1">10.4&nbsp;&nbsp;&nbsp;<a href="#STATUS_423">423 Locked</a></li><li class="tocline1">10.5&nbsp;&nbsp;&nbsp;<a href="#STATUS_424">424 Failed Dependency</a></li><li class="tocline1">10.6&nbsp;&nbsp;&nbsp;<a href="#STATUS_507">507 Insufficient Storage</a></li></ul></li><li class="tocline0">11.&nbsp;&nbsp;&nbsp;<a href="#multi-status.response">Multi-Status Response</a></li><li class="tocline0">12.&nbsp;&nbsp;&nbsp;<a href="#xml.element.definitions">XML Element Definitions</a><ul class="toc"><li class="tocline1">12.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_activelock">activelock XML Element</a><ul class="toc"><li class="tocline1">12.1.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_depth">depth XML Element</a></li><li class="tocline1">12.1.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktoken">locktoken XML Element</a></li><li class="tocline1">12.1.3&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_timeout">timeout XML Element</a></li></ul></li><li class="tocline1">12.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_collection">collection XML Element</a></li><li class="tocline1">12.3&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_href">href XML Element</a></li><li class="tocline1">12.4&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_link">link XML Element</a><ul class="toc"><li class="tocline1">12.4.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_dst">dst XML Element</a></li><li class="tocline1">12.4.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_src">src XML Element</a></li></ul></li><li class="tocline1">12.5&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockentry">lockentry XML Element</a></li><li class="tocline1">12.6&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockinfo">lockinfo XML Element</a></li><li class="tocline1">12.7&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_lockscope">lockscope XML Element</a><ul class="toc"><li class="tocline1">12.7.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_exclusive">exclusive XML Element</a></li><li class="tocline1">12.7.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_shared">shared XML Element</a></li></ul></li><li class="tocline1">12.8&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_locktype">locktype XML Element</a><ul class="toc"><li class="tocline1">12.8.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_write">write XML Element</a></li></ul></li><li class="tocline1">12.9&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_multistatus">multistatus XML Element</a><ul class="toc"><li class="tocline1">12.9.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_response">response XML Element</a><ul class="toc"><li class="tocline1">;&nbsp;&nbsp;<a href="#ELEMENT_propstat">propstat XML Element</a></li><li class="tocline1">;&nbsp;&nbsp;<a href="#ELEMENT_status">status XML Element</a></li></ul></li><li class="tocline1">12.9.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_responsedescription">responsedescription XML Element</a></li></ul></li><li class="tocline1">12.10&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_owner">owner XML Element</a></li><li class="tocline1">12.11&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_prop">prop XML element</a></li><li class="tocline1">12.12&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propertybehaviour">propertybehavior XML element</a><ul class="toc"><li class="tocline1">12.12.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_keepalive">keepalive XML element</a></li><li class="tocline1">12.12.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_omit">omit XML element</a></li></ul></li><li class="tocline1">12.13&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propertyupdate">propertyupdate XML element</a><ul class="toc"><li class="tocline1">12.13.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_remove">remove XML element</a></li><li class="tocline1">12.13.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_set">set XML element</a></li></ul></li><li class="tocline1">12.14&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propfind">propfind XML Element</a><ul class="toc"><li class="tocline1">12.14.1&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_allprop">allprop XML Element</a></li><li class="tocline1">12.14.2&nbsp;&nbsp;&nbsp;<a href="#ELEMENT_propname">propname XML Element</a></li></ul></li></ul></li><li class="tocline0">13.&nbsp;&nbsp;&nbsp;<a href="">DAV Properties</a><ul class="toc"><li class="tocline1">13.1&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_creationdate">creationdate Property</a></li><li class="tocline1">13.2&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_displayname">displayname Property</a></li><li class="tocline1">13.3&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></li><li class="tocline1">13.4&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontentlength">getcontentlength Property</a></li><li class="tocline1">13.5&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getcontenttype">getcontenttype Property</a></li><li class="tocline1">13.6&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getetag">getetag Property</a></li><li class="tocline1">13.7&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_getlastmodified">getlastmodified Property</a></li><li class="tocline1">13.8&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a><ul class="toc"><li class="tocline1">13.8.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.8.1">Example - Retrieving the lockdiscovery Property</a></li></ul></li><li class="tocline1">13.9&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_resourcetype">resourcetype Property</a></li><li class="tocline1">13.10&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_source">source Property</a><ul class="toc"><li class="tocline1">13.10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.10.1">Example - A source Property</a></li></ul></li><li class="tocline1">13.11&nbsp;&nbsp;&nbsp;<a href="#PROPERTY_supportedlock">supportedlock Property</a><ul class="toc"><li class="tocline1">13.11.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.13.11.1">Example - Retrieving the supportedlock Property</a></li></ul></li></ul></li><li class="tocline0">14.&nbsp;&nbsp;&nbsp;<a href="">Instructions for Processing XML in DAV</a></li><li class="tocline0">15.&nbsp;&nbsp;&nbsp;<a href="#dav.compliance.classes">DAV Compliance Classes</a><ul class="toc"><li class="tocline1">15.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.1">Class 1</a></li><li class="tocline1">15.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.15.2">Class 2</a></li></ul></li><li class="tocline0">16.&nbsp;&nbsp;&nbsp;<a href="#internationalization.considerations">Internationalization Considerations</a></li><li class="tocline0">17.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc"><li class="tocline1">17.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.1">Authentication of Clients</a></li><li class="tocline1">17.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.2">Denial of Service</a></li><li class="tocline1">17.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.3">Security through Obscurity</a></li><li class="tocline1">17.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.4">Privacy Issues Connected to Locks</a></li><li class="tocline1">17.5&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.5">Privacy Issues Connected to Properties</a></li><li class="tocline1">17.6&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.6">Reduction of Security due to Source Link</a></li><li class="tocline1">17.7&nbsp;&nbsp;&nbsp;<a href="#rfc.section.17.7">Implications of XML External Entities</a></li><li class="tocline1">17.8&nbsp;&nbsp;&nbsp;<a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></li></ul></li><li class="tocline0">18.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.18">IANA Considerations</a></li><li class="tocline0">19.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.19">Intellectual Property</a></li><li class="tocline0">20.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20">Acknowledgements</a></li><li class="tocline0">21.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc"><li class="tocline1">21.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li class="tocline1">21.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informational References</a></li></ul></li><li class="tocline0">22.&nbsp;&nbsp;&nbsp;<a href="#rfc.authors">Authors' Addresses</a></li><li class="tocline0">23.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23">Appendices</a><ul class="toc"><li class="tocline1">23.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.1">Appendix 1 - WebDAV Document Type Definition</a></li><li class="tocline1">23.2&nbsp;&nbsp;&nbsp;<a href="">Appendix 2 - ISO 8601 Date and Time Profile</a></li><li class="tocline1">23.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3">Appendix 3 - Notes on Processing XML Elements</a><ul class="toc"><li class="tocline1">23.3.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3.1">Notes on Empty XML Elements</a></li><li class="tocline1">23.3.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.3.2">Notes on Illegal XML Processing</a><ul class="toc"><li class="tocline1">;&nbsp;&nbsp;<a href="#rfc.section.">Example - XML Syntax Error</a></li><li class="tocline1">;&nbsp;&nbsp;<a href="#rfc.section.">Example - Unknown XML Element</a></li></ul></li></ul></li><li class="tocline1">23.4&nbsp;&nbsp;&nbsp;<a href="#xml.namespaces.for.webdav">Appendix 4 -- XML Namespaces for WebDAV</a><ul class="toc"><li class="tocline1">23.4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.4.1">Introduction</a></li><li class="tocline1">23.4.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.23.4.2">Meaning of Qualified Names</a></li></ul></li></ul></li><li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li><li class="tocline0"><a href="#rfc.index">Index</a></li></ul><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction</h1><p id="rfc.section.1.p.1">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:</p><p id="rfc.section.1.p.2">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.</p><p id="rfc.section.1.p.3">Collections: The ability
+to create sets of documents and to retrieve a hierarchical membership
+listing (like a directory listing in a file system).</p><p id="rfc.section.1.p.4">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.</p><p id="rfc.section.1.p.5">Namespace Operations: The ability to instruct the server to copy and move Web resources.</p><p id="rfc.section.1.p.6">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" <a href="#RFC2291" id="rfc.xref.RFC2291.1"><cite title="Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web">[RFC2291]</cite></a>.</p><p id="rfc.section.1.p.7">The sections below provide a detailed introduction to resource properties (<a href="" title="Data Model for Resource Properties">Section&nbsp;4</a>), collections of resources (<a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a>), and locking operations (<a href="#locking" title="Locking">Section&nbsp;6</a>). These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods described in <a href="#http.methods.for.distributed.authoring" title="HTTP Methods for Distributed Authoring">Section&nbsp;8</a>, "HTTP Methods for Distributed Authoring".</p><p id="rfc.section.1.p.8">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) <a href="#REC-XML" id="rfc.xref.REC-XML.1"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>
+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. <a href="#http.headers.for.distributed.authoring" title="HTTP Headers for Distributed Authoring">Section&nbsp;9</a> describes the new HTTP headers used with WebDAV methods.</p><p id="rfc.section.1.p.9">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.</p><p id="rfc.section.1.p.10">XML elements used in this specification are defined in <a href="#xml.element.definitions" title="XML Element Definitions">Section&nbsp;12</a>.</p><p id="rfc.section.1.p.11">The XML namespace extension (<a href="#xml.namespaces.for.webdav" title="Appendix 4 -- XML Namespaces for WebDAV">Appendix&nbsp;23.4</a>)
+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.</p><p id="rfc.section.1.p.12">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 <a href="" title="Status Code Extensions to HTTP/1.1">Section&nbsp;10</a>.
+Since some WebDAV methods may operate over many resources, the
+Multi-Status response has been introduced to return status information
+for multiple resources. The Multi-Status response is described in <a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;11</a>.</p><p id="rfc.section.1.p.13">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. <a href="" title="DAV Properties">Section&nbsp;13</a> defines the properties used within the WebDAV specification.</p><p id="rfc.section.1.p.14">Finishing off the specification are sections on what it means to be compliant with this specification (<a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;15</a>), on internationalization support (<a href="#internationalization.considerations" title="Internationalization Considerations">Section&nbsp;16</a>), and on security (<a href="#security.considerations" title="Security Considerations">Section&nbsp;17</a>).</p><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;Notational Conventions</h1><p id="rfc.section.2.p.1">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 <a href="" id="rfc.xref.RFC2068.1">2.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. Since this augmented BNF uses the basic production rules provided in section <a href="" id="rfc.xref.RFC2068.3">2.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, these rules apply to this document as well.</p><p id="rfc.section.2.p.2">The
+key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+document are to be interpreted as described in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;Terminology</h1><p id="rfc.section.3.p.1"> <span id="rfc.iref.u.1"></span>  <span id="rfc.iref.u.2"></span>  <dfn>URI</dfn>/<dfn>URL</dfn>
+- A Uniform Resource Identifier and Uniform Resource Locator,
+respectively. These terms (and the distinction between them) are
+defined in <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.</p><p id="rfc.section.3.p.2"> <span id="rfc.iref.c.1"></span>  <dfn>Collection</dfn> - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in <a href="#collections.of.web.resources" title="Collections of Web Resources">Section&nbsp;5</a> of this specification.</p><p id="rfc.section.3.p.3"> <span id="rfc.iref.m.1"></span>  <dfn>Member URI</dfn> - A URI which is a member of the set of URIs contained by a collection.</p><p id="rfc.section.3.p.4"> <span id="rfc.iref.i.1"></span>  <dfn>Internal Member URI</dfn> - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in <a href="#collection.resources" title="Collection Resources">Section&nbsp;5.2</a>).</p><p id="rfc.section.3.p.5"> <span id="rfc.iref.p.1"></span>  <dfn>Property</dfn> - A name/value pair that contains descriptive information about a resource.</p><p id="rfc.section.3.p.6"> <span id="rfc.iref.l.1"></span>  <dfn>Live Property</dfn>
+- 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.</p><p id="rfc.section.3.p.7"> <span id="rfc.iref.d.1"></span>  <dfn>Dead Property</dfn>
+- 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.</p><p id="rfc.section.3.p.8"> <span id="rfc.iref.n.1"></span>  <dfn>Null Resource</dfn>
+- 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 <em class="bcp14">MUST NOT</em> appear as a member of its parent collection.</p><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="" href="">Data Model for Resource Properties</a></h1><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;The Resource Property Model</h2><p id="rfc.section.4.1.p.1">Properties are pieces of data that describe the state of a resource. Properties are data about data.</p><p id="rfc.section.4.1.p.2">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.</p><p id="rfc.section.4.1.p.3">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.</p><p id="rfc.section.4.1.p.4">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 <em class="bcp14">MUST</em>
+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.</p><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;Existing Metadata Proposals</h2><p id="rfc.section.4.2.p.1">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 <a href="#REC-PICS" id="rfc.xref.REC-PICS.1"><cite title="PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1">[REC-PICS]</cite></a>,
+PICS-NG, XML, Web Collections, and several proposals on representing
+relationships within HTML. Work on PICS-NG and Web Collections has been
+subsumed by the Resource Description Framework (RDF) metadata activity
+of the World Wide Web Consortium. RDF consists of a network-based data
+model and an XML representation of that model.</p><p id="rfc.section.4.2.p.2">Some proposals come from a digital library perspective. These include the Dublin Core <a href="#RFC2413" id="rfc.xref.RFC2413.1"><cite title="Dublin Core Metadata for Resource Discovery">[RFC2413]</cite></a> metadata set and the Warwick Framework <a href="#WF" id="rfc.xref.WF.1"><cite title="The Warwick Framework: A Container Architecture for Diverse Sets of Metadata">[WF]</cite></a>, a container architecture for different metadata schemas. The literature includes many examples of metadata, including MARC <a href="#USMARC" id="rfc.xref.USMARC.1"><cite title="USMARC Format for Bibliographic Data">[USMARC]</cite></a>, a bibliographic metadata format, and a technical report bibliographic format employed by the Dienst system <a href="#RFC1807" id="rfc.xref.RFC1807.1"><cite title="A Format for Bibliographic Records">[RFC1807]</cite></a>. Additionally, the proceedings from the first IEEE Metadata conference describe many community-specific metadata sets.</p><p id="rfc.section.4.2.p.3">Participants of the 1996 Metadata II Workshop in Warwick, UK <a href="#WF" id="rfc.xref.WF.2"><cite title="The Warwick Framework: A Container Architecture for Diverse Sets of Metadata">[WF]</cite></a>,
+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.</p><h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;Properties and HTTP Headers</h2><p id="rfc.section.4.3.p.1">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.</p><h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;Property Values</h2><p id="rfc.section.4.4.p.1">The value of a property when expressed in XML <em class="bcp14">MUST</em> be well formed.</p><p id="rfc.section.4.4.p.2">XML
+has been chosen because it is a flexible, self-describing, structured
+data format that supports rich schema definitions, and because of its
+support for multiple character sets. XML's self-describing nature
+allows any property's value to be extended by adding new elements.
+Older clients will not break when they encounter extensions because
+they will still have the data specified in the original schema and will
+ignore elements they do not understand. XML's support for multiple
+character sets allows any human-readable property to be encoded and
+read in a character set familiar to the user. XML's support for
+multiple human languages, using the "xml:lang" attribute, handles cases
+where the same character set is employed by multiple human languages.</p><h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;Property Names</h2><p id="rfc.section.4.5.p.1">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.</p><p id="rfc.section.4.5.p.2">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.</p><p id="rfc.section.4.5.p.3">The XML namespace mechanism, which is based on URIs <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>,
+is used to name properties because it prevents namespace collisions and
+provides for varying degrees of administrative control.</p><p id="rfc.section.4.5.p.4">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.</p><p id="rfc.section.4.5.p.5">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.</p><h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;Media Independent Links</h2><p id="rfc.section.4.6.p.1">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 <a href="#ELEMENT_link" title="link XML Element">Section&nbsp;12.4</a>,
+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.</p><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="collections.of.web.resources" href="#collections.of.web.resources">Collections of Web Resources</a></h1><p id="rfc.section.5.p.1">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.</p><p id="rfc.section.5.p.2">All DAV compliant resources <em class="bcp14">MUST</em> support the HTTP URL namespace model specified herein.</p><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="http.url.namespace.model" href="#http.url.namespace.model">HTTP URL Namespace Model</a></h2><p id="rfc.section.5.1.p.1">The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.</p><p id="rfc.section.5.1.p.2">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.</p><p id="rfc.section.5.1.p.3">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.</p><p id="rfc.section.5.1.p.4">Although implicit in <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, any resource, including collection resources, <em class="bcp14">MAY</em> be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.</p><h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="collection.resources" href="#collection.resources">Collection Resources</a></h2><p id="rfc.section.5.2.p.1">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 <em class="bcp14">MUST</em> 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 <a href="" id="rfc.xref.RFC2396.4">3.3</a> of <a href="#RFC2396" id="rfc.xref.RFC2396.5"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.</p><p id="rfc.section.5.2.p.2">Any given internal member URI <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.5.2.p.3">For all WebDAV compliant resources A and B, identified by URIs U and V, for which U is immediately relative to V, B <em class="bcp14">MUST</em>
+be a collection that has U as an internal member URI. So, if the
+resource with URL is WebDAV compliant and if
+the resource with URL is WebDAV compliant then the
+resource with URL must be a collection and must
+contain URL as an internal member.</p><p id="rfc.section.5.2.p.4">Collection resources <em class="bcp14">MAY</em>
+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 is not
+WebDAV compliant and the URL identifies a
+collection then URL may or may not be an
+internal member of the collection with URL</p><p id="rfc.section.5.2.p.5">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.</p><p id="rfc.section.5.2.p.6">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 <em class="bcp14">SHOULD</em>
+return a content-location header in the response pointing to the URI
+ending with the "/". For example, if a client invokes a method on
+ (no trailing slash), the resource
+ (trailing slash) may respond as if the operation
+were invoked on it, and should return a content-location header with
+ in it. In general clients <em class="bcp14">SHOULD</em> use the "/" form of collection names.</p><p id="rfc.section.5.2.p.7">A resource <em class="bcp14">MAY</em>
+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 <em class="bcp14">MUST NOT</em> return a DAV header containing the value "1" on an OPTIONS response.</p><h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;Creation and Retrieval of Collection Resources</h2><p id="rfc.section.5.3.p.1">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:</p><p id="rfc.section.5.3.p.2">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.</p><p id="rfc.section.5.3.p.3">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.</p><p id="rfc.section.5.3.p.4">The exact definition of the behavior of GET and PUT on collections is defined later in this document.</p><h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;Source Resources and Output Resources</h2><p id="rfc.section.5.4.p.1">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.</p><p id="rfc.section.5.4.p.2">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.</p><p id="rfc.section.5.4.p.3">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
+</p><p id="rfc.section.5.4.p.4">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.</p><p id="rfc.section.5.4.p.5">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 <a href="#PROPERTY_source" title="source Property">Section&nbsp;13.10</a>
+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.</p><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="locking" href="#locking">Locking</a></h1><p id="rfc.section.6.p.1">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.</p><p id="rfc.section.6.p.2">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.</p><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;Exclusive Vs. Shared Locks</h2><p id="rfc.section.6.1.p.1">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.</p><p id="rfc.section.6.1.p.2">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.</p><p id="rfc.section.6.1.p.3">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.</p><p id="rfc.section.6.1.p.4">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.</p><p id="rfc.section.6.1.p.5">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.</p><p id="rfc.section.6.1.p.6">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.</p><h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;Required Support</h2><p id="rfc.section.6.2.p.1">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.</p><p id="rfc.section.6.2.p.2">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.</p><h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;Lock Tokens</h2><p id="rfc.section.6.3.p.1">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.</p><p id="rfc.section.6.3.p.2">Lock token URIs <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.6.3.p.3">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.</p><p id="rfc.section.6.3.p.4">Having
+a lock token provides no special access rights. Anyone can find out
+anyone else's lock token by performing lock discovery. Locks <em class="bcp14">MUST</em> be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.</p><h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="opaquelocktoken.lock.token.uri.scheme" href="#opaquelocktoken.lock.token.uri.scheme">opaquelocktoken Lock Token URI Scheme</a></h2><p id="rfc.section.6.4.p.1">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.</p><p id="rfc.section.6.4.p.2">All resources <em class="bcp14">MUST</em>
+recognize the opaquelocktoken scheme and, at minimum, recognize that
+the lock token does not refer to an outstanding lock on the resource.</p><p id="rfc.section.6.4.p.3">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 <a href="#ISO-11578" id="rfc.xref.ISO-11578.1"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>.</p><p id="rfc.section.6.4.p.4">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 <em class="bcp14">MUST</em> guarantee that the same extension will never be used twice with the associated UUID.</p><p id="rfc.section.6.4.p.5">OpaqueLockToken-URI
+= "opaquelocktoken:" UUID [Extension] ; The UUID production is the
+string representation of a UUID, as defined in <a href="#ISO-11578" id="rfc.xref.ISO-11578.2"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>. Note that white space (LWS) is not allowed between elements of this production.</p><p id="rfc.section.6.4.p.6">Extension = path ; path is defined in section <a href="" id="rfc.xref.RFC2068.6">3.2.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> </p><h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="" href="">Node Field Generation Without the IEEE 802 Address</a></h3><p id="rfc.section.6.4.1.p.1">UUIDs, as defined in <a href="#ISO-11578" id="rfc.xref.ISO-11578.3"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>, contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in <a href="#risks.connected.with.lock.tokens" title="Risks Connected with Lock Tokens">Section&nbsp;17.8</a>,
+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 <em class="bcp14">MAY</em> 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.</p><p id="rfc.section.6.4.1.p.2">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.</p><p id="rfc.section.6.4.1.p.3">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:</p><p id="rfc.section.6.4.1.p.4"> </p><ul><li>the percent of memory in use</li><li>the size of main memory in bytes</li><li>the amount of free main memory in bytes</li><li>the size of the paging or swap file in bytes</li><li>free bytes of paging or swap file</li><li>the total size of user virtual address space in bytes</li><li>the total available user address space bytes</li><li>the size of boot disk drive in bytes</li><li>the free disk space on boot drive in bytes</li><li>the current time</li><li>the amount of time since the system booted</li><li>the individual sizes of files in various system directories</li><li>the creation, last read, and modification times of files in various system directories</li><li>the utilization factors of various system resources (heap, etc.)</li><li>current mouse cursor position</li><li>current caret position</li><li>current number of running processes, threads</li><li>handles or IDs of the desktop window and the active window</li><li>the value of stack pointer of the caller</li><li>the process and thread ID of caller</li><li>various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)</li></ul><p id="rfc.section.6.4.1.p.5">(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.)</p><p id="rfc.section.6.4.1.p.6">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.</p><p id="rfc.section.6.4.1.p.7">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.</p><p id="rfc.section.6.4.1.p.8">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.</p><h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;Lock Capability Discovery</h2><p id="rfc.section.6.5.p.1">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.</p><p id="rfc.section.6.5.p.2">Any DAV compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the supportedlock property.</p><h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;Active Lock Discovery</h2><p id="rfc.section.6.6.p.1">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.</p><p id="rfc.section.6.6.p.2">Any DAV compliant resource that supports the LOCK method <em class="bcp14">MUST</em> support the lockdiscovery property.</p><h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;Usage Considerations</h2><p id="rfc.section.6.7.p.1">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:</p><p id="rfc.section.6.7.p.2">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.</p><p id="rfc.section.6.7.p.3">Client A doesn't lock the document, but does a GET and begins editing.</p><p id="rfc.section.6.7.p.4">Client B does LOCK, performs a GET and begins editing.</p><p id="rfc.section.6.7.p.5">Client B finishes editing, performs a PUT, then an UNLOCK.</p><p id="rfc.section.6.7.p.6">Client A performs a PUT, overwriting and losing all of B's changes.</p><p id="rfc.section.6.7.p.7">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.</p><p id="rfc.section.6.7.p.8">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.</p><p id="rfc.section.6.7.p.9">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.</p><p id="rfc.section.6.7.p.10">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.</p><p id="rfc.section.6.7.p.11">Information
+managers may attempt to prevent overwrites by implementing client-side
+procedures requiring locking before modifying WebDAV resources.</p><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Write Lock</h1><p id="rfc.section.7.p.1">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.</p><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;Methods Restricted by Write Locks</h2><p id="rfc.section.7.1.p.1">A write lock <em class="bcp14">MUST</em>
+prevent a principal without the lock from successfully executing a PUT,
+resource. All other current methods, GET in particular, function
+independently of the lock.</p><p id="rfc.section.7.1.p.2">Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.</p><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;Write Locks and Lock Tokens</h2><p id="rfc.section.7.2.p.1">A successful request for an exclusive or shared write lock <em class="bcp14">MUST</em>
+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.</p><h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;Write Locks and Properties</h2><p id="rfc.section.7.3.p.1">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. Only dead properties
+and live properties defined to respect locks are guaranteed not to
+change while write locked.</p><h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;Write Locks and Null Resources</h2><p id="rfc.section.7.4.p.1">It is possible to assert a write lock on a null resource in order to lock the name.</p><p id="rfc.section.7.4.p.2">A write locked null resource, referred to as a lock-null resource, <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> appear as a member of its parent collection. Additionally the lock-null resource <em class="bcp14">MUST</em>
+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
+<em class="bcp14">MUST</em> have defined values for lockdiscovery and supportedlock properties.</p><p id="rfc.section.7.4.p.3">Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.7.4.p.4">If the resource
+is unlocked, for any reason, without a PUT, MKCOL, or similar method
+having been successfully executed upon it then the resource <em class="bcp14">MUST</em> return to the null state.</p><h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="write.locks.and.collections" href="#write.locks.and.collections">Write Locks and Collections</a></h2><p id="rfc.section.7.5.p.1">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 <em class="bcp14">MUST</em> fail if the principal does not have a write lock on the collection.</p><p id="rfc.section.7.5.p.2">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 <em class="bcp14">MUST</em> fail with a 423 (Locked) status code.</p><p id="rfc.section.7.5.p.3">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 <em class="bcp14">MUST</em>
+be automatically added to the lock. This is the only mechanism that
+allows a resource to be added to a write lock. Thus, for example, if
+the collection /a/b/ is write locked and the resource /c is moved to
+/a/b/c then resource /a/b/c will be added to the write lock.</p><h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="write.locks.and.the.if.request.header" href="#write.locks.and.the.if.request.header">Write Locks and the If Request Header</a></h2><p id="rfc.section.7.6.p.1">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.</p><p id="rfc.section.7.6.p.2">In order to prevent these collisions a lock token <em class="bcp14">MUST</em>
+be submitted by an authorized principal in the If header for all locked
+resources that a method may interact with or the method <em class="bcp14">MUST</em>
+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.</p><h3 id="rfc.section.7.6.1"><a href="#rfc.section.7.6.1">7.6.1</a>&nbsp;Example - Write Lock</h3><div id="rfc.figure.u.1"></div><p>&gt;&gt;Request</p>  <pre class="text2">   COPY /~fielding/index.html HTTP/1.1
+   Host:
+   Destination:
+   If: &lt;;
+       (&lt;opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;)
+</pre><div id="rfc.figure.u.2"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 204 No Content
+</pre><p id="rfc.section.7.6.1.p.3">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.</p><h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;Write Locks and COPY/MOVE</h2><p id="rfc.section.7.7.p.1">A COPY method invocation <em class="bcp14">MUST NOT</em>
+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.</p><p id="rfc.section.7.7.p.2">A successful MOVE request on a write locked resource <em class="bcp14">MUST NOT</em>
+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 <a href="#write.locks.and.collections" title="Write Locks and Collections">Section&nbsp;7.5</a>.
+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 <a href="#write.locks.and.the.if.request.header" title="Write Locks and the If Request Header">Section&nbsp;7.6</a>, an If header must be submitted containing a lock token for both the source and destination.</p><h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;Refreshing Write Locks</h2><p id="rfc.section.7.8.p.1">A client <em class="bcp14">MUST NOT</em>
+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.</p><p id="rfc.section.7.8.p.2">However, a client may submit a LOCK method with an If header but without a body. This form of LOCK <em class="bcp14">MUST</em> only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock <em class="bcp14">MUST</em> be re-set.</p><p id="rfc.section.7.8.p.3">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.</p><p id="rfc.section.7.8.p.4">If an error is received in response to a refresh LOCK request the client <em class="bcp14">SHOULD</em> assume that the lock was not refreshed.</p><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="http.methods.for.distributed.authoring" href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a></h1><p id="rfc.section.8.p.1">The following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources <em class="bcp14">MUST</em> use XML parsers that are compliant with <a href="#REC-XML" id="rfc.xref.REC-XML.2"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>. All XML used in either requests or responses <em class="bcp14">MUST</em> be, at minimum, well formed. If a server receives ill-formed XML in a request it <em class="bcp14">MUST</em> reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it <em class="bcp14">MUST NOT</em> assume anything about the outcome of the executed method and <em class="bcp14">SHOULD</em> treat the server as malfunctioning.</p><div id="rfc.iref.p.2"></div><div id="rfc.iref.m.2"></div><h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="METHOD_PROPFIND" href="#METHOD_PROPFIND">PROPFIND</a></h2><p id="rfc.section.8.1.p.1">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 <em class="bcp14">MUST</em> support the PROPFIND method and the propfind XML element (section <a href="#ELEMENT_propfind" title="propfind XML Element">12.14</a>) along with all XML elements defined for use with that element.</p><p id="rfc.section.8.1.p.2">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 <em class="bcp14">MUST</em> support the "0", "1" and "infinity" behaviors. By default, the PROPFIND method without a Depth header <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was included.</p><p id="rfc.section.8.1.p.3">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 <em class="bcp14">MUST</em> be treated as a request for the names and values of all properties.</p><p id="rfc.section.8.1.p.4">All servers <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.8.1.p.5">If there is an error retrieving a property then a proper error result <em class="bcp14">MUST</em> be included in the response. A request to retrieve the value of a property which does not exist is an error and <em class="bcp14">MUST</em>
+be noted, if the response uses a multistatus XML element, with a
+response XML element which contains a 404 (Not Found) status value.</p><p id="rfc.section.8.1.p.6">Consequently, the multistatus XML element for a collection resource with member URIs <em class="bcp14">MUST</em>
+include a response XML element for each member URI of the collection,
+to whatever depth was requested. Each response XML element <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.8.1.p.7">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.</p><p id="rfc.section.8.1.p.8">The results of this method <em class="bcp14">SHOULD NOT</em> be cached.</p><h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;Example - Retrieving Named Properties</h3><div id="rfc.figure.u.3"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPFIND  /file HTTP/1.1
+   Host:
+   Content-type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"&gt;
+     &lt;D:prop xmlns:R=""&gt;
+          &lt;R:bigbox/&gt;
+          &lt;R:author/&gt;
+          &lt;R:DingALing/&gt;
+          &lt;R:Random/&gt;
+     &lt;/D:prop&gt;
+   &lt;/D:propfind&gt;
+</pre><div id="rfc.figure.u.4"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D="DAV:"&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop xmlns:R=""&gt;
+                    &lt;R:bigbox&gt;
+                         &lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt;
+                    &lt;/R:bigbox&gt;
+                    &lt;R:author&gt;
+                         &lt;R:Name&gt;J.J. Johnson&lt;/R:Name&gt;
+                    &lt;/R:author&gt;
+               &lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;&lt;R:DingALing/&gt;&lt;R:Random/&gt;&lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt;
+               &lt;D:responsedescription&gt; The user does not have access to
+   the DingALing property.
+               &lt;/D:responsedescription&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+     &lt;D:responsedescription&gt; There has been an access violation error.
+     &lt;/D:responsedescription&gt;
+   &lt;/D:multistatus&gt;
+</pre><p id="rfc.section.8.1.1.p.3">In this example, PROPFIND is
+executed on a non-collection resource 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.</p><h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;Example - Using allprop to Retrieve All Properties</h3><div id="rfc.figure.u.5"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPFIND  /container/ HTTP/1.1
+   Host:
+   Depth: 1
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"&gt;
+     &lt;D:allprop/&gt;
+   &lt;/D:propfind&gt;
+</pre><div id="rfc.figure.u.6"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D="DAV:"&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop xmlns:R=""&gt;
+                    &lt;R:bigbox&gt;
+                         &lt;R:BoxType&gt;Box type A&lt;/R:BoxType&gt;
+                    &lt;/R:bigbox&gt;
+                    &lt;R:author&gt;
+                         &lt;R:Name&gt;Hadrian&lt;/R:Name&gt;
+                    &lt;/R:author&gt;
+                    &lt;D:creationdate&gt;
+                         1997-12-01T17:42:21-08:00
+                    &lt;/D:creationdate&gt;
+                    &lt;D:displayname&gt;
+                         Example collection
+                    &lt;/D:displayname&gt;
+                    &lt;D:resourcetype&gt;&lt;D:collection/&gt;&lt;/D:resourcetype&gt;
+                    &lt;D:supportedlock&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                    &lt;/D:supportedlock&gt;
+               &lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop xmlns:R=""&gt;
+                    &lt;R:bigbox&gt;
+                         &lt;R:BoxType&gt;Box type B&lt;/R:BoxType&gt;
+                    &lt;/R:bigbox&gt;
+                    &lt;D:creationdate&gt;
+                         1997-12-01T18:27:21-08:00
+                    &lt;/D:creationdate&gt;
+                    &lt;D:displayname&gt;
+                         Example HTML resource
+                    &lt;/D:displayname&gt;
+                    &lt;D:getcontentlength&gt;
+                         4525
+                    &lt;/D:getcontentlength&gt;
+                    &lt;D:getcontenttype&gt;
+                         text/html
+                    &lt;/D:getcontenttype&gt;
+                    &lt;D:getetag&gt;
+                         zzyzx
+                    &lt;/D:getetag&gt;
+                    &lt;D:getlastmodified&gt;
+                         Monday, 12-Jan-98 09:25:56 GMT
+                    &lt;/D:getlastmodified&gt;
+                    &lt;D:resourcetype/&gt;
+                    &lt;D:supportedlock&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                    &lt;/D:supportedlock&gt;
+               &lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+   &lt;/D:multistatus&gt;
+</pre><p id="rfc.section.8.1.2.p.3">In this example, PROPFIND was
+invoked on the resource 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.</p><p id="rfc.section.8.1.2.p.4">The resource has six properties defined on it:</p><p id="rfc.section.8.1.2.p.5">,
+, DAV:creationdate, DAV:displayname,
+DAV:resourcetype, and DAV:supportedlock.</p><p id="rfc.section.8.1.2.p.6">The last four properties are WebDAV-specific, defined in <a href="" title="DAV Properties">Section&nbsp;13</a>.
+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).</p><p id="rfc.section.8.1.2.p.7">The resource has nine properties defined on it:</p><p id="rfc.section.8.1.2.p.8">
+(another instance of the "bigbox" property type), DAV:creationdate,
+DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.</p><p id="rfc.section.8.1.2.p.9">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).</p><h3 id="rfc.section.8.1.3"><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;Example - Using propname to Retrieve all Property Names</h3><div id="rfc.figure.u.7"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPFIND  /container/ HTTP/1.1
+   Host:
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;propfind xmlns="DAV:"&gt;
+     &lt;propname/&gt;
+   &lt;/propfind&gt;
+</pre><div id="rfc.figure.u.8"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;multistatus xmlns="DAV:"&gt;
+     &lt;response&gt;
+          &lt;href&gt;;/href&gt;
+          &lt;propstat&gt;
+               &lt;prop xmlns:R=""&gt;
+                    &lt;R:bigbox/&gt;
+                    &lt;R:author/&gt;
+                    &lt;creationdate/&gt;
+                    &lt;displayname/&gt;
+                    &lt;resourcetype/&gt;
+                    &lt;supportedlock/&gt;
+               &lt;/prop&gt;
+               &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt;
+          &lt;/propstat&gt;
+     &lt;/response&gt;
+     &lt;response&gt;
+          &lt;href&gt;;/href&gt;
+          &lt;propstat&gt;
+               &lt;prop xmlns:R=""&gt;
+                    &lt;R:bigbox/&gt;
+                    &lt;creationdate/&gt;
+                    &lt;displayname/&gt;
+                    &lt;getcontentlength/&gt;
+                    &lt;getcontenttype/&gt;
+                    &lt;getetag/&gt;
+                    &lt;getlastmodified/&gt;
+                    &lt;resourcetype/&gt;
+                    &lt;supportedlock/&gt;
+               &lt;/prop&gt;
+               &lt;status&gt;HTTP/1.1 200 OK&lt;/status&gt;
+          &lt;/propstat&gt;
+     &lt;/response&gt;
+   &lt;/multistatus&gt;
+</pre><p id="rfc.section.8.1.3.p.3">In this example, PROPFIND is
+invoked on the collection resource, 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.</p><p id="rfc.section.8.1.3.p.4">Consistent with the previous
+example, resource has six properties
+defined on it,,
+, DAV:creationdate, DAV:displayname,
+DAV:resourcetype, and DAV:supportedlock.</p><p id="rfc.section.8.1.3.p.5">The
+resource, a member of the
+"container" collection, has nine properties defined on it,
+, DAV:creationdate, DAV:displayname,
+DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.</p><p id="rfc.section.8.1.3.p.6">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.</p><div id="rfc.iref.p.3"></div><div id="rfc.iref.m.3"></div><h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="METHOD_PROPPATCH" href="#METHOD_PROPPATCH">PROPPATCH</a></h2><p id="rfc.section.8.2.p.1">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.</p><p id="rfc.section.8.2.p.2">All DAV compliant resources <em class="bcp14">MUST</em> support the PROPPATCH method and <em class="bcp14">MUST</em>
+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 <em class="bcp14">SHOULD</em> support the setting of arbitrary dead properties.</p><p id="rfc.section.8.2.p.3">The request message body of a PROPPATCH method <em class="bcp14">MUST</em> contain the propertyupdate XML element. Instruction processing <em class="bcp14">MUST</em> occur in the order instructions are received (i.e., from top to bottom). Instructions <em class="bcp14">MUST</em> either all be executed or none executed. Thus if any error occurs during processing all executed instructions <em class="bcp14">MUST</em>
+be undone and a proper error result returned. Instruction processing
+details can be found in the definition of the set and remove
+instructions in <a href="#ELEMENT_propertyupdate" title="propertyupdate XML element">Section&nbsp;12.13</a>.</p><h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;Status Codes for use with 207 (Multi-Status)</h3><p id="rfc.section.8.2.1.p.1">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.</p><p id="rfc.section.8.2.1.p.2">200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.</p><p id="rfc.section.8.2.1.p.3">403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.</p><p id="rfc.section.8.2.1.p.4">409
+(Conflict) - The client has provided a value whose semantics are not
+appropriate for the property. This includes trying to set read-only
+properties.</p><p id="rfc.section.8.2.1.p.5">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.</p><p id="rfc.section.8.2.1.p.6">507 (Insufficient Storage) - The server did not have sufficient space to record the property.</p><h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;Example - PROPPATCH</h3><div id="rfc.figure.u.9"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPPATCH /bar.html HTTP/1.1
+   Host:
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propertyupdate xmlns:D="DAV:"
+   xmlns:Z=""&gt;
+     &lt;D:set&gt;
+          &lt;D:prop&gt;
+               &lt;Z:authors&gt;
+                    &lt;Z:Author&gt;Jim Whitehead&lt;/Z:Author&gt;
+                    &lt;Z:Author&gt;Roy Fielding&lt;/Z:Author&gt;
+               &lt;/Z:authors&gt;
+          &lt;/D:prop&gt;
+     &lt;/D:set&gt;
+     &lt;D:remove&gt;
+          &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt;
+     &lt;/D:remove&gt;
+   &lt;/D:propertyupdate&gt;
+</pre><div id="rfc.figure.u.10"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D="DAV:"
+   xmlns:Z=""&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;&lt;Z:Authors/&gt;&lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;&lt;Z:Copyright-Owner/&gt;&lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 409 Conflict&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+          &lt;D:responsedescription&gt; Copyright Owner can not be deleted or
+   altered.&lt;/D:responsedescription&gt;
+     &lt;/D:response&gt;
+   &lt;/D:multistatus&gt;
+</pre><p id="rfc.section.8.2.2.p.3">In this example, the client
+requests the server to set the value of the
+ property, and to remove the
+property 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.</p><div id="rfc.iref.m.4"></div><div id="rfc.iref.m.5"></div><h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="METHOD_MKCOL" href="#METHOD_MKCOL">MKCOL Method</a></h2><p id="rfc.section.8.3.p.1">The MKCOL method is used to create a new collection. All DAV compliant resources <em class="bcp14">MUST</em> support the MKCOL method.</p><h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;Request</h3><p id="rfc.section.8.3.1.p.1">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 <em class="bcp14">MUST</em> fail. During MKCOL processing, a server <em class="bcp14">MUST</em> make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method <em class="bcp14">MUST</em> fail. When the MKCOL operation creates a new collection resource, all ancestors <em class="bcp14">MUST</em> already exist, or the method <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.8.3.1.p.2">When MKCOL is invoked without a request body, the newly created collection <em class="bcp14">SHOULD</em> have no members.</p><p id="rfc.section.8.3.1.p.3">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 <em class="bcp14">MUST</em>
+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.</p><h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;Status Codes</h3><p id="rfc.section.8.3.2.p.1">Responses from a MKCOL request <em class="bcp14">MUST NOT</em> be cached as MKCOL has non-idempotent semantics.</p><p id="rfc.section.8.3.2.p.2">201 (Created) - The collection or structured resource was created in its entirety.</p><p id="rfc.section.8.3.2.p.3">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.</p><p id="rfc.section.8.3.2.p.4">405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.</p><p id="rfc.section.8.3.2.p.5">409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.</p><p id="rfc.section.8.3.2.p.6">415 (Unsupported Media Type)- The server does not support the request type of the body.</p><p id="rfc.section.8.3.2.p.7">507
+(Insufficient Storage) - The resource does not have sufficient space to
+record the state of the resource after the execution of this method.</p><h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;Example - MKCOL</h3><p id="rfc.section.8.3.3.p.1">This example creates a collection called /webdisc/xfiles/ on the server</p><div id="rfc.figure.u.11"></div><p>&gt;&gt;Request</p>  <pre class="text2">   MKCOL /webdisc/xfiles/ HTTP/1.1
+   Host:
+</pre><div id="rfc.figure.u.12"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 201 Created
+</pre><h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;GET, HEAD for Collections</h2><p id="rfc.section.8.4.p.1">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" <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+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.</p><p id="rfc.section.8.4.p.2">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.</p><h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;POST for Collections</h2><p id="rfc.section.8.5.p.1">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.</p><div id="rfc.iref.d.2"></div><div id="rfc.iref.m.6"></div><h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="METHOD_DELETE" href="#METHOD_DELETE">DELETE</a></h2><h3 id="rfc.section.8.6.1"><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;DELETE for Non-Collection Resources</h3><p id="rfc.section.8.6.1.p.1">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 <em class="bcp14">MUST</em> remove any URI for the resource identified by the Request-URI from collections which contain it as a member.</p><h3 id="rfc.section.8.6.2"><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;DELETE for Collections</h3><p id="rfc.section.8.6.2.p.1">The DELETE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header with a DELETE on a collection with any value but infinity.</p><p id="rfc.section.8.6.2.p.2">DELETE
+instructs that the collection specified in the Request-URI and all
+resources identified by its internal member URIs are to be deleted.</p><p id="rfc.section.8.6.2.p.3">If any resource identified by a member URI cannot be deleted then all of the member's ancestors <em class="bcp14">MUST NOT</em> be deleted, so as to maintain namespace consistency.</p><p id="rfc.section.8.6.2.p.4">Any headers included with DELETE <em class="bcp14">MUST</em> be applied in processing every resource to be deleted.</p><p id="rfc.section.8.6.2.p.5">When the DELETE method has completed processing it <em class="bcp14">MUST</em> result in a consistent namespace.</p><p id="rfc.section.8.6.2.p.6">If an error occurs with a resource other than the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status). 424 (Failed Dependency) errors <em class="bcp14">SHOULD NOT</em>
+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 <em class="bcp14">SHOULD NOT</em> be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.</p><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;Example - DELETE</h4><div id="rfc.figure.u.13"></div><p>&gt;&gt;Request</p>  <pre class="text2">   DELETE  /container/ HTTP/1.1
+   Host:
+</pre><div id="rfc.figure.u.14"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;d:multistatus xmlns:d="DAV:"&gt;
+     &lt;d:response&gt;
+          &lt;d:href&gt;;/d:href&gt;
+          &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt;
+     &lt;/d:response&gt;
+   &lt;/d:multistatus&gt;
+</pre><p id="rfc.section.">In this example the attempt to
+delete failed because it is
+locked, and no lock token was submitted with the request. Consequently,
+the attempt to delete also failed. Thus
+the client knows that the attempt to delete
+ 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.</p><div id="rfc.iref.p.4"></div><div id="rfc.iref.m.7"></div><h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="METHOD_PUT" href="#METHOD_PUT">PUT</a></h2><h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a>&nbsp;PUT for Non-Collection Resources</h3><p id="rfc.section.8.7.1.p.1">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.</p><p id="rfc.section.8.7.1.p.2">A PUT that would result in the creation of a resource without an appropriately scoped parent collection <em class="bcp14">MUST</em> fail with a 409 (Conflict).</p><h3 id="rfc.section.8.7.2"><a href="#rfc.section.8.7.2">8.7.2</a>&nbsp;PUT for Collections</h3><p id="rfc.section.8.7.2.p.1">As defined in the HTTP/1.1 specification <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>,
+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.</p><p id="rfc.section.8.7.2.p.2">When the PUT operation creates a new non-collection resource all ancestors <em class="bcp14">MUST</em> already exist. If all ancestors do not exist, the method <em class="bcp14">MUST</em>
+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.</p><div id="rfc.iref.c.2"></div><div id="rfc.iref.m.8"></div><h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="METHOD_COPY" href="#METHOD_COPY">COPY Method</a></h2><p id="rfc.section.8.8.p.1">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 <em class="bcp14">MUST</em> be present. The exact behavior of the COPY method depends on the type of the source resource.</p><p id="rfc.section.8.8.p.2">All WebDAV compliant resources <em class="bcp14">MUST</em>
+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.</p><h3 id="rfc.section.8.8.1"><a href="#rfc.section.8.8.1">8.8.1</a>&nbsp;COPY for HTTP/1.1 resources</h3><p id="rfc.section.8.8.1.p.1">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 <em class="bcp14">MUST</em> 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.</p><h3 id="rfc.section.8.8.2"><a href="#rfc.section.8.8.2">8.8.2</a>&nbsp;<a id="" href="">COPY for Properties</a></h3><p id="rfc.section.8.8.2.p.1">The following section defines how properties on a resource are handled during a COPY operation.</p><p id="rfc.section.8.8.2.p.2">Live properties <em class="bcp14">SHOULD</em>
+be duplicated as identically behaving live properties at the
+destination resource. If a property cannot be copied live, then its
+value <em class="bcp14">MUST</em> be duplicated, octet-for-octet, in
+an identically named, dead property on the destination resource subject
+to the effects of the propertybehavior XML element.</p><p id="rfc.section.8.8.2.p.3">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 <a href="#ELEMENT_propertybehaviour" title="propertybehavior XML element">Section&nbsp;12.12</a>.</p><h3 id="rfc.section.8.8.3"><a href="#rfc.section.8.8.3">8.8.3</a>&nbsp;<a id="copy.for.collections" href="#copy.for.collections">COPY for Collections</a></h3><p id="rfc.section.8.8.3.p.1">The COPY method on a collection without a Depth header <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> support the "0" and "infinity" Depth header behaviors.</p><p id="rfc.section.8.8.3.p.2">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.</p><p id="rfc.section.8.8.3.p.3">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.</p><p id="rfc.section.8.8.3.p.4">Any headers included with a COPY <em class="bcp14">MUST</em> be applied in processing every resource to be copied with the exception of the Destination header.</p><p id="rfc.section.8.8.3.p.5">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 and the Destination is
+ then when is processed it must
+use a Destination of</p><p id="rfc.section.8.8.3.p.6">When the COPY method has completed processing it <em class="bcp14">MUST</em> have created a consistent namespace at the destination (see <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">Section&nbsp;5.1</a> for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server <em class="bcp14">MUST NOT</em>
+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 <em class="bcp14">SHOULD</em>
+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 <em class="bcp14">SHOULD</em> try to finish as much of the original copy operation as possible.</p><p id="rfc.section.8.8.3.p.7">If
+an error in executing the COPY method occurs with a resource other than
+the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status).</p><p id="rfc.section.8.8.3.p.8">The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
+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 <em class="bcp14">SHOULD NOT</em> 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.</p><h3 id="rfc.section.8.8.4"><a href="#rfc.section.8.8.4">8.8.4</a>&nbsp;COPY and the Overwrite Header</h3><p id="rfc.section.8.8.4.p.1">If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server <em class="bcp14">MUST</em>
+perform a DELETE with "Depth: infinity" on the destination resource. If
+the Overwrite header is set to "F" then the operation will fail.</p><h3 id="rfc.section.8.8.5"><a href="#rfc.section.8.8.5">8.8.5</a>&nbsp;Status Codes</h3><p id="rfc.section.8.8.5.p.1">201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource.</p><p id="rfc.section.8.8.5.p.2">204 (No Content) - The source resource was successfully copied to a pre-existing destination resource.</p><p id="rfc.section.8.8.5.p.3">403 (Forbidden) - The source and destination URIs are the same.</p><p id="rfc.section.8.8.5.p.4">409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created.</p><p id="rfc.section.8.8.5.p.5">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.</p><p id="rfc.section.8.8.5.p.6">423 (Locked) - The destination resource was locked.</p><p id="rfc.section.8.8.5.p.7">502
+(Bad Gateway) - This may occur when the destination is on another
+server and the destination server refuses to accept the resource.</p><p id="rfc.section.8.8.5.p.8">507
+(Insufficient Storage) - The destination resource does not have
+sufficient space to record the state of the resource after the
+execution of this method.</p><h3 id="rfc.section.8.8.6"><a href="#rfc.section.8.8.6">8.8.6</a>&nbsp;Example - COPY with Overwrite</h3><p id="rfc.section.8.8.6.p.1">This
+example shows resource
+being copied to the location
+ The 204 (No
+Content) status code indicates the existing resource at the destination
+was overwritten.</p><div id="rfc.figure.u.15"></div><p>&gt;&gt;Request</p>  <pre class="text2">   COPY /~fielding/index.html HTTP/1.1
+   Host:
+   Destination:
+</pre><div id="rfc.figure.u.16"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 204 No Content
+</pre><h3 id="rfc.section.8.8.7"><a href="#rfc.section.8.8.7">8.8.7</a>&nbsp;Example - COPY with No Overwrite</h3><p id="rfc.section.8.8.7.p.1">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.</p><div id="rfc.figure.u.17"></div><p>&gt;&gt;Request</p>  <pre class="text2">   COPY /~fielding/index.html HTTP/1.1
+   Host:
+   Destination:
+   Overwrite: F
+</pre><div id="rfc.figure.u.18"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 412 Precondition Failed
+</pre><h3 id="rfc.section.8.8.8"><a href="#rfc.section.8.8.8">8.8.8</a>&nbsp;Example - COPY of a Collection</h3><div id="rfc.figure.u.19"></div><p>&gt;&gt;Request</p>  <pre class="text2">   COPY /container/ HTTP/1.1
+   Host:
+   Destination:
+   Depth: infinity
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;d:propertybehavior xmlns:d="DAV:"&gt;
+     &lt;d:keepalive&gt;*&lt;/d:keepalive&gt;
+   &lt;/d:propertybehavior&gt;
+</pre><div id="rfc.figure.u.20"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;d:multistatus xmlns:d="DAV:"&gt;
+      &lt;d:response&gt;
+          &lt;d:href&gt;;/d:href&gt;
+          &lt;d:status&gt;HTTP/1.1 412 Precondition Failed&lt;/d:status&gt;
+      &lt;/d:response&gt;
+   &lt;/d:multistatus&gt;
+</pre><p id="rfc.section.8.8.8.p.3">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 <a href="#copy.for.collections" title="COPY for Collections">Section&nbsp;8.8.3</a>.</p><div id="rfc.iref.m.9"></div><div id="rfc.iref.m.10"></div><h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="METHOD_MOVE" href="#METHOD_MOVE">MOVE Method</a></h2><p id="rfc.section.8.9.p.1">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 <em class="bcp14">MUST</em> be present on all MOVE methods and <em class="bcp14">MUST</em> follow all COPY requirements for the COPY part of the MOVE method. All DAV compliant resources <em class="bcp14">MUST</em>
+support the MOVE method. However, support for the MOVE method does not
+guarantee the ability to move a resource to a particular destination.</p><p id="rfc.section.8.9.p.2">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.</p><p id="rfc.section.8.9.p.3">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.</p><h3 id="rfc.section.8.9.1"><a href="#rfc.section.8.9.1">8.9.1</a>&nbsp;MOVE for Properties</h3><p id="rfc.section.8.9.1.p.1">The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, <em class="bcp14">MUST</em> be the same as specified in <a href="" title="COPY for Properties">Section&nbsp;8.8.2</a>.</p><h3 id="rfc.section.8.9.2"><a href="#rfc.section.8.9.2">8.9.2</a>&nbsp;MOVE for Collections</h3><p id="rfc.section.8.9.2.p.1">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.</p><p id="rfc.section.8.9.2.p.2">The MOVE method on a collection <em class="bcp14">MUST</em> act as if a "Depth: infinity" header was used on it. A client <em class="bcp14">MUST NOT</em> submit a Depth header on a MOVE on a collection with any value but "infinity".</p><p id="rfc.section.8.9.2.p.3">Any headers included with MOVE <em class="bcp14">MUST</em> be applied in processing every resource to be moved with the exception of the Destination header.</p><p id="rfc.section.8.9.2.p.4">The behavior of the Destination header is the same as given for COPY on collections.</p><p id="rfc.section.8.9.2.p.5">When the MOVE method has completed processing it <em class="bcp14">MUST</em> have created a consistent namespace at both the source and destination (see section <a href="#http.url.namespace.model" title="HTTP URL Namespace Model">5.1</a> for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server <em class="bcp14">MUST NOT</em>
+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 <em class="bcp14">SHOULD</em> 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 <em class="bcp14">SHOULD</em> try to finish as much of the original move operation as possible.</p><p id="rfc.section.8.9.2.p.6">If an error occurs with a resource other than the resource identified in the Request-URI then the response <em class="bcp14">MUST</em> be a 207 (Multi-Status).</p><p id="rfc.section.8.9.2.p.7">The 424 (Failed Dependency) status code <em class="bcp14">SHOULD NOT</em>
+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 <em class="bcp14">SHOULD</em> 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.</p><h3 id="rfc.section.8.9.3"><a href="#rfc.section.8.9.3">8.9.3</a>&nbsp;MOVE and the Overwrite Header</h3><p id="rfc.section.8.9.3.p.1">If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server <em class="bcp14">MUST</em>
+perform a DELETE with "Depth: infinity" on the destination resource. If
+the Overwrite header is set to "F" then the operation will fail.</p><h3 id="rfc.section.8.9.4"><a href="#rfc.section.8.9.4">8.9.4</a>&nbsp;Status Codes</h3><p id="rfc.section.8.9.4.p.1">201 (Created) - The source resource was successfully moved, and a new resource was created at the destination.</p><p id="rfc.section.8.9.4.p.2">204 (No Content) - The source resource was successfully moved to a pre-existing destination resource.</p><p id="rfc.section.8.9.4.p.3">403 (Forbidden) - The source and destination URIs are the same.</p><p id="rfc.section.8.9.4.p.4">409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created.</p><p id="rfc.section.8.9.4.p.5">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.</p><p id="rfc.section.8.9.4.p.6">423 (Locked) - The source or the destination resource was locked.</p><p id="rfc.section.8.9.4.p.7">502
+(Bad Gateway) - This may occur when the destination is on another
+server and the destination server refuses to accept the resource.</p><h3 id="rfc.section.8.9.5"><a href="#rfc.section.8.9.5">8.9.5</a>&nbsp;Example - MOVE of a Non-Collection</h3><p id="rfc.section.8.9.5.p.1">This
+example shows resource
+being moved to the location
+ 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).</p><div id="rfc.figure.u.21"></div><p>&gt;&gt;Request</p>  <pre class="text2">   MOVE /~fielding/index.html HTTP/1.1
+   Host:
+   Destination:
+</pre><div id="rfc.figure.u.22"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 201 Created
+   Location:
+</pre><h3 id="rfc.section.8.9.6"><a href="#rfc.section.8.9.6">8.9.6</a>&nbsp;Example - MOVE of a Collection</h3><div id="rfc.figure.u.23"></div><p>&gt;&gt;Request</p>  <pre class="text2">   MOVE /container/ HTTP/1.1
+   Host:
+   Destination:
+   Overwrite: F
+   If: (&lt;opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4&gt;)
+       (&lt;opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77&gt;)
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;d:propertybehavior xmlns:d='DAV:'&gt;
+     &lt;d:keepalive&gt;*&lt;/d:keepalive&gt;
+   &lt;/d:propertybehavior&gt;
+</pre><div id="rfc.figure.u.24"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;d:multistatus xmlns:d='DAV:'&gt;
+     &lt;d:response&gt;
+          &lt;d:href&gt;;/d:href&gt;
+          &lt;d:status&gt;HTTP/1.1 423 Locked&lt;/d:status&gt;
+     &lt;/d:response&gt;
+   &lt;/d:multistatus&gt;
+</pre><p id="rfc.section.8.9.6.p.3">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
+ 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 <a href="#copy.for.collections" title="COPY for Collections">Section&nbsp;8.8.3</a>.
+User agent authentication has previously occurred via a mechanism
+outside the scope of the HTTP protocol, in an underlying transport
+layer.</p><div id="rfc.iref.l.2"></div><div id="rfc.iref.m.11"></div><h2 id="rfc.section.8.10"><a href="#rfc.section.8.10">8.10</a>&nbsp;<a id="METHOD_LOCK" href="#METHOD_LOCK">LOCK Method</a></h2><p id="rfc.section.8.10.p.1">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.</p><p id="rfc.section.8.10.p.2">Any resource which supports the LOCK method <em class="bcp14">MUST</em>, at minimum, support the XML request and response formats defined herein.</p><h3 id="rfc.section.8.10.1"><a href="#rfc.section.8.10.1">8.10.1</a>&nbsp;Operation</h3><p id="rfc.section.8.10.1.p.1">A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests <em class="bcp14">SHOULD</em>
+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.</p><p id="rfc.section.8.10.1.p.2">Clients <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> contain the value of the lockdiscovery property in a prop XML element.</p><p id="rfc.section.8.10.1.p.3">In order to indicate the lock token associated with a newly created lock, a Lock-Token response header <em class="bcp14">MUST</em>
+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.</p><h3 id="rfc.section.8.10.2"><a href="#rfc.section.8.10.2">8.10.2</a>&nbsp;The Effect of Locks on Properties and Collections</h3><p id="rfc.section.8.10.2.p.1">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 <em class="bcp14">MUST</em> also lock the resource's properties.</p><p id="rfc.section.8.10.2.p.2">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.</p><h3 id="rfc.section.8.10.3"><a href="#rfc.section.8.10.3">8.10.3</a>&nbsp;Locking Replicated Resources</h3><p id="rfc.section.8.10.3.p.1">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 <em class="bcp14">MUST NOT</em> succeed if can not be honored by all the URIs through which the resource is addressable.</p><h3 id="rfc.section.8.10.4"><a href="#rfc.section.8.10.4">8.10.4</a>&nbsp;Depth and Locking</h3><p id="rfc.section.8.10.4.p.1">The Depth header may be used with the LOCK method. Values other than 0 or infinity <em class="bcp14">MUST NOT</em> be used with the Depth header on a LOCK method. All resources that support the LOCK method <em class="bcp14">MUST</em> support the Depth header.</p><p id="rfc.section.8.10.4.p.2">A Depth header of value 0 means to just lock the resource specified by the Request-URI.</p><p id="rfc.section.8.10.4.p.3">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 <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> 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.</p><p id="rfc.section.8.10.4.p.4">If no Depth header is submitted on a LOCK request then the request <em class="bcp14">MUST</em> act as if a "Depth:infinity" had been submitted.</p><h3 id="rfc.section.8.10.5"><a href="#rfc.section.8.10.5">8.10.5</a>&nbsp;Interaction with other Methods</h3><p id="rfc.section.8.10.5.p.1">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 <em class="bcp14">MUST</em> cause all of its locks to be removed.</p><h3 id="rfc.section.8.10.6"><a href="#rfc.section.8.10.6">8.10.6</a>&nbsp;Lock Compatibility Table</h3><div id="rfc.table.u.1"><p>The table below describes the behavior that occurs when a lock request is made on a resource.</p><table summary="   The table below describes the behavior that occurs when a lock
+   request is made on a resource." class="tt full" cellpadding="3" cellspacing="0"><thead><tr><th style="width: 40%;">Current lock state / Lock request</th><th>Shared Lock</th><th>Exclusive Lock</th></tr></thead><tbody><tr><td>None</td><td>True</td><td>True</td></tr><tr><td>Shared Lock</td><td>True</td><td>False</td></tr><tr><td>Exclusive Lock</td><td>False</td><td>False*</td></tr></tbody></table><p>Legend: True = lock may be granted. False = lock <em class="bcp14">MUST NOT</em> be granted. *=It is illegal for a principal to request the same lock twice.</p></div><p id="rfc.section.8.10.6.p.1">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.</p><h3 id="rfc.section.8.10.7"><a href="#rfc.section.8.10.7">8.10.7</a>&nbsp;Status Codes</h3><p id="rfc.section.8.10.7.p.1">200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.</p><p id="rfc.section.8.10.7.p.2">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.</p><p id="rfc.section.8.10.7.p.3">423 (Locked) - The resource is locked, so the method has been rejected.</p><h3 id="rfc.section.8.10.8"><a href="#rfc.section.8.10.8">8.10.8</a>&nbsp;Example - Simple Lock Request</h3><div id="rfc.figure.u.25"></div><p>&gt;&gt;Request</p>  <pre class="text2">   LOCK /workspace/webdav/proposal.doc HTTP/1.1
+   Host:
+   Timeout: Infinite, Second-4100000000
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   Authorization: Digest username="ejw",
+      realm="", nonce="...",
+      uri="/workspace/webdav/proposal.doc",
+      response="...", opaque="..."
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:lockinfo xmlns:D='DAV:'&gt;
+     &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+     &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+     &lt;D:owner&gt;
+          &lt;D:href&gt;;/D:href&gt;
+     &lt;/D:owner&gt;
+   &lt;/D:lockinfo&gt;
+</pre><div id="rfc.figure.u.26"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 200 OK
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:prop xmlns:D="DAV:"&gt;
+     &lt;D:lockdiscovery&gt;
+          &lt;D:activelock&gt;
+               &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+               &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+               &lt;D:depth&gt;Infinity&lt;/D:depth&gt;
+               &lt;D:owner&gt;
+                    &lt;D:href&gt;
+                    &lt;/D:href&gt;
+               &lt;/D:owner&gt;
+               &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt;
+               &lt;D:locktoken&gt;
+                    &lt;D:href&gt;
+               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+                    &lt;/D:href&gt;
+               &lt;/D:locktoken&gt;
+          &lt;/D:activelock&gt;
+     &lt;/D:lockdiscovery&gt;
+   &lt;/D:prop&gt;
+</pre><p id="rfc.section.8.10.8.p.3">This example shows the successful
+creation of an exclusive write lock on resource
+ The resource
+ 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.</p><h3 id="rfc.section.8.10.9"><a href="#rfc.section.8.10.9">8.10.9</a>&nbsp;Example - Refreshing a Write Lock</h3><div id="rfc.figure.u.27"></div><p>&gt;&gt;Request</p>  <pre class="text2">   LOCK /workspace/webdav/proposal.doc HTTP/1.1
+   Host:
+   Timeout: Infinite, Second-4100000000
+   If: (&lt;opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4&gt;)
+   Authorization: Digest username="ejw",
+      realm="", nonce="...",
+      uri="/workspace/webdav/proposal.doc",
+      response="...", opaque="..."
+</pre><div id="rfc.figure.u.28"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 200 OK
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:prop xmlns:D="DAV:"&gt;
+     &lt;D:lockdiscovery&gt;
+          &lt;D:activelock&gt;
+               &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+               &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+               &lt;D:depth&gt;Infinity&lt;/D:depth&gt;
+               &lt;D:owner&gt;
+                    &lt;D:href&gt;
+                    &lt;/D:href&gt;
+               &lt;/D:owner&gt;
+               &lt;D:timeout&gt;Second-604800&lt;/D:timeout&gt;
+               &lt;D:locktoken&gt;
+                    &lt;D:href&gt;
+               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+                    &lt;/D:href&gt;
+               &lt;/D:locktoken&gt;
+          &lt;/D:activelock&gt;
+     &lt;/D:lockdiscovery&gt;
+   &lt;/D:prop&gt;
+</pre><p id="rfc.section.8.10.9.p.3">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.</p><h3 id="rfc.section.8.10.10"><a href="#rfc.section.8.10.10">8.10.10</a>&nbsp;Example - Multi-Resource Lock Request</h3><div id="rfc.figure.u.29"></div><p>&gt;&gt;Request</p>  <pre class="text2">   LOCK /webdav/ HTTP/1.1
+   Host:
+   Timeout: Infinite, Second-4100000000
+   Depth: infinity
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   Authorization: Digest username="ejw",
+      realm="", nonce="...",
+      uri="/workspace/webdav/proposal.doc",
+      response="...", opaque="..."
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:lockinfo xmlns:D="DAV:"&gt;
+     &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+     &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+     &lt;D:owner&gt;
+          &lt;D:href&gt;;/D:href&gt;
+     &lt;/D:owner&gt;
+   &lt;/D:lockinfo&gt;
+</pre><div id="rfc.figure.u.30"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D="DAV:"&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:status&gt;HTTP/1.1 403 Forbidden&lt;/D:status&gt;
+     &lt;/D:response&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 424 Failed Dependency&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+   &lt;/D:multistatus&gt;
+</pre><p id="rfc.section.8.10.10.p.3">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.</p><p id="rfc.section.8.10.10.p.4">The
+error is a 403 (Forbidden) response on the resource
+ 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.</p><p id="rfc.section.8.10.10.p.5">In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.</p><div id="rfc.iref.u.3"></div><div id="rfc.iref.m.12"></div><h2 id="rfc.section.8.11"><a href="#rfc.section.8.11">8.11</a>&nbsp;<a id="METHOD_UNLOCK" href="#METHOD_UNLOCK">UNLOCK Method</a></h2><p id="rfc.section.8.11.p.1">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 <em class="bcp14">MUST</em> fail.</p><p id="rfc.section.8.11.p.2">Any DAV compliant resource which supports the LOCK method <em class="bcp14">MUST</em> support the UNLOCK method.</p><h3 id="rfc.section.8.11.1"><a href="#rfc.section.8.11.1">8.11.1</a>&nbsp;Example - UNLOCK</h3><div id="rfc.figure.u.31"></div><p>&gt;&gt;Request</p>  <pre class="text2">   UNLOCK /workspace/webdav/info.doc HTTP/1.1
+   Host:
+   Lock-Token: &lt;opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7&gt;
+   Authorization: Digest username="ejw",
+      realm="", nonce="...",
+      uri="/workspace/webdav/proposal.doc",
+      response="...", opaque="..."
+</pre><div id="rfc.figure.u.32"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 204 No Content
+</pre><p id="rfc.section.8.11.1.p.3">In this example, the lock
+identified by the lock token
+"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully
+removed from the resource
+ 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.</p><p id="rfc.section.8.11.1.p.4">In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.</p><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="http.headers.for.distributed.authoring" href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a></h1><div id="rfc.iref.d.3"></div><div id="rfc.iref.h.1"></div><h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="HEADER_DAV" href="#HEADER_DAV">DAV Header</a></h2><div id="rfc.figure.u.33"></div><pre class="inline">   DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
+</pre><p id="rfc.section.9.1.p.2">This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources <em class="bcp14">MUST</em> return the DAV header on all OPTIONS responses.</p><p id="rfc.section.9.1.p.3">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 <a href="#dav.compliance.classes" title="DAV Compliance Classes">Section&nbsp;15</a> for more details. In general, however, support for one compliance class does not entail support for any other.</p><div id="rfc.iref.d.4"></div><div id="rfc.iref.h.2"></div><h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="HEADER_Depth" href="#HEADER_Depth">Depth Header</a></h2><div id="rfc.figure.u.34"></div><pre class="inline">   Depth = "Depth" ":" ("0" | "1" | "infinity")
+</pre><p id="rfc.section.9.2.p.2">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").</p><p id="rfc.section.9.2.p.3">The Depth header is only supported if a method's definition explicitly provides for such support.</p><p id="rfc.section.9.2.p.4">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.</p><p id="rfc.section.9.2.p.5">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.</p><p id="rfc.section.9.2.p.6">Clients <em class="bcp14">MUST NOT</em>
+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.</p><p id="rfc.section.9.2.p.7">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.</p><p id="rfc.section.9.2.p.8">So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.</p><p id="rfc.section.9.2.p.9">Any headers on a method that has a defined interaction with the Depth header <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.9.2.p.10">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 <em class="bcp14">MUST</em> be submitted with the request in the If request header.</p><p id="rfc.section.9.2.p.11">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 <em class="bcp14">MUST</em> be ignored.</p><p id="rfc.section.9.2.p.12">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.</p><div id="rfc.iref.d.5"></div><div id="rfc.iref.h.3"></div><h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="HEADER_Destination" href="#HEADER_Destination">Destination Header</a></h2><div id="rfc.figure.u.35"></div><pre class="inline">   Destination = "Destination" ":" absoluteURI
+</pre><p id="rfc.section.9.3.p.2">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 <a href="#RFC2396" id="rfc.xref.RFC2396.6"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.</p><div id="rfc.iref.i.2"></div><div id="rfc.iref.h.4"></div><h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="HEADER_If" href="#HEADER_If">If Header</a></h2><div id="rfc.figure.u.36"></div><pre class="inline">   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 = "&lt;" absoluteURI "&gt;"
+</pre><p id="rfc.section.9.4.p.2">The If header is intended to have similar functionality to the If-Match header defined in section <a href="" id="rfc.xref.RFC2068.10">14.25</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+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.</p><p id="rfc.section.9.4.p.3">All DAV compliant resources <em class="bcp14">MUST</em> honor the If header.</p><p id="rfc.section.9.4.p.4">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 <em class="bcp14">MUST</em>
+fail with a 412 (Precondition Failed). If one of the described state
+lists matches the state of the resource then the request may succeed.</p><p id="rfc.section.9.4.p.5">Note that the absoluteURI production is defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>.</p><h3 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1</a>&nbsp;No-tag-list Production</h3><p id="rfc.section.9.4.1.p.1">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.</p><p id="rfc.section.9.4.1.p.2">If
+a method, due to the presence of a Depth or Destination header, is
+applied to multiple resources then the No-tag-list production <em class="bcp14">MUST</em> be applied to each resource the method is applied to.</p><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;Example - No-tag-list If Header</h4><div id="rfc.figure.u.37"></div><pre class="text">   If: (&lt;locktoken:a-write-lock-token&gt; ["I am an ETag"]) (["I am another
+   ETag"])
+</pre><p id="rfc.section.">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
+&lt;locktoken:a-write-lock-token&gt; ["I am an ETag"]) (and ["I am
+another ETag"])).</p><h3 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a>&nbsp;Tagged-list Production</h3><p id="rfc.section.9.4.2.p.1">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.</p><p id="rfc.section.9.4.2.p.2">When the If header is applied to a particular resource, the Tagged-list productions <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> be applied to the resource in the manner specified in the previous section.</p><p id="rfc.section.9.4.2.p.3">The same URI <em class="bcp14">MUST NOT</em> appear more than once in a resource production in an If header.</p><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;Example - Tagged List If header</h4><div id="rfc.figure.u.38"></div><pre class="text2">   COPY /resource1 HTTP/1.1
+   Host:
+   Destination:
+   If: &lt;; (&lt;locktoken:a-write-lock-token&gt;
+   [W/"A weak ETag"]) (["strong ETag"])
+   &lt;;(["another strong ETag"])
+</pre><p id="rfc.section.">In this example
+ is being copied to
+ When the method is first applied to
+, resource1 must be in the state specified
+by "(&lt;locktoken:a-write-lock-token&gt; [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".</p><p id="rfc.section.">That
+is the only success condition since the resource
+ never has the method applied to it (the only
+other resource listed in the If header) and
+ is not listed in the If header.</p><h3 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a>&nbsp;not Production</h3><p id="rfc.section.9.4.3.p.1">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.</p><div id="rfc.figure.u.39"></div><pre class="text">   If: (Not &lt;locktoken:write1&gt; &lt;locktoken:write2&gt;)
+</pre><p id="rfc.section.9.4.3.p.3">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.</p><h3 id="rfc.section.9.4.4"><a href="#rfc.section.9.4.4">9.4.4</a>&nbsp;Matching Function</h3><p id="rfc.section.9.4.4.p.1">When performing If header processing, the definition of a matching state token or entity tag is as follows.</p><p id="rfc.section.9.4.4.p.2">Matching entity tag: Where the entity tag matches an entity tag associated with that resource.</p><p id="rfc.section.9.4.4.p.3">Matching
+state token: Where there is an exact match between the state token in
+the If header and any state token on the resource.</p><h3 id="rfc.section.9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a>&nbsp;If Header and Non-DAV Compliant Proxies</h3><p id="rfc.section.9.4.5.p.1">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 <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> be used for the same reason.</p><div id="rfc.iref.l.3"></div><div id="rfc.iref.h.5"></div><h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="HEADER_Lock-Token" href="#HEADER_Lock-Token">Lock-Token Header</a></h2><div id="rfc.figure.u.40"></div><pre class="inline">   Lock-Token = "Lock-Token" ":" Coded-URL
+</pre><p id="rfc.section.9.5.p.2">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 <em class="bcp14">MUST</em> identify a lock that contains the resource identified by Request-URI as a member.</p><p id="rfc.section.9.5.p.3">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.</p><div id="rfc.iref.o.1"></div><div id="rfc.iref.h.6"></div><h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="HEADER_Overwrite" href="#HEADER_Overwrite">Overwrite Header</a></h2><div id="rfc.figure.u.41"></div><pre class="inline">   Overwrite = "Overwrite" ":" ("T" | "F")
+</pre><p id="rfc.section.9.6.p.2">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 <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.9.6.p.3">If a COPY or MOVE is not performed due to the value of the Overwrite header, the method <em class="bcp14">MUST</em> fail with a 412 (Precondition Failed) status code.</p><p id="rfc.section.9.6.p.4">All DAV compliant resources <em class="bcp14">MUST</em> support the Overwrite header.</p><div id="rfc.iref.s.1"></div><div id="rfc.iref.h.7"></div><div id="rfc.iref.41"></div><div id="rfc.iref.s.2"></div><h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="HEADER_Status-URI" href="#HEADER_Status-URI">Status-URI Response Header</a></h2><p id="rfc.section.9.7.p.1">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.</p><div id="rfc.figure.u.42"></div><pre class="inline">   Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
+   is defined in <a href="" id="rfc.xref.RFC2068.12">Section 6.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.13"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>
+</pre><p id="rfc.section.9.7.p.3">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.</p><div id="rfc.iref.t.1"></div><div id="rfc.iref.h.8"></div><h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="HEADER_Timeout" href="#HEADER_Timeout">Timeout Request Header</a></h2><div id="rfc.figure.u.43"></div><pre class="inline">   TimeOut = "Timeout" ":" 1#TimeType
+   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
+   DAVTimeOutVal = 1*digit
+   Other = "Extend" field-value   ; See section <a href="" id="rfc.xref.RFC2068.14">4.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.15"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>
+</pre><p id="rfc.section.9.8.p.2">Clients may include Timeout headers
+in their LOCK requests. However, the server is not required to honor or
+even consider these requests. Clients <em class="bcp14">MUST NOT</em> submit a Timeout request header with any method other than a LOCK method.</p><p id="rfc.section.9.8.p.3">A Timeout request header <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.9.8.p.4">Timeout response values <em class="bcp14">MUST</em>
+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.</p><p id="rfc.section.9.8.p.5">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" <em class="bcp14">MUST</em> NOT be greater than 2^32-1.</p><p id="rfc.section.9.8.p.6">The timeout counter <em class="bcp14">SHOULD</em>
+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 <em class="bcp14">MUST</em> be refreshed if a refresh LOCK method is successfully received.</p><p id="rfc.section.9.8.p.7">If
+the timeout expires then the lock may be lost. Specifically, if the
+server wishes to harvest the lock upon time-out, the server <em class="bcp14">SHOULD</em>
+act as if an UNLOCK method was executed by the server on the resource
+using the lock token of the timed-out lock, performed with its override
+authority. Thus logs should be updated with the disposition of the
+lock, notifications should be sent, etc., just as they would be for an
+UNLOCK request.</p><p id="rfc.section.9.8.p.8">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.</p><p id="rfc.section.9.8.p.9">A client <em class="bcp14">MUST NOT</em> assume that just because the time-out has expired the lock has been lost.</p><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="" href="">Status Code Extensions to HTTP/1.1</a></h1><p id="rfc.section.10.p.1">The following status codes are added to those defined in HTTP/1.1 <a href="#RFC2068" id="rfc.xref.RFC2068.16"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.</p><div id="rfc.iref.44"></div><div id="rfc.iref.s.3"></div><h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="STATUS_102" href="#STATUS_102">102 Processing</a></h2><p id="rfc.section.10.1.p.1">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 <em class="bcp14">SHOULD</em> 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 <em class="bcp14">SHOULD</em> return a 102 (Processing) response. The server <em class="bcp14">MUST</em> send a final response after the request has been completed.</p><p id="rfc.section.10.1.p.2">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.</p><div id="rfc.iref.45"></div><div id="rfc.iref.s.4"></div><h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="STATUS_207" href="#STATUS_207">207 Multi-Status</a></h2><p id="rfc.section.10.2.p.1">The 207 (Multi-Status) status code provides status for multiple independent operations (see <a href="#multi-status.response" title="Multi-Status Response">Section&nbsp;11</a> for more information).</p><div id="rfc.iref.46"></div><div id="rfc.iref.s.5"></div><h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="STATUS_422" href="#STATUS_422">422 Unprocessable Entity</a></h2><p id="rfc.section.10.3.p.1">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.</p><div id="rfc.iref.47"></div><div id="rfc.iref.s.6"></div><h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="STATUS_423" href="#STATUS_423">423 Locked</a></h2><p id="rfc.section.10.4.p.1">The 423 (Locked) status code means the source or destination resource of a method is locked.</p><div id="rfc.iref.48"></div><div id="rfc.iref.s.7"></div><h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="STATUS_424" href="#STATUS_424">424 Failed Dependency</a></h2><p id="rfc.section.10.5.p.1">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).</p><div id="rfc.iref.49"></div><div id="rfc.iref.s.8"></div><h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="STATUS_507" href="#STATUS_507">507 Insufficient Storage</a></h2><p id="rfc.section.10.6.p.1">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 <em class="bcp14">MUST NOT</em> be repeated until it is requested by a separate user action.</p><div id="rfc.iref.50"></div><div id="rfc.iref.s.9"></div><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="multi-status.response" href="#multi-status.response">Multi-Status Response</a></h1><p id="rfc.section.11.p.1">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 <em class="bcp14">SHOULD NOT</em> be recorded in a response XML element.</p><h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="xml.element.definitions" href="#xml.element.definitions">XML Element Definitions</a></h1><p id="rfc.section.12.p.1">In the section below, the final line of each section gives the element type declaration using the format defined in <a href="#REC-XML" id="rfc.xref.REC-XML.3"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>.
+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).</p><h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a>&nbsp;<a id="ELEMENT_activelock" href="#ELEMENT_activelock">activelock XML Element</a></h2><div id="rfc.iref.a.1"></div><dl><dt>Name:</dt><dd>activelock</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Describes a lock on a resource.</dd></dl><div id="rfc.figure.u.44"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_activelock">activelock</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>, <a href="#ELEMENT_depth">depth</a>, <a href="#ELEMENT_owner">owner</a>?, <a href="#ELEMENT_timeout">timeout</a>?,
+   <a href="#ELEMENT_locktoken">locktoken</a>?) &gt;
+</pre><h3 id="rfc.section.12.1.1"><a href="#rfc.section.12.1.1">12.1.1</a>&nbsp;<a id="ELEMENT_depth" href="#ELEMENT_depth">depth XML Element</a></h3><div id="rfc.iref.d.6"></div><dl><dt>Name:</dt><dd>depth</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The value of the Depth header.</dd><dt>Value:</dt><dd>"0" | "1" | "infinity"</dd></dl><div id="rfc.figure.u.45"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_depth">depth</a> (#PCDATA) &gt;
+</pre><h3 id="rfc.section.12.1.2"><a href="#rfc.section.12.1.2">12.1.2</a>&nbsp;<a id="ELEMENT_locktoken" href="#ELEMENT_locktoken">locktoken XML Element</a></h3><div id="rfc.iref.l.4"></div><dl><dt>Name:</dt><dd>locktoken</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The lock token associated with a lock.</dd><dt>Description:</dt><dd>The
+href contains one or more opaque lock token URIs which all refer to the
+same lock (i.e., the OpaqueLockToken-URI production in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>).</dd></dl><div id="rfc.figure.u.46"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_locktoken">locktoken</a> (<a href="#ELEMENT_href">href</a>+) &gt;
+</pre><h3 id="rfc.section.12.1.3"><a href="#rfc.section.12.1.3">12.1.3</a>&nbsp;<a id="ELEMENT_timeout" href="#ELEMENT_timeout">timeout XML Element</a></h3><div id="rfc.iref.t.2"></div><dl><dt>Name:</dt><dd>timeout</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The timeout associated with a lock</dd><dt>Value:</dt><dd>TimeType ;Defined in <a href="#HEADER_Timeout" title="Timeout Request Header">Section&nbsp;9.8</a></dd></dl><div id="rfc.figure.u.47"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_timeout">timeout</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a>&nbsp;<a id="ELEMENT_collection" href="#ELEMENT_collection">collection XML Element</a></h2><div id="rfc.iref.d.7"></div><div id="rfc.iref.r.1"></div><dl><dt>Name:</dt><dd>collection</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the associated resource as a collection. The resourcetype property of a collection resource <em class="bcp14">MUST</em> have this value.</dd></dl><div id="rfc.figure.u.48"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_collection">collection</a> EMPTY &gt;
+</pre><h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a>&nbsp;<a id="ELEMENT_href" href="#ELEMENT_href">href XML Element</a></h2><div id="rfc.iref.h.9"></div><dl><dt>Name:</dt><dd>href</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the content of the element as a URI.</dd><dt>Value:</dt><dd>URI ; See section <a href="" id="rfc.xref.RFC2068.17">3.2.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.18"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.49"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_href">href</a> (#PCDATA)&gt;
+</pre><h2 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a>&nbsp;<a id="ELEMENT_link" href="#ELEMENT_link">link XML Element</a></h2><div id="rfc.iref.l.5"></div><dl><dt>Name:</dt><dd>link</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Identifies the property as a link and contains the source and destination of that link.</dd><dt>Description:</dt><dd>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 <em class="bcp14">MUST NOT</em> be rejected if they point to resources which do not exist.</dd></dl><div id="rfc.figure.u.50"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_link">link</a> (<a href="#ELEMENT_src">src</a>+, <a href="#ELEMENT_dst">dst</a>+) &gt;
+</pre><h3 id="rfc.section.12.4.1"><a href="#rfc.section.12.4.1">12.4.1</a>&nbsp;<a id="ELEMENT_dst" href="#ELEMENT_dst">dst XML Element</a></h3><div id="rfc.iref.d.8"></div><dl><dt>Name:</dt><dd>dst</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Indicates the destination of a link</dd><dt>Value:</dt><dd>URI</dd></dl><div id="rfc.figure.u.51"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_dst">dst</a> (#PCDATA) &gt;
+</pre><h3 id="rfc.section.12.4.2"><a href="#rfc.section.12.4.2">12.4.2</a>&nbsp;<a id="ELEMENT_src" href="#ELEMENT_src">src XML Element</a></h3><div id="rfc.iref.s.10"></div><dl><dt>Name:</dt><dd>src</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Indicates the source of a link.</dd><dt>Value:</dt><dd>URI</dd></dl><div id="rfc.figure.u.52"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_src">src</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.12.5"><a href="#rfc.section.12.5">12.5</a>&nbsp;<a id="ELEMENT_lockentry" href="#ELEMENT_lockentry">lockentry XML Element</a></h2><div id="rfc.iref.l.6"></div><dl><dt>Name:</dt><dd>lockentry</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Defines the types of locks that can be used with the resource.</dd></dl><div id="rfc.figure.u.53"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockentry">lockentry</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>) &gt;
+</pre><h2 id="rfc.section.12.6"><a href="#rfc.section.12.6">12.6</a>&nbsp;<a id="ELEMENT_lockinfo" href="#ELEMENT_lockinfo">lockinfo XML Element</a></h2><div id="rfc.iref.l.7"></div><dl><dt>Name:</dt><dd>lockinfo</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.</dd></dl><div id="rfc.figure.u.54"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockinfo">lockinfo</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>, <a href="#ELEMENT_owner">owner</a>?) &gt;
+</pre><h2 id="rfc.section.12.7"><a href="#rfc.section.12.7">12.7</a>&nbsp;<a id="ELEMENT_lockscope" href="#ELEMENT_lockscope">lockscope XML Element</a></h2><div id="rfc.iref.l.8"></div><dl><dt>Name:</dt><dd>lockscope</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies whether a lock is an exclusive lock, or a shared lock.</dd></dl><div id="rfc.figure.u.55"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_lockscope">lockscope</a> (<a href="#ELEMENT_exclusive">exclusive</a> | <a href="#ELEMENT_shared">shared</a>) &gt;
+</pre><h3 id="rfc.section.12.7.1"><a href="#rfc.section.12.7.1">12.7.1</a>&nbsp;<a id="ELEMENT_exclusive" href="#ELEMENT_exclusive">exclusive XML Element</a></h3><div id="rfc.iref.e.1"></div><dl><dt>Name:</dt><dd>exclusive</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies an exclusive lock</dd></dl><div id="rfc.figure.u.56"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_exclusive">exclusive</a> EMPTY &gt;
+</pre><h3 id="rfc.section.12.7.2"><a href="#rfc.section.12.7.2">12.7.2</a>&nbsp;<a id="ELEMENT_shared" href="#ELEMENT_shared">shared XML Element</a></h3><div id="rfc.iref.s.11"></div><dl><dt>Name:</dt><dd>shared</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies a shared lock</dd></dl><div id="rfc.figure.u.57"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_shared">shared</a> EMPTY &gt;
+</pre><h2 id="rfc.section.12.8"><a href="#rfc.section.12.8">12.8</a>&nbsp;<a id="ELEMENT_locktype" href="#ELEMENT_locktype">locktype XML Element</a></h2><div id="rfc.iref.l.9"></div><dl><dt>Name:</dt><dd>locktype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.</dd></dl><div id="rfc.figure.u.58"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_locktype">locktype</a> (<a href="#ELEMENT_write">write</a>) &gt;
+</pre><h3 id="rfc.section.12.8.1"><a href="#rfc.section.12.8.1">12.8.1</a>&nbsp;<a id="ELEMENT_write" href="#ELEMENT_write">write XML Element</a></h3><div id="rfc.iref.w.1"></div><dl><dt>Name:</dt><dd>write</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies a write lock.</dd></dl><div id="rfc.figure.u.59"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_write">write</a> EMPTY &gt;
+</pre><h2 id="rfc.section.12.9"><a href="#rfc.section.12.9">12.9</a>&nbsp;<a id="ELEMENT_multistatus" href="#ELEMENT_multistatus">multistatus XML Element</a></h2><div id="rfc.iref.m.13"></div><dl><dt>Name:</dt><dd>multistatus</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains multiple response messages.</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.60"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_multistatus">multistatus</a> (<a href="#ELEMENT_response">response</a>+, <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+</pre><h3 id="rfc.section.12.9.1"><a href="#rfc.section.12.9.1">12.9.1</a>&nbsp;<a id="ELEMENT_response" href="#ELEMENT_response">response XML Element</a></h3><div id="rfc.iref.r.2"></div><dl><dt>Name:</dt><dd>response</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Holds a single response describing the effect of a method on resource and/or its properties.</dd><dt>Description:</dt><dd>A particular href <em class="bcp14">MUST NOT</em>
+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.</dd></dl><div id="rfc.figure.u.61"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_response">response</a> (<a href="#ELEMENT_href">href</a>, ((<a href="#ELEMENT_href">href</a>*, <a href="#ELEMENT_status">status</a>)|(<a href="#ELEMENT_propstat">propstat</a>+)),
+   <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+</pre><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;<a id="ELEMENT_propstat" href="#ELEMENT_propstat">propstat XML Element</a></h4><div id="rfc.iref.p.5"></div><dl><dt>Name:</dt><dd>propstat</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Groups together a prop and status element that is associated with a particular href element.</dd><dt>Description:</dt><dd>The propstat XML element <em class="bcp14">MUST</em> contain one prop XML element and one status XML element. The contents of the prop XML element <em class="bcp14">MUST</em> only list the names of properties to which the result in the status element applies.</dd></dl><div id="rfc.figure.u.62"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propstat">propstat</a> (<a href="#ELEMENT_prop">prop</a>, <a href="#ELEMENT_status">status</a>, <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+</pre><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;<a id="ELEMENT_status" href="#ELEMENT_status">status XML Element</a></h4><div id="rfc.iref.s.12"></div><dl><dt>Name:</dt><dd>status</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Holds a single HTTP status-line</dd><dt>Value:</dt><dd>status-line ;status-line defined in <a href="#RFC2068" id="rfc.xref.RFC2068.19"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.63"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_status">status</a> (#PCDATA) &gt;
+</pre><h3 id="rfc.section.12.9.2"><a href="#rfc.section.12.9.2">12.9.2</a>&nbsp;<a id="ELEMENT_responsedescription" href="#ELEMENT_responsedescription">responsedescription XML Element</a></h3><div id="rfc.iref.r.3"></div><dl><dt>Name:</dt><dd>responsedescription</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains a message that can be displayed to the user explaining the nature of the response.</dd><dt>Description:</dt><dd>This XML element provides information suitable to be presented to a user.</dd></dl><div id="rfc.figure.u.64"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_responsedescription">responsedescription</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.12.10"><a href="#rfc.section.12.10">12.10</a>&nbsp;<a id="ELEMENT_owner" href="#ELEMENT_owner">owner XML Element</a></h2><div id="rfc.iref.o.2"></div><dl><dt>Name:</dt><dd>owner</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Provides information about the principal taking out a lock.</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.65"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_owner">owner</a> ANY&gt;
+</pre><h2 id="rfc.section.12.11"><a href="#rfc.section.12.11">12.11</a>&nbsp;<a id="ELEMENT_prop" href="#ELEMENT_prop">prop XML element</a></h2><div id="rfc.iref.p.6"></div><dl><dt>Name:</dt><dd>prop</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains properties related to a resource.</dd><dt>Description:</dt><dd>The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element <em class="bcp14">MUST</em> define properties related to the resource. No other elements may be used inside of a prop element.</dd></dl><div id="rfc.figure.u.66"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_prop">prop</a> ANY&gt;
+</pre><h2 id="rfc.section.12.12"><a href="#rfc.section.12.12">12.12</a>&nbsp;<a id="ELEMENT_propertybehaviour" href="#ELEMENT_propertybehaviour">propertybehavior XML element</a></h2><div id="rfc.iref.p.7"></div><dl><dt>Name:</dt><dd>propertybehavior</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies how properties are handled during a COPY or MOVE.</dd><dt>Description:</dt><dd>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 <em class="bcp14">MUST</em> support the propertybehavior XML element.</dd></dl><div id="rfc.figure.u.67"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propertybehaviour">propertybehavior</a> (<a href="#ELEMENT_omit">omit</a> | <a href="#ELEMENT_keepalive">keepalive</a>) &gt;
+</pre><h3 id="rfc.section.12.12.1"><a href="#rfc.section.12.12.1">12.12.1</a>&nbsp;<a id="ELEMENT_keepalive" href="#ELEMENT_keepalive">keepalive XML element</a></h3><div id="rfc.iref.k.1"></div><dl><dt>Name:</dt><dd>keepalive</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies requirements for the copying/moving of live properties.</dd><dt>Description:</dt><dd>If a list of URIs is included as the value of keepalive then the named properties <em class="bcp14">MUST</em>
+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 <em class="bcp14">MUST</em> be live on the destination. If the requirements specified by the keepalive element can not be honored then the method <em class="bcp14">MUST</em> fail with a 412 (Precondition Failed). All DAV compliant resources <em class="bcp14">MUST</em> support the keepalive XML element for use with the COPY and MOVE methods.</dd><dt>Value:</dt><dd>"*" ; #PCDATA value can only be "*"</dd></dl><div id="rfc.figure.u.68"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_keepalive">keepalive</a> (#PCDATA | <a href="#ELEMENT_href">href</a>+) &gt;
+</pre><h3 id="rfc.section.12.12.2"><a href="#rfc.section.12.12.2">12.12.2</a>&nbsp;<a id="ELEMENT_omit" href="#ELEMENT_omit">omit XML element</a></h3><div id="rfc.iref.o.3"></div><dl><dt>Name:</dt><dd>omit</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The omit XML element instructs the server that it should use best effort to copy properties but a failure to copy a property <em class="bcp14">MUST NOT</em> cause the method to fail.</dd><dt>Description:</dt><dd>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 <em class="bcp14">MUST</em> support the omit XML element on COPY/MOVE methods.</dd></dl><div id="rfc.figure.u.69"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_omit">omit</a> EMPTY &gt;
+</pre><h2 id="rfc.section.12.13"><a href="#rfc.section.12.13">12.13</a>&nbsp;<a id="ELEMENT_propertyupdate" href="#ELEMENT_propertyupdate">propertyupdate XML element</a></h2><div id="rfc.iref.p.8"></div><dl><dt>Name:</dt><dd>propertyupdate</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains a request to alter the properties on a resource.</dd><dt>Description:</dt><dd>This
+XML element is a container for the information required to modify the
+properties on the resource. This XML element is multi-valued.</dd></dl><div id="rfc.figure.u.70"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propertyupdate">propertyupdate</a> (<a href="#ELEMENT_remove">remove</a> | <a href="#ELEMENT_set">set</a>)+ &gt;
+</pre><h3 id="rfc.section.12.13.1"><a href="#rfc.section.12.13.1">12.13.1</a>&nbsp;<a id="ELEMENT_remove" href="#ELEMENT_remove">remove XML element</a></h3><div id="rfc.iref.r.4"></div><dl><dt>Name:</dt><dd>remove</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Lists the DAV properties to be removed from a resource.</dd><dt>Description:</dt><dd>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 <em class="bcp14">MUST</em> be empty, as only the names of properties to be removed are required.</dd></dl><div id="rfc.figure.u.71"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_remove">remove</a> (<a href="#ELEMENT_prop">prop</a>) &gt;
+</pre><h3 id="rfc.section.12.13.2"><a href="#rfc.section.12.13.2">12.13.2</a>&nbsp;<a id="ELEMENT_set" href="#ELEMENT_set">set XML element</a></h3><div id="rfc.iref.s.13"></div><dl><dt>Name:</dt><dd>set</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Lists the DAV property values to be set for a resource.</dd><dt>Description:</dt><dd>The set XML element <em class="bcp14">MUST</em> contain only a prop XML element. The elements contained by the prop XML element inside the set XML element <em class="bcp14">MUST</em>
+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) <em class="bcp14">MUST</em> be persistently stored along with the property, and <em class="bcp14">MUST</em> be subsequently retrievable using PROPFIND.</dd></dl><div id="rfc.figure.u.72"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_set">set</a> (<a href="#ELEMENT_prop">prop</a>) &gt;
+</pre><h2 id="rfc.section.12.14"><a href="#rfc.section.12.14">12.14</a>&nbsp;<a id="ELEMENT_propfind" href="#ELEMENT_propfind">propfind XML Element</a></h2><div id="rfc.iref.p.9"></div><dl><dt>Name:</dt><dd>propfind</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>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 <em class="bcp14">MUST</em> only contain property names, not values.</dd></dl><div id="rfc.figure.u.73"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propfind">propfind</a> (<a href="#ELEMENT_allprop">allprop</a> | <a href="#ELEMENT_propname">propname</a> | <a href="#ELEMENT_prop">prop</a>) &gt;
+</pre><h3 id="rfc.section.12.14.1"><a href="#rfc.section.12.14.1">12.14.1</a>&nbsp;<a id="ELEMENT_allprop" href="#ELEMENT_allprop">allprop XML Element</a></h3><div id="rfc.iref.a.2"></div><dl><dt>Name:</dt><dd>allprop</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The allprop XML element specifies that all property names and values on the resource are to be returned.</dd></dl><div id="rfc.figure.u.74"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_allprop">allprop</a> EMPTY &gt;
+</pre><h3 id="rfc.section.12.14.2"><a href="#rfc.section.12.14.2">12.14.2</a>&nbsp;<a id="ELEMENT_propname" href="#ELEMENT_propname">propname XML Element</a></h3><div id="rfc.iref.p.10"></div><dl><dt>Name:</dt><dd>propname</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The propname XML element specifies that only a list of property names on the resource is to be returned.</dd></dl><div id="rfc.figure.u.75"></div><pre class="inline">   &lt;!ELEMENT <a href="#ELEMENT_propname">propname</a> EMPTY &gt;
+</pre><h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<a id="" href="">DAV Properties</a></h1><p id="rfc.section.13.p.1">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 <a href="#REC-XML" id="rfc.xref.REC-XML.4"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>.
+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).</p><h2 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a>&nbsp;<a id="PROPERTY_creationdate" href="#PROPERTY_creationdate">creationdate Property</a></h2><div id="rfc.iref.d.9"></div><div id="rfc.iref.p.11"></div><dl><dt>Name:</dt><dd>creationdate</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Records the time and date the resource was created.</dd><dt>Value:</dt><dd>date-time ; See <a href="" title="Appendix 2 - ISO 8601 Date and Time Profile">Appendix&nbsp;23.2</a></dd><dt>Description:</dt><dd>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).</dd></dl><div id="rfc.figure.u.76"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_creationdate">creationdate</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.2"><a href="#rfc.section.13.2">13.2</a>&nbsp;<a id="PROPERTY_displayname" href="#PROPERTY_displayname">displayname Property</a></h2><div id="rfc.iref.d.10"></div><div id="rfc.iref.p.12"></div><dl><dt>Name:</dt><dd>displayname</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Provides a name for the resource that is suitable for presentation to a user.</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.77"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_displayname">displayname</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.3"><a href="#rfc.section.13.3">13.3</a>&nbsp;<a id="PROPERTY_getcontentlanguage" href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></h2><div id="rfc.iref.d.11"></div><div id="rfc.iref.p.13"></div><dl><dt>Name:</dt><dd>getcontentlanguage</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Language header returned by a GET without accept headers</dd><dt>Description:</dt><dd>The getcontentlanguage property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Language header on a GET.</dd><dt>Value:</dt><dd>language-tag ;language-tag is defined in section <a href="" id="rfc.xref.RFC2068.20">14.13</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.21"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.78"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontentlanguage">getcontentlanguage</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.4"><a href="#rfc.section.13.4">13.4</a>&nbsp;<a id="PROPERTY_getcontentlength" href="#PROPERTY_getcontentlength">getcontentlength Property</a></h2><div id="rfc.iref.d.12"></div><div id="rfc.iref.p.14"></div><dl><dt>Name:</dt><dd>getcontentlength</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Length header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>The getcontentlength property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Length header in response to a GET.</dd><dt>Value:</dt><dd>content-length ; see section <a href="" id="rfc.xref.RFC2068.22">14.14</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.23"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.79"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontentlength">getcontentlength</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.5"><a href="#rfc.section.13.5">13.5</a>&nbsp;<a id="PROPERTY_getcontenttype" href="#PROPERTY_getcontenttype">getcontenttype Property</a></h2><div id="rfc.iref.d.13"></div><div id="rfc.iref.p.15"></div><dl><dt>Name:</dt><dd>getcontenttype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Content-Type header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>This getcontenttype property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Content-Type header in response to a GET.</dd><dt>Value:</dt><dd>media-type ; defined in section <a href="" id="rfc.xref.RFC2068.24">3.7</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.25"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.80"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getcontenttype">getcontenttype</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.6"><a href="#rfc.section.13.6">13.6</a>&nbsp;<a id="PROPERTY_getetag" href="#PROPERTY_getetag">getetag Property</a></h2><div id="rfc.iref.d.14"></div><div id="rfc.iref.p.16"></div><dl><dt>Name:</dt><dd>getetag</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the ETag header returned by a GET without accept headers.</dd><dt>Description:</dt><dd>The getetag property <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Etag header.</dd><dt>Value:</dt><dd>entity-tag ; defined in section <a href="" id="rfc.xref.RFC2068.26">3.11</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.27"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.81"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getetag">getetag</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.7"><a href="#rfc.section.13.7">13.7</a>&nbsp;<a id="PROPERTY_getlastmodified" href="#PROPERTY_getlastmodified">getlastmodified Property</a></h2><div id="rfc.iref.d.15"></div><div id="rfc.iref.p.17"></div><dl><dt>Name:</dt><dd>getlastmodified</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Contains the Last-Modified header returned by a GET method without accept headers.</dd><dt>Description:</dt><dd>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 <em class="bcp14">MUST</em> be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET.</dd><dt>Value:</dt><dd>HTTP-date ; defined in section <a href="" id="rfc.xref.RFC2068.28">3.3.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.29"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a></dd></dl><div id="rfc.figure.u.82"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_getlastmodified">getlastmodified</a> (#PCDATA) &gt;
+</pre><h2 id="rfc.section.13.8"><a href="#rfc.section.13.8">13.8</a>&nbsp;<a id="PROPERTY_lockdiscovery" href="#PROPERTY_lockdiscovery">lockdiscovery Property</a></h2><div id="rfc.iref.d.16"></div><div id="rfc.iref.p.18"></div><dl><dt>Name:</dt><dd>lockdiscovery</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Describes the active locks on a resource</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.83"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_lockdiscovery">lockdiscovery</a> (<a href="#ELEMENT_activelock">activelock</a>)* &gt;
+</pre><h3 id="rfc.section.13.8.1"><a href="#rfc.section.13.8.1">13.8.1</a>&nbsp;Example - Retrieving the lockdiscovery Property</h3><div id="rfc.figure.u.84"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPFIND /container/ HTTP/1.1
+   Host:
+   Content-Length: xxxx
+   Content-Type: text/xml; charset="utf-8"
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D='DAV:'&gt;
+     &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;
+   &lt;/D:propfind&gt;
+</pre><div id="rfc.figure.u.85"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D='DAV:'&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;
+                    &lt;D:lockdiscovery&gt;
+                         &lt;D:activelock&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:depth&gt;0&lt;/D:depth&gt;
+                              &lt;D:owner&gt;Jane Smith&lt;/D:owner&gt;
+                              &lt;D:timeout&gt;Infinite&lt;/D:timeout&gt;
+                              &lt;D:locktoken&gt;
+                                   &lt;D:href&gt;
+               opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
+                                   &lt;/D:href&gt;
+                              &lt;/D:locktoken&gt;
+                         &lt;/D:activelock&gt;
+                    &lt;/D:lockdiscovery&gt;
+               &lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+   &lt;/D:multistatus&gt;
+</pre><p id="rfc.section.13.8.1.p.3">This resource has a single exclusive write lock on it, with an infinite timeout.</p><h2 id="rfc.section.13.9"><a href="#rfc.section.13.9">13.9</a>&nbsp;<a id="PROPERTY_resourcetype" href="#PROPERTY_resourcetype">resourcetype Property</a></h2><div id="rfc.iref.d.17"></div><div id="rfc.iref.p.19"></div><dl><dt>Name:</dt><dd>resourcetype</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>Specifies the nature of the resource.</dd><dt>Description:</dt><dd>The resourcetype property <em class="bcp14">MUST</em> be defined on all DAV compliant resources. The default value is empty.</dd></dl><div id="rfc.figure.u.86"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_resourcetype">resourcetype</a> ANY &gt;
+</pre><h2 id="rfc.section.13.10"><a href="#rfc.section.13.10">13.10</a>&nbsp;<a id="PROPERTY_source" href="#PROPERTY_source">source Property</a></h2><div id="rfc.iref.d.18"></div><div id="rfc.iref.p.20"></div><dl><dt>Name:</dt><dd>source</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>The destination of the source link identifies the resource that contains the unprocessed source of the link's source.</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.87"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_source">source</a> (<a href="#ELEMENT_link">link</a>)* &gt;
+</pre><h3 id="rfc.section.13.10.1"><a href="#rfc.section.13.10.1">13.10.1</a>&nbsp;Example - A source Property</h3><div id="rfc.figure.u.88"></div><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:prop xmlns:D="DAV:" xmlns:F=""&gt;
+     &lt;D:source&gt;
+          &lt;D:link&gt;
+               &lt;F:projfiles&gt;Source&lt;/F:projfiles&gt;
+               &lt;D:src&gt;;/D:src&gt;
+               &lt;D:dst&gt;;/D:dst&gt;
+          &lt;/D:link&gt;
+          &lt;D:link&gt;
+               &lt;F:projfiles&gt;Library&lt;/F:projfiles&gt;
+               &lt;D:src&gt;;/D:src&gt;
+               &lt;D:dst&gt;;/D:dst&gt;
+          &lt;/D:link&gt;
+          &lt;D:link&gt;
+               &lt;F:projfiles&gt;Makefile&lt;/F:projfiles&gt;
+               &lt;D:src&gt;;/D:src&gt;
+               &lt;D:dst&gt;;/D:dst&gt;
+          &lt;/D:link&gt;
+     &lt;/D:source&gt;
+   &lt;/D:prop&gt;
+</pre><p id="rfc.section.13.10.1.p.2">In this example the resource
+ 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 (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.</p><h2 id="rfc.section.13.11"><a href="#rfc.section.13.11">13.11</a>&nbsp;<a id="PROPERTY_supportedlock" href="#PROPERTY_supportedlock">supportedlock Property</a></h2><div id="rfc.iref.d.19"></div><div id="rfc.iref.p.21"></div><dl><dt>Name:</dt><dd>supportedlock</dd><dt>Namespace:</dt><dd>DAV:</dd><dt>Purpose:</dt><dd>To provide a listing of the lock capabilities supported by the resource.</dd><dt>Description:</dt><dd>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.</dd></dl><div id="rfc.figure.u.89"></div><pre class="inline">   &lt;!ELEMENT <a href="#PROPERTY_supportedlock">supportedlock</a> (<a href="#ELEMENT_lockentry">lockentry</a>)* &gt;
+</pre><h3 id="rfc.section.13.11.1"><a href="#rfc.section.13.11.1">13.11.1</a>&nbsp;Example - Retrieving the supportedlock Property</h3><div id="rfc.figure.u.90"></div><p>&gt;&gt;Request</p>  <pre class="text2">   PROPFIND  /container/ HTTP/1.1
+   Host:
+   Content-Length: xxxx
+   Content-Type: text/xml; charset="utf-8"
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"&gt;
+     &lt;D:prop&gt;&lt;D:supportedlock/&gt;&lt;/D:prop&gt;
+   &lt;/D:propfind&gt;
+</pre><div id="rfc.figure.u.91"></div><p>&gt;&gt;Response</p>  <pre class="text">   HTTP/1.1 207 Multi-Status
+   Content-Type: text/xml; charset="utf-8"
+   Content-Length: xxxx
+   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:multistatus xmlns:D="DAV:"&gt;
+     &lt;D:response&gt;
+          &lt;D:href&gt;;/D:href&gt;
+          &lt;D:propstat&gt;
+               &lt;D:prop&gt;
+                    &lt;D:supportedlock&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:exclusive/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                         &lt;D:lockentry&gt;
+                              &lt;D:lockscope&gt;&lt;D:shared/&gt;&lt;/D:lockscope&gt;
+                              &lt;D:locktype&gt;&lt;D:write/&gt;&lt;/D:locktype&gt;
+                         &lt;/D:lockentry&gt;
+                    &lt;/D:supportedlock&gt;
+               &lt;/D:prop&gt;
+               &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
+          &lt;/D:propstat&gt;
+     &lt;/D:response&gt;
+   &lt;/D:multistatus&gt;
+</pre><h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a>&nbsp;<a id="" href="">Instructions for Processing XML in DAV</a></h1><p id="rfc.section.14.p.1">All DAV compliant resources <em class="bcp14">MUST</em>
+ignore any unknown XML element and all its children encountered while
+processing a DAV method that uses XML as its command language.</p><p id="rfc.section.14.p.2">This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements <em class="bcp14">SHOULD</em> be ignored unless the property's schema declares otherwise.</p><p id="rfc.section.14.p.3">This restriction does not apply to setting dead DAV properties on the server where the server <em class="bcp14">MUST</em> record unknown XML elements.</p><p id="rfc.section.14.p.4">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.</p><p id="rfc.section.14.p.5">Since XML can be transported as text/xml or application/xml, a DAV server <em class="bcp14">MUST</em> accept DAV method requests with XML parameters transported as either text/xml or application/xml, and DAV client <em class="bcp14">MUST</em> accept XML responses using either text/xml or application/xml.</p><h1 id="rfc.section.15"><a href="#rfc.section.15">15.</a>&nbsp;<a id="dav.compliance.classes" href="#dav.compliance.classes">DAV Compliance Classes</a></h1><p id="rfc.section.15.p.1">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.</p><p id="rfc.section.15.p.2">Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies <em class="bcp14">MUST</em> be compliant with <a href="#RFC2068" id="rfc.xref.RFC2068.30"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.</p><p id="rfc.section.15.p.3">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.</p><div id="rfc.iref.d.20"></div><h2 id="rfc.section.15.1"><a href="#rfc.section.15.1">15.1</a>&nbsp;Class 1</h2><p id="rfc.section.15.1.p.1">A class 1 compliant resource <em class="bcp14">MUST</em> meet all "MUST" requirements in all sections of this document.</p><p id="rfc.section.15.1.p.2">Class 1 compliant resources <em class="bcp14">MUST</em> return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.</p><div id="rfc.iref.d.21"></div><h2 id="rfc.section.15.2"><a href="#rfc.section.15.2">15.2</a>&nbsp;Class 2</h2><p id="rfc.section.15.2.p.1">A class 2 compliant resource <em class="bcp14">MUST</em>
+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 <em class="bcp14">SHOULD</em> also support the Time-Out request header and the owner XML element.</p><p id="rfc.section.15.2.p.2">Class 2 compliant resources <em class="bcp14">MUST</em> return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.</p><h1 id="rfc.section.16"><a href="#rfc.section.16">16.</a>&nbsp;<a id="internationalization.considerations" href="#internationalization.considerations">Internationalization Considerations</a></h1><p id="rfc.section.16.p.1">In the realm of internationalization, this specification complies with the IETF Character Set Policy <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
+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 <a href="#UTF-8" id="rfc.xref.UTF-8.1"><cite title="UTF-8, a transformation format of ISO 10646">[UTF-8]</cite></a>
+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 <a href="#RFC2376" id="rfc.xref.RFC2376.1"><cite title="XML Media Types">[RFC2376]</cite></a>,
+as well as the XML "encoding" attribute, which together provide charset
+identification information for MIME and XML processors.</p><p id="rfc.section.16.p.2">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 <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>) or ISO 639 language tags <a href="#ISO-639" id="rfc.xref.ISO-639.1"><cite title="ISO 639:1988. Code for the representation of names of languages.">[ISO-639]</cite></a> in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.</p><p id="rfc.section.16.p.3">WebDAV applications <em class="bcp14">MUST</em>
+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" <a href="#RFC2376" id="rfc.xref.RFC2376.2"><cite title="XML Media Types">[RFC2376]</cite></a>
+for instruction on which MIME media type to use for XML transport, and
+on use of the charset parameter of the Content-Type header.</p><p id="rfc.section.16.p.4">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.</p><p id="rfc.section.16.p.5">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
+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.</p><p id="rfc.section.16.p.6">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.</p><p id="rfc.section.16.p.7">Since
+interoperation of clients and servers does not require locale
+information, this specification does not specify any mechanism for
+transmission of this information.</p><h1 id="rfc.section.17"><a href="#rfc.section.17">17.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.17.p.1">This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.</p><p id="rfc.section.17.p.2">All of the security considerations of HTTP/1.1 (discussed in <a href="#RFC2068" id="rfc.xref.RFC2068.31"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) and XML (discussed in <a href="#RFC2376" id="rfc.xref.RFC2376.3"><cite title="XML Media Types">[RFC2376]</cite></a>)
+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.</p><h2 id="rfc.section.17.1"><a href="#rfc.section.17.1">17.1</a>&nbsp;Authentication of Clients</h2><p id="rfc.section.17.1.p.1">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.</p><p id="rfc.section.17.1.p.2">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
+<em class="bcp14">MUST NOT</em> be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server <em class="bcp14">MUST NOT</em>
+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.</p><p id="rfc.section.17.1.p.3">WebDAV applications <em class="bcp14">MUST</em> support the Digest authentication scheme <a href="#RFC2069" id="rfc.xref.RFC2069.1"><cite title="An Extension to HTTP : Digest Access Authentication">[RFC2069]</cite></a>.
+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.</p><h2 id="rfc.section.17.2"><a href="#rfc.section.17.2">17.2</a>&nbsp;Denial of Service</h2><p id="rfc.section.17.2.p.1">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.</p><p id="rfc.section.17.2.p.2">The underlying storage can be attacked by PUTting extremely large files.</p><p id="rfc.section.17.2.p.3">Asking for recursive operations on large collections can attack processing time.</p><p id="rfc.section.17.2.p.4">Making multiple pipelined requests on multiple connections can attack network connections.</p><p id="rfc.section.17.2.p.5">WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.</p><h2 id="rfc.section.17.3"><a href="#rfc.section.17.3">17.3</a>&nbsp;Security through Obscurity</h2><p id="rfc.section.17.3.p.1">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.</p><h2 id="rfc.section.17.4"><a href="#rfc.section.17.4">17.4</a>&nbsp;Privacy Issues Connected to Locks</h2><p id="rfc.section.17.4.p.1">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 <em class="bcp14">SHOULD</em> limit read access to the lockdiscovery property as appropriate. Furthermore, user agents <em class="bcp14">SHOULD</em>
+provide control over whether contact information is sent at all, and if
+contact information is sent, control over exactly what information is
+sent.</p><h2 id="rfc.section.17.5"><a href="#rfc.section.17.5">17.5</a>&nbsp;Privacy Issues Connected to Properties</h2><p id="rfc.section.17.5.p.1">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.</p><h2 id="rfc.section.17.6"><a href="#rfc.section.17.6">17.6</a>&nbsp;Reduction of Security due to Source Link</h2><p id="rfc.section.17.6.p.1">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.</p><h2 id="rfc.section.17.7"><a href="#rfc.section.17.7">17.7</a>&nbsp;Implications of XML External Entities</h2><p id="rfc.section.17.7.p.1">XML supports a facility known as "external entities", defined in section <a href="" id="rfc.xref.REC-XML.5">4.2.2</a> of <a href="#REC-XML" id="rfc.xref.REC-XML.6"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>,
+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 <a href="#REC-XML" id="rfc.xref.REC-XML.7"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>. However, <a href="#REC-XML" id="rfc.xref.REC-XML.8"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a> does state that an XML processor may, at its discretion, include the external XML entity.</p><p id="rfc.section.17.7.p.2">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 case
+significantly modifying its semantics, or exposing the XML processor to
+the security risks discussed in <a href="#RFC2376" id="rfc.xref.RFC2376.4"><cite title="XML Media Types">[RFC2376]</cite></a>. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy.</p><p id="rfc.section.17.7.p.3">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.</p><h2 id="rfc.section.17.8"><a href="#rfc.section.17.8">17.8</a>&nbsp;<a id="risks.connected.with.lock.tokens" href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></h2><p id="rfc.section.17.8.p.1">This specification, in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>,
+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 <a href="#ISO-11578" id="rfc.xref.ISO-11578.4"><cite title="ISO/IEC 11578:1996. Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)">[ISO-11578]</cite></a>,
+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.</p><p id="rfc.section.17.8.p.2">There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:</p><ul><li>It is possible to track the movement of hardware from subnet to subnet.</li><li>It may be possible to identify the manufacturer of the hardware running a WebDAV server.</li><li>It may be possible to determine the number of each type of computer running WebDAV.</li></ul><p id="rfc.section.17.8.p.4"> <a href="" title="Node Field Generation Without the IEEE 802 Address">Section&nbsp;6.4.1</a>
+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.</p><h1 id="rfc.section.18"><a href="#rfc.section.18">18.</a>&nbsp;IANA Considerations</h1><p id="rfc.section.18.p.1">This
+document defines two namespaces, the namespace of property names, and
+the namespace of WebDAV-specific XML elements used within property
+values. 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.</p><p id="rfc.section.18.p.2">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.</p><p id="rfc.section.18.p.3">This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in <a href="#opaquelocktoken.lock.token.uri.scheme" title="opaquelocktoken Lock Token URI Scheme">Section&nbsp;6.4</a>.</p><p id="rfc.section.18.p.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.</p><h1 id="rfc.section.19"><a href="#rfc.section.19">19.</a>&nbsp;Intellectual Property</h1><p id="rfc.section.19.p.1">The following notice is copied from RFC 2026 <a href="#RFC2026" id="rfc.xref.RFC2026.1"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a>, section <a href="" id="rfc.xref.RFC2026.2">10.4</a>, and describes the position of the IETF concerning intellectual property claims made against this document.</p><p id="rfc.section.19.p.2">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.</p><p id="rfc.section.19.p.3">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.</p><h1 id="rfc.section.20"><a href="#rfc.section.20">20.</a>&nbsp;Acknowledgements</h1><p id="rfc.section.20.p.1">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.</p><p id="rfc.section.20.p.2">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.</p><p id="rfc.section.20.p.3">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.</p><p id="rfc.section.20.p.4">We would also like to thank John Turner for developing the XML DTD.</p><h1 id="rfc.references"><a id="rfc.section.21" href="#rfc.section.21">21.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.21.1" id="rfc.section.21.1">21.1</a> Normative References</h2><table summary="Normative References"> <tbody><tr><td class="reference"><b id="RFC1766">[RFC1766]</b></td><td class="top"><a href="" title="UNINETT">Alvestrand, H.T.</a>, &#8220;<a href="">Tags for the Identification of Languages</a>&#8221;, RFC&nbsp;1766, March&nbsp;1995.</td></tr>  <tr><td class="reference"><b id="RFC2277">[RFC2277]</b></td><td class="top"><a href="" title="UNINETT">Alvestrand, H.T.</a>, &#8220;<a href="">IETF Policy on Character Sets and Languages</a>&#8221;, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.</td></tr>  <tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="" title="Harvard University">Bradner, S.</a>, &#8220;<a href="">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr>  <tr><td class="reference"><b id="RFC2396">[RFC2396]</b></td><td class="top"><a href="" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="" title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="" title="Xerox PARC">L. Masinter</a>, &#8220;<a href="">Uniform Resource Identifiers (URI): Generic Syntax</a>&#8221;, RFC&nbsp;2396, August&nbsp;1998.</td></tr>  <tr><td class="reference"><b id="REC-XML">[REC-XML]</b></td><td class="top"><a href="" title="Textuality">Bray, T.</a>, <a href="" title="Microsoft">Paoli, J.</a>, and <a href="" title="University of Illinois at Chicago">C.M. Sperberg-McQueen</a>, &#8220;<a href="">Extensible Markup Language (XML) 1.0</a>&#8221;, W3C&nbsp;REC-xml-19980210, February&nbsp;1998, &lt;<a href=""></a>&gt;.</td></tr>  <tr><td class="reference"><b id="REC-XML-NAMES">[REC-XML-NAMES]</b></td><td class="top"><a href="" title="Textuality">Bray, T.</a>, <a href="" title="Hewlett-Packard Company">Hollander, D.</a>, and <a href="" title="Microsoft">A. Layman</a>, &#8220;<a href="">Namespaces in XML</a>&#8221;, W3C&nbsp;REC-xml-names-19990114, January&nbsp;1999, &lt;<a href=""></a>&gt;.</td></tr>  <tr><td class="reference"><b id="RFC2069">[RFC2069]</b></td><td class="top"><a href="" title="Northwestern University">Franks, J.</a>, <a href="" title="CERN">Hallam-Baker, P.</a>, <a href="" title="Spyglass, Inc.">Hostetler, J.</a>, <a href="" title="Microsoft Corporation">Leach, P.</a>, <a href="" title="Netscape Communications Corporation">Luotonen, A.</a>, <a href="" title="Spyglass, Inc.">Sink, E.</a>, and <a href="" title="Open Market, Inc.">L. Stewart</a>, &#8220;<a href="">An Extension to HTTP : Digest Access Authentication</a>&#8221;, RFC&nbsp;2069, January&nbsp;1997.</td></tr>  <tr><td class="reference"><b id="RFC2068">[RFC2068]</b></td><td class="top"><a href="" title="University of California">Fielding, R.</a>, <a href="" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="" title="Digital Equipment Corporation">Mogul, J.</a>, <a href="" title="W3 Consortium">Frystyk, H.</a>, and <a href="" title="W3 Consortium">T. Berners-Lee</a>, &#8220;<a href="">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2068, January&nbsp;1997.</td></tr>  <tr><td class="reference"><b id="ISO-639">[ISO-639]</b></td><td class="top"><a href="">International Organization for Standardization</a>, &#8220;ISO 639:1988. Code for the representation of names of languages.&#8221;, 1988.</td></tr>  <tr><td class="reference"><b id="ISO-8601">[ISO-8601]</b></td><td class="top"><a href="">International Organization for Standardization</a>, &#8220;ISO 8601, Data elements and interchange formats-Information
+        interchange--Representation of dates and times&#8221;, June&nbsp;1988.</td></tr>  <tr><td class="reference"><b id="ISO-11578">[ISO-11578]</b></td><td class="top"><a href="">International Organization for Standardization</a>, &#8220;ISO/IEC 11578:1996. Information technology - Open
+        Systems Interconnection - Remote Procedure Call
+        (RPC)&#8221;, 1996.</td></tr>  <tr><td class="reference"><b id="RFC2141">[RFC2141]</b></td><td class="top"><a href="" title="AT&amp;T">Moats, R.</a>, &#8220;<a href="">URN Syntax</a>&#8221;, RFC&nbsp;2141, May&nbsp;1997.</td></tr>  <tr><td class="reference"><b id="UTF-8">[UTF-8]</b></td><td class="top"><a href="" title="Alis Technologies">Yergeau, F.</a>, &#8220;<a href="">UTF-8, a transformation format of ISO 10646</a>&#8221;, RFC&nbsp;2279, January&nbsp;1998.</td></tr> </tbody></table><h2 id="rfc.references.2"><a href="#rfc.section.21.2" id="rfc.section.21.2">21.2</a> Informational References</h2><table summary="Informational References"> <tbody><tr><td class="reference"><b id="RFC2026">[RFC2026]</b></td><td class="top"><a href="" title="Harvard University">Bradner, S.</a>, &#8220;<a href="">The Internet Standards Process -- Revision 3</a>&#8221;, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.</td></tr>  <tr><td class="reference"><b id="RFC1807">[RFC1807]</b></td><td class="top"><a href="" title="Stanford University">Lasher, R.</a> and <a href="" title="Myricom">D. Cohen</a>, &#8220;<a href="">A Format for Bibliographic Records</a>&#8221;, RFC&nbsp;1807, June&nbsp;1995.</td></tr>  <tr><td class="reference"><b id="WF">[WF]</b></td><td class="top"><a href="" title="Digital Library Research Group, Cornell University">Lagoze, C.</a>, &#8220;<a href="">The Warwick Framework: A Container Architecture for Diverse Sets of Metadata</a>&#8221;, July&nbsp;1996, &lt;<a href=""></a>&gt;.<br>D-Lib Magazine, July/August 1996.</td></tr>  <tr><td class="reference"><b id="USMARC">[USMARC]</b></td><td class="top">Network Development and MARC Standards, Office, Washington DC:
+          Cataloging Distribution Service, Library of Congress., &#8220;USMARC Format for Bibliographic Data&#8221;, 1994.</td></tr>  <tr><td class="reference"><b id="REC-PICS">[REC-PICS]</b></td><td class="top"><a href="" title="World Wide Web Consortium">Miller, J.</a>, <a href="">Krauskopf, T.</a>, <a href="">Resnick, P.</a>, and <a href="">W. Treese</a>, &#8220;<a href="">PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1</a>&#8221;, W3C&nbsp;REC-PICS-labels-961031, October&nbsp;1996, &lt;<a href=""></a>&gt;.</td></tr>  <tr><td class="reference"><b id="RFC2291">[RFC2291]</b></td><td class="top"><a href="" title="Xerox Corporation">Slein, J.</a>, <a href="" title="University of Bologna">Vitali, F.</a>, <a href="" title="University of California">Whitehead, E.J.</a>, and <a href="" title="Boston University">D.G. Durand</a>, &#8220;<a href="">Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</a>&#8221;, RFC&nbsp;2291, February&nbsp;1998.</td></tr>  <tr><td class="reference"><b id="RFC2413">[RFC2413]</b></td><td class="top"><a href="" title="OCLC Online Computer Library Center, Inc., Office of Research">Weibel, S.L.</a>, <a href="" title="University of California, San Francisco, Center for Knowledge Management">Kunze, J.A.</a>, <a href="" title="Cornell University, University Library and Department of Computer Science">Lagoze, C.</a>, and <a href="" title="Reuters Limited">M. Wolf</a>, &#8220;<a href="">Dublin Core Metadata for Resource Discovery</a>&#8221;, RFC&nbsp;2413, September&nbsp;1998.</td></tr>  <tr><td class="reference"><b id="RFC2376">[RFC2376]</b></td><td class="top"><a href="" title="Dept. of Information and Computer Science">Whitehead, E.J.</a> and <a href="" title="Fuji Xerox Information Systems">M. Makoto</a>, &#8220;<a href="">XML Media Types</a>&#8221;, RFC&nbsp;2376, July&nbsp;1998.</td></tr> </tbody></table><h1 id="rfc.authors"><a href="#rfc.section.22" id="rfc.section.22">22.</a> <a href="#rfc.authors">Authors' Addresses</a></h1><address class="vcard"><span class="vcardline"><span class="fn">Y. Y. Goland</span><span class="n hidden"><span class="family-name">Goland</span><span class="given-name">Y. Y.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">One Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052-6399</span></span></span><span class="vcardline">EMail: <a href=""><span class="email"></span></a></span></address><address class="vcard"><span class="vcardline"><span class="fn">E. J. Whitehead, Jr.</span><span class="n hidden"><span class="family-name">Whitehead</span></span></span><span class="org vcardline">Dept. Of Information and Computer Science,
+      University of California, Irvine</span><span class="adr"><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">92697-3425</span></span></span><span class="vcardline">EMail: <a href=""><span class="email"></span></a></span></address><address class="vcard"><span class="vcardline"><span class="fn">A. Faizi</span><span class="n hidden"><span class="family-name">Faizi</span><span class="given-name">A.</span></span></span><span class="org vcardline">Netscape</span><span class="adr"><span class="street-address vcardline">685 East Middlefield Road</span><span class="vcardline"><span class="locality">Mountain View</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94043</span></span></span><span class="vcardline">EMail: <a href=""><span class="email"></span></a></span></address><address class="vcard"><span class="vcardline"><span class="fn">S. R. Carter</span><span class="n hidden"><span class="family-name">Carter</span><span class="given-name">S. R.</span></span></span><span class="org vcardline">Novell</span><span class="adr"><span class="street-address vcardline">1555 N. Technology Way</span><span class="street-address vcardline">M/S ORM F111</span><span class="vcardline"><span class="locality">Orem</span>, <span class="region">UT</span>&nbsp;<span class="postal-code">84097-2399</span></span></span><span class="vcardline">EMail: <a href=""><span class="email"></span></a></span></address><address class="vcard"><span class="vcardline"><span class="fn">D. Jensen</span><span class="n hidden"><span class="family-name">Jensen</span><span class="given-name">D.</span></span></span><span class="org vcardline">Novell</span><span class="adr"><span class="street-address vcardline">1555 N. Technology Way</span><span class="street-address vcardline">M/S ORM F111</span><span class="vcardline"><span class="locality">Orem</span>, <span class="region">UT</span>&nbsp;<span class="postal-code">84097-2399</span></span></span><span class="vcardline">EMail: <a href=""><span class="email"></span></a></span></address><h1 id="rfc.section.23"><a href="#rfc.section.23">23.</a>&nbsp;Appendices</h1><h2 id="rfc.section.23.1"><a href="#rfc.section.23.1">23.1</a>&nbsp;Appendix 1 - WebDAV Document Type Definition</h2><p id="rfc.section.23.1.p.1">This section provides a document type definition, following the rules in <a href="#REC-XML" id="rfc.xref.REC-XML.9"><cite title="Extensible Markup Language (XML) 1.0">[REC-XML]</cite></a>,
+for the XML elements used in the protocol stream and in the values of
+properties. It collects the element definitions given in sections <a href="#xml.element.definitions" title="XML Element Definitions">12</a> and <a href="" title="DAV Properties">13</a>.</p><div id="rfc.figure.u.92"></div><pre class="inline">   &lt;!DOCTYPE webdav-1.0 [
+   &lt;!--============ XML Elements from <a href="#xml.element.definitions" title="XML Element Definitions">Section&nbsp;12</a> ==================--&gt;
+   &lt;!ELEMENT <a href="#ELEMENT_activelock">activelock</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>, <a href="#ELEMENT_depth">depth</a>, <a href="#ELEMENT_owner">owner</a>?, <a href="#ELEMENT_timeout">timeout</a>?,
+   <a href="#ELEMENT_locktoken">locktoken</a>?) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_lockentry">lockentry</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_lockinfo">lockinfo</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>, <a href="#ELEMENT_owner">owner</a>?) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_locktype">locktype</a> (<a href="#ELEMENT_write">write</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_write">write</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_lockscope">lockscope</a> (<a href="#ELEMENT_exclusive">exclusive</a> | <a href="#ELEMENT_shared">shared</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_exclusive">exclusive</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_shared">shared</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_depth">depth</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_owner">owner</a> ANY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_timeout">timeout</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_locktoken">locktoken</a> (<a href="#ELEMENT_href">href</a>+) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_href">href</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_link">link</a> (<a href="#ELEMENT_src">src</a>+, <a href="#ELEMENT_dst">dst</a>+) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_dst">dst</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_src">src</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_multistatus">multistatus</a> (<a href="#ELEMENT_response">response</a>+, <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_response">response</a> (<a href="#ELEMENT_href">href</a>, ((<a href="#ELEMENT_href">href</a>*, <a href="#ELEMENT_status">status</a>)|(<a href="#ELEMENT_propstat">propstat</a>+)),
+   <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_status">status</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_propstat">propstat</a> (<a href="#ELEMENT_prop">prop</a>, <a href="#ELEMENT_status">status</a>, <a href="#ELEMENT_responsedescription">responsedescription</a>?) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_responsedescription">responsedescription</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_prop">prop</a> ANY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_propertybehaviour">propertybehavior</a> (<a href="#ELEMENT_omit">omit</a> | <a href="#ELEMENT_keepalive">keepalive</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_omit">omit</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_keepalive">keepalive</a> (#PCDATA | <a href="#ELEMENT_href">href</a>+) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_propertyupdate">propertyupdate</a> (<a href="#ELEMENT_remove">remove</a> | <a href="#ELEMENT_set">set</a>)+ &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_remove">remove</a> (<a href="#ELEMENT_prop">prop</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_set">set</a> (<a href="#ELEMENT_prop">prop</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_propfind">propfind</a> (<a href="#ELEMENT_allprop">allprop</a> | <a href="#ELEMENT_propname">propname</a> | <a href="#ELEMENT_prop">prop</a>) &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_allprop">allprop</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_propname">propname</a> EMPTY &gt;
+   &lt;!ELEMENT <a href="#ELEMENT_collection">collection</a> EMPTY &gt;
+   &lt;!--=========== Property Elements from <a href="" title="DAV Properties">Section&nbsp;13</a> ===============--&gt;
+   &lt;!ELEMENT <a href="#PROPERTY_creationdate">creationdate</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_displayname">displayname</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_getcontentlanguage">getcontentlanguage</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_getcontentlength">getcontentlength</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_getcontenttype">getcontenttype</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_getetag">getetag</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_getlastmodified">getlastmodified</a> (#PCDATA) &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_lockdiscovery">lockdiscovery</a> (<a href="#ELEMENT_activelock">activelock</a>)* &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_resourcetype">resourcetype</a> ANY &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_source">source</a> (<a href="#ELEMENT_link">link</a>)* &gt;
+   &lt;!ELEMENT <a href="#PROPERTY_supportedlock">supportedlock</a> (<a href="#ELEMENT_lockentry">lockentry</a>)* &gt;
+   ]&gt;
+</pre><h2 id="rfc.section.23.2"><a href="#rfc.section.23.2">23.2</a>&nbsp;<a id="" href="">Appendix 2 - ISO 8601 Date and Time Profile</a></h2><p id="rfc.section.23.2.p.1">The creationdate property specifies the use of the ISO 8601 date format <a href="#ISO-8601" id="rfc.xref.ISO-8601.1"><cite title="ISO 8601, Data elements and interchange formats-Information interchange--Representation of dates and times">[ISO-8601]</cite></a>.
+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.</p><div id="rfc.figure.u.93"></div><pre class="inline">   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]
+</pre><p id="rfc.section.23.2.p.3">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.</p><p id="rfc.section.23.2.p.4">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.</p><h2 id="rfc.section.23.3"><a href="#rfc.section.23.3">23.3</a>&nbsp;Appendix 3 - Notes on Processing XML Elements</h2><h3 id="rfc.section.23.3.1"><a href="#rfc.section.23.3.1">23.3.1</a>&nbsp;Notes on Empty XML Elements</h3><p id="rfc.section.23.3.1.p.1">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
+&lt;A&gt;&lt;/A&gt;. The second is to declare an XML element of the
+form &lt;A/&gt;. The two XML elements are semantically identical.</p><p id="rfc.section.23.3.1.p.2">It
+is a violation of the XML specification to use the &lt;A&gt;&lt;/A&gt;
+form if the associated DTD declares the element to be EMPTY (e.g.,
+&lt;!ELEMENT A EMPTY&gt;). If such a statement is included, then the
+empty element format, &lt;A/&gt; must be used. If the element is not
+declared to be EMPTY, then either form &lt;A&gt;&lt;/A&gt; or
+&lt;A/&gt; may be used for empty elements.</p><h3 id="rfc.section.23.3.2"><a href="#rfc.section.23.3.2">23.3.2</a>&nbsp;Notes on Illegal XML Processing</h3><p id="rfc.section.23.3.2.p.1">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.</p><p id="rfc.section.23.3.2.p.2">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.</p><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;Example - XML Syntax Error</h4><p id="rfc.section.">The following request body for a PROPFIND method is illegal.</p><div id="rfc.figure.u.94"></div><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"&gt;
+     &lt;D:allprop/&gt;
+     &lt;D:propname/&gt;
+   &lt;/D:propfind&gt;
+</pre><p id="rfc.section.">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).</p><p id="rfc.section.">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.</p><p id="rfc.section.">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.</p><h4 id="rfc.section."><a href="#rfc.section."></a>&nbsp;Example - Unknown XML Element</h4><p id="rfc.section.">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.</p><div id="rfc.figure.u.95"></div><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"
+   xmlns:E=""&gt;
+     &lt;E:expired-props/&gt;
+   &lt;/D:propfind&gt;
+</pre><p id="rfc.section.">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.</p><div id="rfc.figure.u.96"></div><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"
+               xmlns:E=""&gt;
+   &lt;/D:propfind&gt;
+</pre><p id="rfc.section.">As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in <a href="" title="Instructions for Processing XML in DAV">Section&nbsp;14</a>, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal.</p><p id="rfc.section.">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:</p><div id="rfc.figure.u.97"></div><pre class="text">   &lt;?xml version="1.0" encoding="utf-8" ?&gt;
+   &lt;D:propfind xmlns:D="DAV:"
+               xmlns:E=""&gt;
+     &lt;D:propname/&gt;
+     &lt;E:leave-out&gt;*boss*&lt;/E:leave-out&gt;
+   &lt;/D:propfind&gt;
+</pre><p id="rfc.section.">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.</p><h2 id="rfc.section.23.4"><a href="#rfc.section.23.4">23.4</a>&nbsp;<a id="xml.namespaces.for.webdav" href="#xml.namespaces.for.webdav">Appendix 4 -- XML Namespaces for WebDAV</a></h2><h3 id="rfc.section.23.4.1"><a href="#rfc.section.23.4.1">23.4.1</a>&nbsp;Introduction</h3><p id="rfc.section.23.4.1.p.1">All DAV compliant systems <em class="bcp14">MUST</em> support the XML namespace extensions as specified in <a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.1"><cite title="Namespaces in XML">[REC-XML-NAMES]</cite></a>.</p><h3 id="rfc.section.23.4.2"><a href="#rfc.section.23.4.2">23.4.2</a>&nbsp;Meaning of Qualified Names</h3><p id="rfc.section.23.4.2.p.1">[Note to the reader: This section does not appear in <a href="#REC-XML-NAMES" id="rfc.xref.REC-XML-NAMES.2"><cite title="Namespaces in XML">[REC-XML-NAMES]</cite></a>, but is necessary to avoid ambiguity for WebDAV XML processors.]</p><p id="rfc.section.23.4.2.p.2">WebDAV compliant XML processors <em class="bcp14">MUST</em> interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI.</p><div id="rfc.figure.u.98"></div><p>Example</p><pre class="text">   &lt;del:glider xmlns:del=""&gt;
+     &lt;del:glidername&gt;
+          Johnny Updraft
+     &lt;/del:glidername&gt;
+     &lt;del:glideraccidents/&gt;
+   &lt;/del:glider&gt;
+</pre><p id="rfc.section.23.4.2.p.4">In this example, the qualified element name "del:glider" is interpreted as the URL "".</p><div id="rfc.figure.u.99"></div><pre class="text">   &lt;bar:glider xmlns:del=""&gt;
+     &lt;bar:glidername&gt;
+          Johnny Updraft
+     &lt;/bar:glidername&gt;
+     &lt;bar:glideraccidents/&gt;
+   &lt;/bar:glider&gt;
+</pre><p id="rfc.section.23.4.2.p.6">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
+"" 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.</p><div id="rfc.figure.u.100"></div><pre class="text">   &lt;foo:r xmlns:foo=""&gt;
+     &lt;foo:rname&gt;
+          Johnny Updraft
+     &lt;/foo:rname&gt;
+     &lt;foo:raccidents/&gt;
+   &lt;/foo:r&gt;
+</pre><p id="rfc.section.23.4.2.p.8">This example is semantically
+identical to the two previous ones. Each instance of the namespace name
+"foo" is replaced with "" which is then
+appended to the local name for each element tag, the resulting tag
+names are identical to those in the previous examples.</p><h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1><p>Copyright  The Internet Society (1999). All Rights Reserved.</p><p>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.</p><p>The limited
+permissions granted above are perpetual and will not be revoked by the
+Internet Society or its successors or assignees.</p><p>This document
+and the information contained herein is provided on an &#8220;;AS IS&#8221; basis
+FITNESS FOR A PARTICULAR PURPOSE.</p><h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1><p>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 of the 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.</p><p>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.</p><h1>Acknowledgement</h1><p>Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).</p><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li class="indline0"><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul class="ind"><li class="indline1">102 Processing (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.41">9.7</a>, <a class="iref" href="#rfc.iref.44"><b>10.1</b></a></li></ul></li><li class="indline0"><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul class="ind"><li class="indline1">207 Multi-Status (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.45"><b>10.2</b></a>, <a class="iref" href="#rfc.iref.50">11</a></li></ul></li><li class="indline0"><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul class="ind"><li class="indline1">422 Unprocessable Entity (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.46"><b>10.3</b></a></li><li class="indline1">423 Locked (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.47"><b>10.4</b></a></li><li class="indline1">424 Failed Dependency (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.48"><b>10.5</b></a></li></ul></li><li class="indline0"><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul class="ind"><li class="indline1">507 Insufficient Storage (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.49"><b>10.6</b></a></li></ul></li><li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"><li class="indline1">activelock&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.1">12.1</a></li></ul></li><li class="indline1">allprop&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.2">12.14.1</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"><li class="indline1">Collection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">3</a></li><li class="indline1">COPY method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2"><b>8.8</b></a></li></ul></li><li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"><li class="indline1">DAV header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.3"><b>9.1</b></a><ul class="ind"><li class="indline1">compliance class '1'&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.20"><b>15.1</b></a></li><li class="indline1">compliance class '2'&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.21"><b>15.2</b></a></li></ul></li><li class="indline1">DAV:collection resource type&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.7"><b>12.2</b></a></li><li class="indline1">DAV:creationdate property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.9"><b>13.1</b></a></li><li class="indline1">DAV:displayname property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.10"><b>13.2</b></a></li><li class="indline1">DAV:getcontentlanguage property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.11"><b>13.3</b></a></li><li class="indline1">DAV:getcontentlength property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.12"><b>13.4</b></a></li><li class="indline1">DAV:getcontenttype property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.13"><b>13.5</b></a></li><li class="indline1">DAV:getetag property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.14"><b>13.6</b></a></li><li class="indline1">DAV:getlastmodified property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.15"><b>13.7</b></a></li><li class="indline1">DAV:lockdiscovery property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.16"><b>13.8</b></a></li><li class="indline1">DAV:resourcetype property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.17"><b>13.9</b></a></li><li class="indline1">DAV:source property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.18"><b>13.10</b></a></li><li class="indline1">DAV:supportedlock property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.19"><b>13.11</b></a></li><li class="indline1">Dead Property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">3</a></li><li class="indline1">DELETE method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2"><b>8.6</b></a></li><li class="indline1">depth&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.6">12.1.1</a></li></ul></li><li class="indline1">Depth header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.4"><b>9.2</b></a></li><li class="indline1">Destination header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.5"><b>9.3</b></a></li><li class="indline1">dst&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.8">12.4.1</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"><li class="indline1">exclusive&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1">12.7.1</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind"><li class="indline1">Headers&nbsp;&nbsp;<ul class="ind"><li class="indline1">DAV&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>9.1</b></a></li><li class="indline1">Depth&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2"><b>9.2</b></a></li><li class="indline1">Destination&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.3"><b>9.3</b></a></li><li class="indline1">If&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.4"><b>9.4</b></a></li><li class="indline1">Lock-Token&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.5"><b>9.5</b></a></li><li class="indline1">Overwrite&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.6"><b>9.6</b></a></li><li class="indline1">Status-URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.7"><b>9.7</b></a></li><li class="indline1">Timeout&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.8"><b>9.8</b></a></li></ul></li><li class="indline1">href&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.9">12.3</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"><li class="indline1">If header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>9.4</b></a></li><li class="indline1">Internal Member URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">3</a></li><li class="indline1"><em>ISO-11578</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-11578.1">6.4</a>, <a class="iref" href="#rfc.xref.ISO-11578.2">6.4</a>, <a class="iref" href="#rfc.xref.ISO-11578.3">6.4.1</a>, <a class="iref" href="#rfc.xref.ISO-11578.4">17.8</a>, <a class="iref" href="#ISO-11578"><b>21.1</b></a></li><li class="indline1"><em>ISO-639</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-639.1">16</a>, <a class="iref" href="#ISO-639"><b>21.1</b></a></li><li class="indline1"><em>ISO-8601</em>&nbsp;&nbsp;<a class="iref" href="#ISO-8601"><b>21.1</b></a>, <a class="iref" href="#rfc.xref.ISO-8601.1">23.2</a></li></ul></li><li class="indline0"><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul class="ind"><li class="indline1">keepalive&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.k.1">12.12.1</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind"><li class="indline1">link&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.5">12.4</a></li></ul></li><li class="indline1">Live Property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.1">3</a></li><li class="indline1">LOCK method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.2"><b>8.10</b></a></li><li class="indline1">Lock-Token header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.3"><b>9.5</b></a></li><li class="indline1">lockentry&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.6">12.5</a></li></ul></li><li class="indline1">lockinfo&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.7">12.6</a></li></ul></li><li class="indline1">lockscope&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.8">12.7</a></li></ul></li><li class="indline1">locktoken&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.4">12.1.2</a></li></ul></li><li class="indline1">locktype&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.9">12.8</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind"><li class="indline1">Member URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1">3</a></li><li class="indline1">Methods&nbsp;&nbsp;<ul class="ind"><li class="indline1">COPY&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.8"><b>8.8</b></a></li><li class="indline1">DELETE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.6"><b>8.6</b></a></li><li class="indline1">LOCK&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.11"><b>8.10</b></a></li><li class="indline1">MKCOL&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.5"><b>8.3</b></a></li><li class="indline1">MOVE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.10"><b>8.9</b></a></li><li class="indline1">PROPFIND&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.2"><b>8.1</b></a></li><li class="indline1">PROPPATCH&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>8.2</b></a></li><li class="indline1">PUT&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.7"><b>8.7</b></a></li><li class="indline1">UNLOCK&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.12"><b>8.11</b></a></li></ul></li><li class="indline1">MKCOL method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.4"><b>8.3</b></a></li><li class="indline1">MOVE method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.9"><b>8.9</b></a></li><li class="indline1">multistatus&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.13">12.9</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul class="ind"><li class="indline1">Null Resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.1">3</a></li></ul></li><li class="indline0"><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul class="ind"><li class="indline1">omit&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.3">12.12.2</a></li></ul></li><li class="indline1">Overwrite header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>9.6</b></a></li><li class="indline1">owner&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.2">12.10</a></li></ul></li></ul></li><li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"><li class="indline1">prop&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.6">12.11</a></li></ul></li><li class="indline1">Properties&nbsp;&nbsp;<ul class="ind"><li class="indline1">DAV:creationdate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.11"><b>13.1</b></a></li><li class="indline1">DAV:displayname&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.12"><b>13.2</b></a></li><li class="indline1">DAV:getcontentlanguage&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.13"><b>13.3</b></a></li><li class="indline1">DAV:getcontentlength&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.14"><b>13.4</b></a></li><li class="indline1">DAV:getcontenttype&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.15"><b>13.5</b></a></li><li class="indline1">DAV:getetag&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.16"><b>13.6</b></a></li><li class="indline1">DAV:getlastmodified&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.17"><b>13.7</b></a></li><li class="indline1">DAV:lockdiscovery&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.18"><b>13.8</b></a></li><li class="indline1">DAV:resourcetype&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.19"><b>13.9</b></a></li><li class="indline1">DAV:source&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.20"><b>13.10</b></a></li><li class="indline1">DAV:supportedlock&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.21"><b>13.11</b></a></li></ul></li><li class="indline1">Property&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">3</a></li><li class="indline1">propertybehaviour&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.7">12.12</a></li></ul></li><li class="indline1">propertyupdate&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.8">12.13</a></li></ul></li><li class="indline1">propfind&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.9">12.14</a></li></ul></li><li class="indline1">PROPFIND method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>8.1</b></a></li><li class="indline1">propname&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.10">12.14.2</a></li></ul></li><li class="indline1">PROPPATCH method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.3"><b>8.2</b></a></li><li class="indline1">propstat&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.5"></a></li></ul></li><li class="indline1">PUT method&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.4"><b>8.7</b></a></li></ul></li><li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"><li class="indline1"><em>REC-PICS</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.REC-PICS.1">4.2</a>, <a class="iref" href="#REC-PICS"><b>21.2</b></a></li><li class="indline1"><em>REC-XML</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.REC-XML.1">1</a>, <a class="iref" href="#rfc.xref.REC-XML.2">8</a>, <a class="iref" href="#rfc.xref.REC-XML.3">12</a>, <a class="iref" href="#rfc.xref.REC-XML.4">13</a>, <a class="iref" href="#rfc.xref.REC-XML.5">17.7</a>, <a class="iref" href="#rfc.xref.REC-XML.6">17.7</a>, <a class="iref" href="#rfc.xref.REC-XML.7">17.7</a>, <a class="iref" href="#rfc.xref.REC-XML.8">17.7</a>, <a class="iref" href="#REC-XML"><b>21.1</b></a>, <a class="iref" href="#rfc.xref.REC-XML.9">23.1</a><ul class="ind"><li class="indline1"><em>Section 4.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.REC-XML.5">17.7</a></li></ul></li><li class="indline1"><em>REC-XML-NAMES</em>&nbsp;&nbsp;<a class="iref" href="#REC-XML-NAMES"><b>21.1</b></a>, <a class="iref" href="#rfc.xref.REC-XML-NAMES.1">23.4.1</a>, <a class="iref" href="#rfc.xref.REC-XML-NAMES.2">23.4.2</a></li><li class="indline1">remove&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.4">12.13.1</a></li></ul></li><li class="indline1">Resource Types&nbsp;&nbsp;<ul class="ind"><li class="indline1">DAV:collection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1"><b>12.2</b></a></li></ul></li><li class="indline1">response&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">12.9.1</a></li></ul></li><li class="indline1">responsedescription&nbsp;&nbsp;<ul class="ind"><li class="indline1">XML element&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">12.9.2</a></li></ul></li><li class="indline1"><em>RFC1766</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1766.1">16</a>, <a class="iref" href="#RFC1766"><b>21.1</b></a></li><li class="indline1"><em>RFC1807</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1807.1">4.2</a>, <a class="iref" href="#RFC1807"><b>21.2</b></a></li><li class="indline1"><em>RFC2026</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2026.1">19</a>, <a class="iref" href="#rfc.xref.RFC2026.2">19</a>, <a class="iref" href="#RFC2026"><b>21.2</b></a><ul class="ind"><li class="indline1"><em>Section 10.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2026.2">19</a></li></ul></li><li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">2</a>, <a class="iref" href="#rfc.xref.RFC2068.2">2</a>, <a class="iref" href="#rfc.xref.RFC2068.3">2</a>, <a class="iref" href="#rfc.xref.RFC2068.4">2</a>, <a class="iref" href="#rfc.xref.RFC2068.5">5.1</a>, <a class="iref" href="#rfc.xref.RFC2068.6">6.4</a>, <a class="iref" href="#rfc.xref.RFC2068.7">6.4</a>, <a class="iref" href="#rfc.xref.RFC2068.8">8.4</a>, <a class="iref" href="#rfc.xref.RFC2068.9">8.7.2</a>, <a class="iref" href="#rfc.xref.RFC2068.10">9.4</a>, <a class="iref" href="#rfc.xref.RFC2068.11">9.4</a>, <a class="iref" href="#rfc.xref.RFC2068.12">9.7</a>, <a class="iref" href="#rfc.xref.RFC2068.13">9.7</a>, <a class="iref" href="#rfc.xref.RFC2068.14">9.8</a>, <a class="iref" href="#rfc.xref.RFC2068.15">9.8</a>, <a class="iref" href="#rfc.xref.RFC2068.16">10</a>, <a class="iref" href="#rfc.xref.RFC2068.17">12.3</a>, <a class="iref" href="#rfc.xref.RFC2068.18">12.3</a>, <a class="iref" href="#rfc.xref.RFC2068.19"></a>, <a class="iref" href="#rfc.xref.RFC2068.20">13.3</a>, <a class="iref" href="#rfc.xref.RFC2068.21">13.3</a>, <a class="iref" href="#rfc.xref.RFC2068.22">13.4</a>, <a class="iref" href="#rfc.xref.RFC2068.23">13.4</a>, <a class="iref" href="#rfc.xref.RFC2068.24">13.5</a>, <a class="iref" href="#rfc.xref.RFC2068.25">13.5</a>, <a class="iref" href="#rfc.xref.RFC2068.26">13.6</a>, <a class="iref" href="#rfc.xref.RFC2068.27">13.6</a>, <a class="iref" href="#rfc.xref.RFC2068.28">13.7</a>, <a class="iref" href="#rfc.xref.RFC2068.29">13.7</a>, <a class="iref" href="#rfc.xref.RFC2068.30">15</a>, <a