@@ 0,0 1,2629 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html lang="en"><head profile="http://www.w3.org/2006/03/hcard">
+
+
+ <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;
+}
+h1.np {
+ 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;
+}
+table.tt {
+ vertical-align: top;
+}
+table.full {
+ border-style: outset;
+ border-width: 1px;
+}
+table.headers {
+ border-style: outset;
+ border-width: 1px;
+}
+table.tt td {
+ vertical-align: top;
+}
+table.full td {
+ border-style: inset;
+ border-width: 1px;
+}
+table.tt 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;
+}
+td.top {
+ 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;
+}
+.center {
+ 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="http://www.ietf.org/rfc/rfc2518.txt"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.341, 2007/07/21 13:59:39, XSLT vendor: SAXON 6.5.3 from Michael Kay http://saxon.sf.net/"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><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 “Internet
+Official Protocol Standards” (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. <a href="#rfc.section.1">Introduction</a></li><li class="tocline0">2. <a href="#rfc.section.2">Notational Conventions</a></li><li class="tocline0">3. <a href="#rfc.section.3">Terminology</a></li><li class="tocline0">4. <a href="#data.model.for.resource.properties">Data Model for Resource Properties</a><ul class="toc"><li class="tocline1">4.1 <a href="#rfc.section.4.1">The Resource Property Model</a></li><li class="tocline1">4.2 <a href="#rfc.section.4.2">Existing Metadata Proposals</a></li><li class="tocline1">4.3 <a href="#rfc.section.4.3">Properties and HTTP Headers</a></li><li class="tocline1">4.4 <a href="#rfc.section.4.4">Property Values</a></li><li class="tocline1">4.5 <a href="#rfc.section.4.5">Property Names</a></li><li class="tocline1">4.6 <a href="#rfc.section.4.6">Media Independent Links</a></li></ul></li><li class="tocline0">5. <a href="#collections.of.web.resources">Collections of Web Resources</a><ul class="toc"><li class="tocline1">5.1 <a href="#http.url.namespace.model">HTTP URL Namespace Model</a></li><li class="tocline1">5.2 <a href="#collection.resources">Collection Resources</a></li><li class="tocline1">5.3 <a href="#rfc.section.5.3">Creation and Retrieval of Collection Resources</a></li><li class="tocline1">5.4 <a href="#rfc.section.5.4">Source Resources and Output Resources</a></li></ul></li><li class="tocline0">6. <a href="#locking">Locking</a><ul class="toc"><li class="tocline1">6.1 <a href="#rfc.section.6.1">Exclusive Vs. Shared Locks</a></li><li class="tocline1">6.2 <a href="#rfc.section.6.2">Required Support</a></li><li class="tocline1">6.3 <a href="#rfc.section.6.3">Lock Tokens</a></li><li class="tocline1">6.4 <a href="#opaquelocktoken.lock.token.uri.scheme">opaquelocktoken Lock Token URI Scheme</a><ul class="toc"><li class="tocline1">6.4.1 <a href="#node.field.generation.without.the.ieee.802.address">Node Field Generation Without the IEEE 802 Address</a></li></ul></li><li class="tocline1">6.5 <a href="#rfc.section.6.5">Lock Capability Discovery</a></li><li class="tocline1">6.6 <a href="#rfc.section.6.6">Active Lock Discovery</a></li><li class="tocline1">6.7 <a href="#rfc.section.6.7">Usage Considerations</a></li></ul></li><li class="tocline0">7. <a href="#rfc.section.7">Write Lock</a><ul class="toc"><li class="tocline1">7.1 <a href="#rfc.section.7.1">Methods Restricted by Write Locks</a></li><li class="tocline1">7.2 <a href="#rfc.section.7.2">Write Locks and Lock Tokens</a></li><li class="tocline1">7.3 <a href="#rfc.section.7.3">Write Locks and Properties</a></li><li class="tocline1">7.4 <a href="#rfc.section.7.4">Write Locks and Null Resources</a></li><li class="tocline1">7.5 <a href="#write.locks.and.collections">Write Locks and Collections</a></li><li class="tocline1">7.6 <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 <a href="#rfc.section.7.6.1">Example - Write Lock</a></li></ul></li><li class="tocline1">7.7 <a href="#rfc.section.7.7">Write Locks and COPY/MOVE</a></li><li class="tocline1">7.8 <a href="#rfc.section.7.8">Refreshing Write Locks</a></li></ul></li><li class="tocline0">8. <a href="#http.methods.for.distributed.authoring">HTTP Methods for Distributed Authoring</a><ul class="toc"><li class="tocline1">8.1 <a href="#METHOD_PROPFIND">PROPFIND</a><ul class="toc"><li class="tocline1">8.1.1 <a href="#rfc.section.8.1.1">Example - Retrieving Named Properties</a></li><li class="tocline1">8.1.2 <a href="#rfc.section.8.1.2">Example - Using allprop to Retrieve All Properties</a></li><li class="tocline1">8.1.3 <a href="#rfc.section.8.1.3">Example - Using propname to Retrieve all Property Names</a></li></ul></li><li class="tocline1">8.2 <a href="#METHOD_PROPPATCH">PROPPATCH</a><ul class="toc"><li class="tocline1">8.2.1 <a href="#rfc.section.8.2.1">Status Codes for use with 207 (Multi-Status)</a></li><li class="tocline1">8.2.2 <a href="#rfc.section.8.2.2">Example - PROPPATCH</a></li></ul></li><li class="tocline1">8.3 <a href="#METHOD_MKCOL">MKCOL Method</a><ul class="toc"><li class="tocline1">8.3.1 <a href="#rfc.section.8.3.1">Request</a></li><li class="tocline1">8.3.2 <a href="#rfc.section.8.3.2">Status Codes</a></li><li class="tocline1">8.3.3 <a href="#rfc.section.8.3.3">Example - MKCOL</a></li></ul></li><li class="tocline1">8.4 <a href="#rfc.section.8.4">GET, HEAD for Collections</a></li><li class="tocline1">8.5 <a href="#rfc.section.8.5">POST for Collections</a></li><li class="tocline1">8.6 <a href="#METHOD_DELETE">DELETE</a><ul class="toc"><li class="tocline1">8.6.1 <a href="#rfc.section.8.6.1">DELETE for Non-Collection Resources</a></li><li class="tocline1">8.6.2 <a href="#rfc.section.8.6.2">DELETE for Collections</a><ul class="toc"><li class="tocline1">8.6.2.1 <a href="#rfc.section.8.6.2.1">Example - DELETE</a></li></ul></li></ul></li><li class="tocline1">8.7 <a href="#METHOD_PUT">PUT</a><ul class="toc"><li class="tocline1">8.7.1 <a href="#rfc.section.8.7.1">PUT for Non-Collection Resources</a></li><li class="tocline1">8.7.2 <a href="#rfc.section.8.7.2">PUT for Collections</a></li></ul></li><li class="tocline1">8.8 <a href="#METHOD_COPY">COPY Method</a><ul class="toc"><li class="tocline1">8.8.1 <a href="#rfc.section.8.8.1">COPY for HTTP/1.1 resources</a></li><li class="tocline1">8.8.2 <a href="#copy.for.properties">COPY for Properties</a></li><li class="tocline1">8.8.3 <a href="#copy.for.collections">COPY for Collections</a></li><li class="tocline1">8.8.4 <a href="#rfc.section.8.8.4">COPY and the Overwrite Header</a></li><li class="tocline1">8.8.5 <a href="#rfc.section.8.8.5">Status Codes</a></li><li class="tocline1">8.8.6 <a href="#rfc.section.8.8.6">Example - COPY with Overwrite</a></li><li class="tocline1">8.8.7 <a href="#rfc.section.8.8.7">Example - COPY with No Overwrite</a></li><li class="tocline1">8.8.8 <a href="#rfc.section.8.8.8">Example - COPY of a Collection</a></li></ul></li><li class="tocline1">8.9 <a href="#METHOD_MOVE">MOVE Method</a><ul class="toc"><li class="tocline1">8.9.1 <a href="#rfc.section.8.9.1">MOVE for Properties</a></li><li class="tocline1">8.9.2 <a href="#rfc.section.8.9.2">MOVE for Collections</a></li><li class="tocline1">8.9.3 <a href="#rfc.section.8.9.3">MOVE and the Overwrite Header</a></li><li class="tocline1">8.9.4 <a href="#rfc.section.8.9.4">Status Codes</a></li><li class="tocline1">8.9.5 <a href="#rfc.section.8.9.5">Example - MOVE of a Non-Collection</a></li><li class="tocline1">8.9.6 <a href="#rfc.section.8.9.6">Example - MOVE of a Collection</a></li></ul></li><li class="tocline1">8.10 <a href="#METHOD_LOCK">LOCK Method</a><ul class="toc"><li class="tocline1">8.10.1 <a href="#rfc.section.8.10.1">Operation</a></li><li class="tocline1">8.10.2 <a href="#rfc.section.8.10.2">The Effect of Locks on Properties and Collections</a></li><li class="tocline1">8.10.3 <a href="#rfc.section.8.10.3">Locking Replicated Resources</a></li><li class="tocline1">8.10.4 <a href="#rfc.section.8.10.4">Depth and Locking</a></li><li class="tocline1">8.10.5 <a href="#rfc.section.8.10.5">Interaction with other Methods</a></li><li class="tocline1">8.10.6 <a href="#rfc.section.8.10.6">Lock Compatibility Table</a></li><li class="tocline1">8.10.7 <a href="#rfc.section.8.10.7">Status Codes</a></li><li class="tocline1">8.10.8 <a href="#rfc.section.8.10.8">Example - Simple Lock Request</a></li><li class="tocline1">8.10.9 <a href="#rfc.section.8.10.9">Example - Refreshing a Write Lock</a></li><li class="tocline1">8.10.10 <a href="#rfc.section.8.10.10">Example - Multi-Resource Lock Request</a></li></ul></li><li class="tocline1">8.11 <a href="#METHOD_UNLOCK">UNLOCK Method</a><ul class="toc"><li class="tocline1">8.11.1 <a href="#rfc.section.8.11.1">Example - UNLOCK</a></li></ul></li></ul></li><li class="tocline0">9. <a href="#http.headers.for.distributed.authoring">HTTP Headers for Distributed Authoring</a><ul class="toc"><li class="tocline1">9.1 <a href="#HEADER_DAV">DAV Header</a></li><li class="tocline1">9.2 <a href="#HEADER_Depth">Depth Header</a></li><li class="tocline1">9.3 <a href="#HEADER_Destination">Destination Header</a></li><li class="tocline1">9.4 <a href="#HEADER_If">If Header</a><ul class="toc"><li class="tocline1">9.4.1 <a href="#rfc.section.9.4.1">No-tag-list Production</a><ul class="toc"><li class="tocline1">9.4.1.1 <a href="#rfc.section.9.4.1.1">Example - No-tag-list If Header</a></li></ul></li><li class="tocline1">9.4.2 <a href="#rfc.section.9.4.2">Tagged-list Production</a><ul class="toc"><li class="tocline1">9.4.2.1 <a href="#rfc.section.9.4.2.1">Example - Tagged List If header</a></li></ul></li><li class="tocline1">9.4.3 <a href="#rfc.section.9.4.3">not Production</a></li><li class="tocline1">9.4.4 <a href="#rfc.section.9.4.4">Matching Function</a></li><li class="tocline1">9.4.5 <a href="#rfc.section.9.4.5">If Header and Non-DAV Compliant Proxies</a></li></ul></li><li class="tocline1">9.5 <a href="#HEADER_Lock-Token">Lock-Token Header</a></li><li class="tocline1">9.6 <a href="#HEADER_Overwrite">Overwrite Header</a></li><li class="tocline1">9.7 <a href="#HEADER_Status-URI">Status-URI Response Header</a></li><li class="tocline1">9.8 <a href="#HEADER_Timeout">Timeout Request Header</a></li></ul></li><li class="tocline0">10. <a href="#status.code.extensions.to.http11">Status Code Extensions to HTTP/1.1</a><ul class="toc"><li class="tocline1">10.1 <a href="#STATUS_102">102 Processing</a></li><li class="tocline1">10.2 <a href="#STATUS_207">207 Multi-Status</a></li><li class="tocline1">10.3 <a href="#STATUS_422">422 Unprocessable Entity</a></li><li class="tocline1">10.4 <a href="#STATUS_423">423 Locked</a></li><li class="tocline1">10.5 <a href="#STATUS_424">424 Failed Dependency</a></li><li class="tocline1">10.6 <a href="#STATUS_507">507 Insufficient Storage</a></li></ul></li><li class="tocline0">11. <a href="#multi-status.response">Multi-Status Response</a></li><li class="tocline0">12. <a href="#xml.element.definitions">XML Element Definitions</a><ul class="toc"><li class="tocline1">12.1 <a href="#ELEMENT_activelock">activelock XML Element</a><ul class="toc"><li class="tocline1">12.1.1 <a href="#ELEMENT_depth">depth XML Element</a></li><li class="tocline1">12.1.2 <a href="#ELEMENT_locktoken">locktoken XML Element</a></li><li class="tocline1">12.1.3 <a href="#ELEMENT_timeout">timeout XML Element</a></li></ul></li><li class="tocline1">12.2 <a href="#ELEMENT_collection">collection XML Element</a></li><li class="tocline1">12.3 <a href="#ELEMENT_href">href XML Element</a></li><li class="tocline1">12.4 <a href="#ELEMENT_link">link XML Element</a><ul class="toc"><li class="tocline1">12.4.1 <a href="#ELEMENT_dst">dst XML Element</a></li><li class="tocline1">12.4.2 <a href="#ELEMENT_src">src XML Element</a></li></ul></li><li class="tocline1">12.5 <a href="#ELEMENT_lockentry">lockentry XML Element</a></li><li class="tocline1">12.6 <a href="#ELEMENT_lockinfo">lockinfo XML Element</a></li><li class="tocline1">12.7 <a href="#ELEMENT_lockscope">lockscope XML Element</a><ul class="toc"><li class="tocline1">12.7.1 <a href="#ELEMENT_exclusive">exclusive XML Element</a></li><li class="tocline1">12.7.2 <a href="#ELEMENT_shared">shared XML Element</a></li></ul></li><li class="tocline1">12.8 <a href="#ELEMENT_locktype">locktype XML Element</a><ul class="toc"><li class="tocline1">12.8.1 <a href="#ELEMENT_write">write XML Element</a></li></ul></li><li class="tocline1">12.9 <a href="#ELEMENT_multistatus">multistatus XML Element</a><ul class="toc"><li class="tocline1">12.9.1 <a href="#ELEMENT_response">response XML Element</a><ul class="toc"><li class="tocline1">12.9.1.1 <a href="#ELEMENT_propstat">propstat XML Element</a></li><li class="tocline1">12.9.1.2 <a href="#ELEMENT_status">status XML Element</a></li></ul></li><li class="tocline1">12.9.2 <a href="#ELEMENT_responsedescription">responsedescription XML Element</a></li></ul></li><li class="tocline1">12.10 <a href="#ELEMENT_owner">owner XML Element</a></li><li class="tocline1">12.11 <a href="#ELEMENT_prop">prop XML element</a></li><li class="tocline1">12.12 <a href="#ELEMENT_propertybehaviour">propertybehavior XML element</a><ul class="toc"><li class="tocline1">12.12.1 <a href="#ELEMENT_keepalive">keepalive XML element</a></li><li class="tocline1">12.12.2 <a href="#ELEMENT_omit">omit XML element</a></li></ul></li><li class="tocline1">12.13 <a href="#ELEMENT_propertyupdate">propertyupdate XML element</a><ul class="toc"><li class="tocline1">12.13.1 <a href="#ELEMENT_remove">remove XML element</a></li><li class="tocline1">12.13.2 <a href="#ELEMENT_set">set XML element</a></li></ul></li><li class="tocline1">12.14 <a href="#ELEMENT_propfind">propfind XML Element</a><ul class="toc"><li class="tocline1">12.14.1 <a href="#ELEMENT_allprop">allprop XML Element</a></li><li class="tocline1">12.14.2 <a href="#ELEMENT_propname">propname XML Element</a></li></ul></li></ul></li><li class="tocline0">13. <a href="#dav.properties">DAV Properties</a><ul class="toc"><li class="tocline1">13.1 <a href="#PROPERTY_creationdate">creationdate Property</a></li><li class="tocline1">13.2 <a href="#PROPERTY_displayname">displayname Property</a></li><li class="tocline1">13.3 <a href="#PROPERTY_getcontentlanguage">getcontentlanguage Property</a></li><li class="tocline1">13.4 <a href="#PROPERTY_getcontentlength">getcontentlength Property</a></li><li class="tocline1">13.5 <a href="#PROPERTY_getcontenttype">getcontenttype Property</a></li><li class="tocline1">13.6 <a href="#PROPERTY_getetag">getetag Property</a></li><li class="tocline1">13.7 <a href="#PROPERTY_getlastmodified">getlastmodified Property</a></li><li class="tocline1">13.8 <a href="#PROPERTY_lockdiscovery">lockdiscovery Property</a><ul class="toc"><li class="tocline1">13.8.1 <a href="#rfc.section.13.8.1">Example - Retrieving the lockdiscovery Property</a></li></ul></li><li class="tocline1">13.9 <a href="#PROPERTY_resourcetype">resourcetype Property</a></li><li class="tocline1">13.10 <a href="#PROPERTY_source">source Property</a><ul class="toc"><li class="tocline1">13.10.1 <a href="#rfc.section.13.10.1">Example - A source Property</a></li></ul></li><li class="tocline1">13.11 <a href="#PROPERTY_supportedlock">supportedlock Property</a><ul class="toc"><li class="tocline1">13.11.1 <a href="#rfc.section.13.11.1">Example - Retrieving the supportedlock Property</a></li></ul></li></ul></li><li class="tocline0">14. <a href="#instructions.for.processing.xml.in.dav">Instructions for Processing XML in DAV</a></li><li class="tocline0">15. <a href="#dav.compliance.classes">DAV Compliance Classes</a><ul class="toc"><li class="tocline1">15.1 <a href="#rfc.section.15.1">Class 1</a></li><li class="tocline1">15.2 <a href="#rfc.section.15.2">Class 2</a></li></ul></li><li class="tocline0">16. <a href="#internationalization.considerations">Internationalization Considerations</a></li><li class="tocline0">17. <a href="#security.considerations">Security Considerations</a><ul class="toc"><li class="tocline1">17.1 <a href="#rfc.section.17.1">Authentication of Clients</a></li><li class="tocline1">17.2 <a href="#rfc.section.17.2">Denial of Service</a></li><li class="tocline1">17.3 <a href="#rfc.section.17.3">Security through Obscurity</a></li><li class="tocline1">17.4 <a href="#rfc.section.17.4">Privacy Issues Connected to Locks</a></li><li class="tocline1">17.5 <a href="#rfc.section.17.5">Privacy Issues Connected to Properties</a></li><li class="tocline1">17.6 <a href="#rfc.section.17.6">Reduction of Security due to Source Link</a></li><li class="tocline1">17.7 <a href="#rfc.section.17.7">Implications of XML External Entities</a></li><li class="tocline1">17.8 <a href="#risks.connected.with.lock.tokens">Risks Connected with Lock Tokens</a></li></ul></li><li class="tocline0">18. <a href="#rfc.section.18">IANA Considerations</a></li><li class="tocline0">19. <a href="#rfc.section.19">Intellectual Property</a></li><li class="tocline0">20. <a href="#rfc.section.20">Acknowledgements</a></li><li class="tocline0">21. <a href="#rfc.references">References</a><ul class="toc"><li class="tocline1">21.1 <a href="#rfc.references.1">Normative References</a></li><li class="tocline1">21.2 <a href="#rfc.references.2">Informational References</a></li></ul></li><li class="tocline0">22. <a href="#rfc.authors">Authors' Addresses</a></li><li class="tocline0">23. <a href="#rfc.section.23">Appendices</a><ul class="toc"><li class="tocline1">23.1 <a href="#rfc.section.23.1">Appendix 1 - WebDAV Document Type Definition</a></li><li class="tocline1">23.2 <a href="#iso.8601.date.and.time.profile">Appendix 2 - ISO 8601 Date and Time Profile</a></li><li class="tocline1">23.3 <a href="#rfc.section.23.3">Appendix 3 - Notes on Processing XML Elements</a><ul class="toc"><li class="tocline1">23.3.1 <a href="#rfc.section.23.3.1">Notes on Empty XML Elements</a></li><li class="tocline1">23.3.2 <a href="#rfc.section.23.3.2">Notes on Illegal XML Processing</a><ul class="toc"><li class="tocline1">23.3.2.1 <a href="#rfc.section.23.3.2.1">Example - XML Syntax Error</a></li><li class="tocline1">23.3.2.2 <a href="#rfc.section.23.3.2.2">Example - Unknown XML Element</a></li></ul></li></ul></li><li class="tocline1">23.4 <a href="#xml.namespaces.for.webdav">Appendix 4 -- XML Namespaces for WebDAV</a><ul class="toc"><li class="tocline1">23.4.1 <a href="#rfc.section.23.4.1">Introduction</a></li><li class="tocline1">23.4.2 <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> 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="#data.model.for.resource.properties" title="Data Model for Resource Properties">Section 4</a>), collections of resources (<a href="#collections.of.web.resources" title="Collections of Web Resources">Section 5</a>), and locking operations (<a href="#locking" title="Locking">Section 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 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 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 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 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="#status.code.extensions.to.http11" title="Status Code Extensions to HTTP/1.1">Section 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 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="#dav.properties" title="DAV Properties">Section 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 15</a>), on internationalization support (<a href="#internationalization.considerations" title="Internationalization Considerations">Section 16</a>), and on security (<a href="#security.considerations" title="Security Considerations">Section 17</a>).</p><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> 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="http://tools.ietf.org/html/rfc2068#section-2.1" 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="http://tools.ietf.org/html/rfc2068#section-2.2" 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",
+"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+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> 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 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 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> <a id="data.model.for.resource.properties" href="#data.model.for.resource.properties">Data Model for Resource Properties</a></h1><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> 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> 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> 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> 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> 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> 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 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> <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> <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> <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="http://tools.ietf.org/html/rfc2396#section-3.3" 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 http://foo.com/bar/blah is WebDAV compliant and if
+the resource with URL http://foo.com/bar/ is WebDAV compliant then the
+resource with URL http://foo.com/bar/ must be a collection and must
+contain URL http://foo.com/bar/blah as an internal member.</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 http://foo.com/bar/blah is not
+WebDAV compliant and the URL http://foo.com/bar/ identifies a
+collection then URL http://foo.com/bar/blah may or may not be an
+internal member of the collection with URL http://foo.com/bar/.</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
+http://foo.bar/blah (no trailing slash), the resource
+http://foo.bar/blah/ (trailing slash) may respond as if the operation
+were invoked on it, and should return a content-location header with
+http://foo.bar/blah/ in it. In general clients <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> 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> 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
+http://www.foo.bar.org/finger_gateway/user@host.</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 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> <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> 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> 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> 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> <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="http://tools.ietf.org/html/rfc2068#section-3.2.1" 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> <a id="node.field.generation.without.the.ieee.802.address" href="#node.field.generation.without.the.ieee.802.address">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 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> 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> 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> 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> 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> 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,
+POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked
+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> 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> 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> 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> <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> <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> Example - Write Lock</h3><div id="rfc.figure.u.1"></div><p>>>Request</p> <pre class="text2"> COPY /~fielding/index.html HTTP/1.1
+ Host: www.ics.uci.edu
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html
+ If: <http://www.ics.uci.edu/users/f/fielding/index.html>
+ (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
+</pre><div id="rfc.figure.u.2"></div><p>>>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> 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 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 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> 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> <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> <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> Example - Retrieving Named Properties</h3><div id="rfc.figure.u.3"></div><p>>>Request</p> <pre class="text2"> PROPFIND /file HTTP/1.1
+ Host: www.foo.bar
+ Content-type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox/>
+ <R:author/>
+ <R:DingALing/>
+ <R:Random/>
+ </D:prop>
+ </D:propfind>
+</pre><div id="rfc.figure.u.4"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>http://www.foo.bar/file</D:href>
+ <D:propstat>
+ <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox>
+ <R:BoxType>Box type A</R:BoxType>
+ </R:bigbox>
+ <R:author>
+ <R:Name>J.J. Johnson</R:Name>
+ </R:author>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ <D:propstat>
+ <D:prop><R:DingALing/><R:Random/></D:prop>
+ <D:status>HTTP/1.1 403 Forbidden</D:status>
+ <D:responsedescription> The user does not have access to
+ the DingALing property.
+ </D:responsedescription>
+ </D:propstat>
+ </D:response>
+ <D:responsedescription> There has been an access violation error.
+ </D:responsedescription>
+ </D:multistatus>
+</pre><p id="rfc.section.8.1.1.p.3">In this example, PROPFIND is
+executed on a non-collection resource http://www.foo.bar/file. The
+propfind XML element specifies the name of four properties whose values
+are being requested. In this case only two properties were returned,
+since the principal issuing the request did not have sufficient access
+rights to see the third and fourth properties.</p><h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> Example - Using allprop to Retrieve All Properties</h3><div id="rfc.figure.u.5"></div><p>>>Request</p> <pre class="text2"> PROPFIND /container/ HTTP/1.1
+ Host: www.foo.bar
+ Depth: 1
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:allprop/>
+ </D:propfind>
+</pre><div id="rfc.figure.u.6"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>http://www.foo.bar/container/</D:href>
+ <D:propstat>
+ <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox>
+ <R:BoxType>Box type A</R:BoxType>
+ </R:bigbox>
+ <R:author>
+ <R:Name>Hadrian</R:Name>
+ </R:author>
+ <D:creationdate>
+ 1997-12-01T17:42:21-08:00
+ </D:creationdate>
+ <D:displayname>
+ Example collection
+ </D:displayname>
+ <D:resourcetype><D:collection/></D:resourcetype>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://www.foo.bar/container/front.html</D:href>
+ <D:propstat>
+ <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox>
+ <R:BoxType>Box type B</R:BoxType>
+ </R:bigbox>
+ <D:creationdate>
+ 1997-12-01T18:27:21-08:00
+ </D:creationdate>
+ <D:displayname>
+ Example HTML resource
+ </D:displayname>
+ <D:getcontentlength>
+ 4525
+ </D:getcontentlength>
+ <D:getcontenttype>
+ text/html
+ </D:getcontenttype>
+ <D:getetag>
+ zzyzx
+ </D:getetag>
+ <D:getlastmodified>
+ Monday, 12-Jan-98 09:25:56 GMT
+ </D:getlastmodified>
+ <D:resourcetype/>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+</pre><p id="rfc.section.8.1.2.p.3">In this example, PROPFIND was
+invoked on the resource http://www.foo.bar/container/ with a Depth
+header of 1, meaning the request applies to the resource and its
+children, and a propfind XML element containing the allprop XML
+element, meaning the request should return the name and value of all
+properties defined on each resource.</p><p id="rfc.section.8.1.2.p.4">The resource http://www.foo.bar/container/ has six properties defined on it:</p><p id="rfc.section.8.1.2.p.5">http://www.foo.bar/boxschema/bigbox,
+http://www.foo.bar/boxschema/author, 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="#dav.properties" title="DAV Properties">Section 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 http://www.foo.bar/container/front.html has nine properties defined on it:</p><p id="rfc.section.8.1.2.p.8">http://www.foo.bar/boxschema/bigbox
+(another instance of the "bigbox" property type), DAV:creationdate,
+DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.</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> Example - Using propname to Retrieve all Property Names</h3><div id="rfc.figure.u.7"></div><p>>>Request</p> <pre class="text2"> PROPFIND /container/ HTTP/1.1
+ Host: www.foo.bar
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <propfind xmlns="DAV:">
+ <propname/>
+ </propfind>
+</pre><div id="rfc.figure.u.8"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <multistatus xmlns="DAV:">
+ <response>
+ <href>http://www.foo.bar/container/</href>
+ <propstat>
+ <prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox/>
+ <R:author/>
+ <creationdate/>
+ <displayname/>
+ <resourcetype/>
+ <supportedlock/>
+ </prop>
+ <status>HTTP/1.1 200 OK</status>
+ </propstat>
+ </response>
+ <response>
+ <href>http://www.foo.bar/container/front.html</href>
+ <propstat>
+ <prop xmlns:R="http://www.foo.bar/boxschema/">
+ <R:bigbox/>
+ <creationdate/>
+ <displayname/>
+ <getcontentlength/>
+ <getcontenttype/>
+ <getetag/>
+ <getlastmodified/>
+ <resourcetype/>
+ <supportedlock/>
+ </prop>
+ <status>HTTP/1.1 200 OK</status>
+ </propstat>
+ </response>
+ </multistatus>
+</pre><p id="rfc.section.8.1.3.p.3">In this example, PROPFIND is
+invoked on the collection resource http://www.foo.bar/container/, with
+a propfind XML element containing the propname XML element, meaning the
+name of all properties should be returned. Since no Depth header is
+present, it assumes its default value of "infinity", meaning the name
+of the properties on the collection and all its progeny should be
+returned.</p><p id="rfc.section.8.1.3.p.4">Consistent with the previous
+example, resource http://www.foo.bar/container/ has six properties
+defined on it, http://www.foo.bar/boxschema/bigbox,
+http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname,
+DAV:resourcetype, and DAV:supportedlock.</p><p id="rfc.section.8.1.3.p.5">The
+resource http://www.foo.bar/container/index.html, a member of the
+"container" collection, has nine properties defined on it,
+http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname,
+DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.</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> <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 12.13</a>.</p><h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> 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> Example - PROPPATCH</h3><div id="rfc.figure.u.9"></div><p>>>Request</p> <pre class="text2"> PROPPATCH /bar.html HTTP/1.1
+ Host: www.foo.com
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propertyupdate xmlns:D="DAV:"
+ xmlns:Z="http://www.w3.com/standards/z39.50/">
+ <D:set>
+ <D:prop>
+ <Z:authors>
+ <Z:Author>Jim Whitehead</Z:Author>
+ <Z:Author>Roy Fielding</Z:Author>
+ </Z:authors>
+ </D:prop>
+ </D:set>
+ <D:remove>
+ <D:prop><Z:Copyright-Owner/></D:prop>
+ </D:remove>
+ </D:propertyupdate>
+</pre><div id="rfc.figure.u.10"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:Z="http://www.w3.com/standards/z39.50">
+ <D:response>
+ <D:href>http://www.foo.com/bar.html</D:href>
+ <D:propstat>
+ <D:prop><Z:Authors/></D:prop>
+ <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+ </D:propstat>
+ <D:propstat>
+ <D:prop><Z:Copyright-Owner/></D:prop>
+ <D:status>HTTP/1.1 409 Conflict</D:status>
+ </D:propstat>
+ <D:responsedescription> Copyright Owner can not be deleted or
+ altered.</D:responsedescription>
+ </D:response>
+ </D:multistatus>
+</pre><p id="rfc.section.8.2.2.p.3">In this example, the client
+requests the server to set the value of the
+http://www.w3.com/standards/z39.50/Authors property, and to remove the
+property http://www.w3.com/standards/z39.50/Copyright-Owner. Since the
+Copyright-Owner property could not be removed, no property
+modifications occur. The 424 (Failed Dependency) status code for the
+Authors property indicates this action would have succeeded if it were
+not for the conflict with removing the Copyright-Owner property.</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> <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> 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> 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> Example - MKCOL</h3><p id="rfc.section.8.3.3.p.1">This example creates a collection called /webdisc/xfiles/ on the server www.server.org.</p><div id="rfc.figure.u.11"></div><p>>>Request</p> <pre class="text2"> MKCOL /webdisc/xfiles/ HTTP/1.1
+ Host: www.server.org
+</pre><div id="rfc.figure.u.12"></div><p>>>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> 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> 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> <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> 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> 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.8.6.2.1"><a href="#rfc.section.8.6.2.1">8.6.2.1</a> Example - DELETE</h4><div id="rfc.figure.u.13"></div><p>>>Request</p> <pre class="text2"> DELETE /container/ HTTP/1.1
+ Host: www.foo.bar
+</pre><div id="rfc.figure.u.14"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <d:multistatus xmlns:d="DAV:">
+ <d:response>
+ <d:href>http://www.foo.bar/container/resource3</d:href>
+ <d:status>HTTP/1.1 423 Locked</d:status>
+ </d:response>
+ </d:multistatus>
+</pre><p id="rfc.section.8.6.2.1.p.3">In this example the attempt to
+delete http://www.foo.bar/container/resource3 failed because it is
+locked, and no lock token was submitted with the request. Consequently,
+the attempt to delete http://www.foo.bar/container/ also failed. Thus
+the client knows that the attempt to delete
+http://www.foo.bar/container/ must have also failed since the parent
+can not be deleted unless its child has also been deleted. Even though
+a Depth header has not been included, a depth of infinity is assumed
+because the method is on a collection.</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> <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> 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> 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> <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> 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> <a id="copy.for.properties" href="#copy.for.properties">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 12.12</a>.</p><h3 id="rfc.section.8.8.3"><a href="#rfc.section.8.8.3">8.8.3</a> <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 http://fun.com/ and the Destination is
+http://fun.com/b/ then when http://fun.com/a/c/d is processed it must
+use a Destination of http://fun.com/b/c/d.</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 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> 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> 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> Example - COPY with Overwrite</h3><p id="rfc.section.8.8.6.p.1">This
+example shows resource http://www.ics.uci.edu/~fielding/index.html
+being copied to the location
+http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No
+Content) status code indicates the existing resource at the destination
+was overwritten.</p><div id="rfc.figure.u.15"></div><p>>>Request</p> <pre class="text2"> COPY /~fielding/index.html HTTP/1.1
+ Host: www.ics.uci.edu
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html
+</pre><div id="rfc.figure.u.16"></div><p>>>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> 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>>>Request</p> <pre class="text2"> COPY /~fielding/index.html HTTP/1.1
+ Host: www.ics.uci.edu
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html
+ Overwrite: F
+</pre><div id="rfc.figure.u.18"></div><p>>>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> Example - COPY of a Collection</h3><div id="rfc.figure.u.19"></div><p>>>Request</p> <pre class="text2"> COPY /container/ HTTP/1.1
+ Host: www.foo.bar
+ Destination: http://www.foo.bar/othercontainer/
+ Depth: infinity
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <d:propertybehavior xmlns:d="DAV:">
+ <d:keepalive>*</d:keepalive>
+ </d:propertybehavior>
+</pre><div id="rfc.figure.u.20"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <d:multistatus xmlns:d="DAV:">
+ <d:response>
+ <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
+ <d:status>HTTP/1.1 412 Precondition Failed</d:status>
+ </d:response>
+ </d:multistatus>
+</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 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> <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> 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="#copy.for.properties" title="COPY for Properties">Section 8.8.2</a>.</p><h3 id="rfc.section.8.9.2"><a href="#rfc.section.8.9.2">8.9.2</a> 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> 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> 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> Example - MOVE of a Non-Collection</h3><p id="rfc.section.8.9.5.p.1">This
+example shows resource http://www.ics.uci.edu/~fielding/index.html
+being moved to the location
+http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the
+destination resource would have been overwritten if the destination
+resource had been non-null. In this case, since there was nothing at
+the destination resource, the response code is 201 (Created).</p><div id="rfc.figure.u.21"></div><p>>>Request</p> <pre class="text2"> MOVE /~fielding/index.html HTTP/1.1
+ Host: www.ics.uci.edu
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html
+</pre><div id="rfc.figure.u.22"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 201 Created
+ Location: http://www.ics.uci.edu/users/f/fielding/index.html
+</pre><h3 id="rfc.section.8.9.6"><a href="#rfc.section.8.9.6">8.9.6</a> Example - MOVE of a Collection</h3><div id="rfc.figure.u.23"></div><p>>>Request</p> <pre class="text2"> MOVE /container/ HTTP/1.1
+ Host: www.foo.bar
+ Destination: http://www.foo.bar/othercontainer/
+ Overwrite: F
+ If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
+ (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <d:propertybehavior xmlns:d='DAV:'>
+ <d:keepalive>*</d:keepalive>
+ </d:propertybehavior>
+</pre><div id="rfc.figure.u.24"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <d:multistatus xmlns:d='DAV:'>
+ <d:response>
+ <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
+ <d:status>HTTP/1.1 423 Locked</d:status>
+ </d:response>
+ </d:multistatus>
+</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
+http://www.foo.bar/othercontainer/C2/. This means that the resource
+/container/C2/ could not be moved. Because there was an error copying
+/container/C2/, none of /container/C2's members were copied. However no
+errors were listed for those members due to the error minimization
+rules given in <a href="#copy.for.collections" title="COPY for Collections">Section 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> <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> 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> 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> 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> 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> 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> 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> 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> Example - Simple Lock Request</h3><div id="rfc.figure.u.25"></div><p>>>Request</p> <pre class="text2"> LOCK /workspace/webdav/proposal.doc HTTP/1.1
+ Host: webdav.sb.aol.com
+ Timeout: Infinite, Second-4100000000
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+ Authorization: Digest username="ejw",
+ realm="ejw@webdav.sb.aol.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:lockinfo xmlns:D='DAV:'>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ <D:owner>
+ <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
+ </D:owner>
+ </D:lockinfo>
+</pre><div id="rfc.figure.u.26"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 200 OK
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:prop xmlns:D="DAV:">
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>Infinity</D:depth>
+ <D:owner>
+ <D:href>
+ http://www.ics.uci.edu/~ejw/contact.html
+ </D:href>
+ </D:owner>
+ <D:timeout>Second-604800</D:timeout>
+ <D:locktoken>
+ <D:href>
+ opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+ </D:href>
+ </D:locktoken>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+</pre><p id="rfc.section.8.10.8.p.3">This example shows the successful
+creation of an exclusive write lock on resource
+http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource
+http://www.ics.uci.edu/~ejw/contact.html contains contact information
+for the owner of the lock. The server has an activity-based timeout
+policy in place on this resource, which causes the lock to
+automatically be removed after 1 week (604800 seconds). Note that the
+nonce, response, and opaque fields have not been calculated in the
+Authorization request header.</p><h3 id="rfc.section.8.10.9"><a href="#rfc.section.8.10.9">8.10.9</a> Example - Refreshing a Write Lock</h3><div id="rfc.figure.u.27"></div><p>>>Request</p> <pre class="text2"> LOCK /workspace/webdav/proposal.doc HTTP/1.1
+ Host: webdav.sb.aol.com
+ Timeout: Infinite, Second-4100000000
+ If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
+ Authorization: Digest username="ejw",
+ realm="ejw@webdav.sb.aol.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+</pre><div id="rfc.figure.u.28"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 200 OK
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:prop xmlns:D="DAV:">
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>Infinity</D:depth>
+ <D:owner>
+ <D:href>
+ http://www.ics.uci.edu/~ejw/contact.html
+ </D:href>
+ </D:owner>
+ <D:timeout>Second-604800</D:timeout>
+ <D:locktoken>
+ <D:href>
+ opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+ </D:href>
+ </D:locktoken>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+</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> Example - Multi-Resource Lock Request</h3><div id="rfc.figure.u.29"></div><p>>>Request</p> <pre class="text2"> LOCK /webdav/ HTTP/1.1
+ Host: webdav.sb.aol.com
+ Timeout: Infinite, Second-4100000000
+ Depth: infinity
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+ Authorization: Digest username="ejw",
+ realm="ejw@webdav.sb.aol.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:lockinfo xmlns:D="DAV:">
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:owner>
+ <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
+ </D:owner>
+ </D:lockinfo>
+</pre><div id="rfc.figure.u.30"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
+ <D:status>HTTP/1.1 403 Forbidden</D:status>
+ </D:response>
+ <D:response>
+ <D:href>http://webdav.sb.aol.com/webdav/</D:href>
+ <D:propstat>
+ <D:prop><D:lockdiscovery/></D:prop>
+ <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+</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
+http://webdav.sb.aol.com/webdav/secret. Because this resource could not
+be locked, none of the resources were locked. Note also that the
+lockdiscovery property for the Request-URI has been included as
+required. In this example the lockdiscovery property is empty which
+means that there are no outstanding locks on the resource.</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> <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> Example - UNLOCK</h3><div id="rfc.figure.u.31"></div><p>>>Request</p> <pre class="text2"> UNLOCK /workspace/webdav/info.doc HTTP/1.1
+ Host: webdav.sb.aol.com
+ Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
+ Authorization: Digest username="ejw",
+ realm="ejw@webdav.sb.aol.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+</pre><div id="rfc.figure.u.32"></div><p>>>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
+http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock
+included more than just one resource, the lock is removed from all
+resources included in the lock. The 204 (No Content) status code is
+used instead of 200 (OK) because there is no response entity body.</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> <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> <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 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> <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> <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> <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 = "<" absoluteURI ">"
+</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="http://tools.ietf.org/html/rfc2068#section-14.25" 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> 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.9.4.1.1"><a href="#rfc.section.9.4.1.1">9.4.1.1</a> Example - No-tag-list If Header</h4><div id="rfc.figure.u.37"></div><pre class="text"> If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
+ ETag"])
+</pre><p id="rfc.section.9.4.1.1.p.2">The previous header would require
+that any resources within the scope of the method must either be locked
+with the specified lock token and in the state identified by the "I am
+an ETag" ETag or in the state identified by the second ETag "I am
+another ETag". To put the matter more plainly one can think of the
+previous If header as being in the form (or (and
+<locktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am
+another ETag"])).</p><h3 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a> 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.9.4.2.1"><a href="#rfc.section.9.4.2.1">9.4.2.1</a> Example - Tagged List If header</h4><div id="rfc.figure.u.38"></div><pre class="text2"> COPY /resource1 HTTP/1.1
+ Host: www.foo.bar
+ Destination: http://www.foo.bar/resource2
+ If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
+ [W/"A weak ETag"]) (["strong ETag"])
+ <http://www.bar.bar/random>(["another strong ETag"])
+</pre><p id="rfc.section.9.4.2.1.p.2">In this example
+http://www.foo.bar/resource1 is being copied to
+http://www.foo.bar/resource2. When the method is first applied to
+http://www.foo.bar/resource1, resource1 must be in the state specified
+by "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong
+ETag"])", that is, it either must be locked with a lock token of
+"locktoken:a-write-lock-token" and have a weak entity tag W/"A weak
+ETag" or it must have a strong entity tag "strong ETag".</p><p id="rfc.section.9.4.2.1.p.3">That
+is the only success condition since the resource
+http://www.bar.bar/random never has the method applied to it (the only
+other resource listed in the If header) and
+http://www.foo.bar/resource2 is not listed in the If header.</p><h3 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a> 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 <locktoken:write1> <locktoken:write2>)
+</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> 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> 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> <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> <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> <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="http://tools.ietf.org/html/rfc2068#section-6.1.1" 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> <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="http://tools.ietf.org/html/rfc2068#section-4.2" 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> <a id="status.code.extensions.to.http11" href="#status.code.extensions.to.http11">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> <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> <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 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> <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> <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> <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> <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> <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> <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> <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"> <!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>?) >
+</pre><h3 id="rfc.section.12.1.1"><a href="#rfc.section.12.1.1">12.1.1</a> <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"> <!ELEMENT <a href="#ELEMENT_depth">depth</a> (#PCDATA) >
+</pre><h3 id="rfc.section.12.1.2"><a href="#rfc.section.12.1.2">12.1.2</a> <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 6.4</a>).</dd></dl><div id="rfc.figure.u.46"></div><pre class="inline"> <!ELEMENT <a href="#ELEMENT_locktoken">locktoken</a> (<a href="#ELEMENT_href">href</a>+) >
+</pre><h3 id="rfc.section.12.1.3"><a href="#rfc.section.12.1.3">12.1.3</a> <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 9.8</a></dd></dl><div id="rfc.figure.u.47"></div><pre class="inline"> <!ELEMENT <a href="#ELEMENT_timeout">timeout</a> (#PCDATA) >
+</pre><h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <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"> <!ELEMENT <a href="#ELEMENT_collection">collection</a> EMPTY >
+</pre><h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <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="http://tools.ietf.org/html/rfc2068#section-3.2.1" 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"> <!ELEMENT <a href="#ELEMENT_href">href</a> (#PCDATA)>
+</pre><h2 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a> <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"> <!ELEMENT <a href="#ELEMENT_link">link</a> (<a href="#ELEMENT_src">src</a>+, <a href="#ELEMENT_dst">dst</a>+) >
+</pre><h3 id="rfc.section.12.4.1"><a href="#rfc.section.12.4.1">12.4.1</a> <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"> <!ELEMENT <a href="#ELEMENT_dst">dst</a> (#PCDATA) >
+</pre><h3 id="rfc.section.12.4.2"><a href="#rfc.section.12.4.2">12.4.2</a> <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"> <!ELEMENT <a href="#ELEMENT_src">src</a> (#PCDATA) >
+</pre><h2 id="rfc.section.12.5"><a href="#rfc.section.12.5">12.5</a> <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"> <!ELEMENT <a href="#ELEMENT_lockentry">lockentry</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>) >
+</pre><h2 id="rfc.section.12.6"><a href="#rfc.section.12.6">12.6</a> <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"> <!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>?) >
+</pre><h2 id="rfc.section.12.7"><a href="#rfc.section.12.7">12.7</a> <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"> <!ELEMENT <a href="#ELEMENT_lockscope">lockscope</a> (<a href="#ELEMENT_exclusive">exclusive</a> | <a href="#ELEMENT_shared">shared</a>) >
+</pre><h3 id="rfc.section.12.7.1"><a href="#rfc.section.12.7.1">12.7.1</a> <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"> <!ELEMENT <a href="#ELEMENT_exclusive">exclusive</a> EMPTY >
+</pre><h3 id="rfc.section.12.7.2"><a href="#rfc.section.12.7.2">12.7.2</a> <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"> <!ELEMENT <a href="#ELEMENT_shared">shared</a> EMPTY >
+</pre><h2 id="rfc.section.12.8"><a href="#rfc.section.12.8">12.8</a> <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"> <!ELEMENT <a href="#ELEMENT_locktype">locktype</a> (<a href="#ELEMENT_write">write</a>) >
+</pre><h3 id="rfc.section.12.8.1"><a href="#rfc.section.12.8.1">12.8.1</a> <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"> <!ELEMENT <a href="#ELEMENT_write">write</a> EMPTY >
+</pre><h2 id="rfc.section.12.9"><a href="#rfc.section.12.9">12.9</a> <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"> <!ELEMENT <a href="#ELEMENT_multistatus">multistatus</a> (<a href="#ELEMENT_response">response</a>+, <a href="#ELEMENT_responsedescription">responsedescription</a>?) >
+</pre><h3 id="rfc.section.12.9.1"><a href="#rfc.section.12.9.1">12.9.1</a> <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"> <!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>?) >
+</pre><h4 id="rfc.section.12.9.1.1"><a href="#rfc.section.12.9.1.1">12.9.1.1</a> <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"> <!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>?) >
+</pre><h4 id="rfc.section.12.9.1.2"><a href="#rfc.section.12.9.1.2">12.9.1.2</a> <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"> <!ELEMENT <a href="#ELEMENT_status">status</a> (#PCDATA) >
+</pre><h3 id="rfc.section.12.9.2"><a href="#rfc.section.12.9.2">12.9.2</a> <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"> <!ELEMENT <a href="#ELEMENT_responsedescription">responsedescription</a> (#PCDATA) >
+</pre><h2 id="rfc.section.12.10"><a href="#rfc.section.12.10">12.10</a> <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"> <!ELEMENT <a href="#ELEMENT_owner">owner</a> ANY>
+</pre><h2 id="rfc.section.12.11"><a href="#rfc.section.12.11">12.11</a> <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"> <!ELEMENT <a href="#ELEMENT_prop">prop</a> ANY>
+</pre><h2 id="rfc.section.12.12"><a href="#rfc.section.12.12">12.12</a> <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"> <!ELEMENT <a href="#ELEMENT_propertybehaviour">propertybehavior</a> (<a href="#ELEMENT_omit">omit</a> | <a href="#ELEMENT_keepalive">keepalive</a>) >
+</pre><h3 id="rfc.section.12.12.1"><a href="#rfc.section.12.12.1">12.12.1</a> <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"> <!ELEMENT <a href="#ELEMENT_keepalive">keepalive</a> (#PCDATA | <a href="#ELEMENT_href">href</a>+) >
+</pre><h3 id="rfc.section.12.12.2"><a href="#rfc.section.12.12.2">12.12.2</a> <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"> <!ELEMENT <a href="#ELEMENT_omit">omit</a> EMPTY >
+</pre><h2 id="rfc.section.12.13"><a href="#rfc.section.12.13">12.13</a> <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"> <!ELEMENT <a href="#ELEMENT_propertyupdate">propertyupdate</a> (<a href="#ELEMENT_remove">remove</a> | <a href="#ELEMENT_set">set</a>)+ >
+</pre><h3 id="rfc.section.12.13.1"><a href="#rfc.section.12.13.1">12.13.1</a> <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"> <!ELEMENT <a href="#ELEMENT_remove">remove</a> (<a href="#ELEMENT_prop">prop</a>) >
+</pre><h3 id="rfc.section.12.13.2"><a href="#rfc.section.12.13.2">12.13.2</a> <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"> <!ELEMENT <a href="#ELEMENT_set">set</a> (<a href="#ELEMENT_prop">prop</a>) >
+</pre><h2 id="rfc.section.12.14"><a href="#rfc.section.12.14">12.14</a> <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"> <!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>) >
+</pre><h3 id="rfc.section.12.14.1"><a href="#rfc.section.12.14.1">12.14.1</a> <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"> <!ELEMENT <a href="#ELEMENT_allprop">allprop</a> EMPTY >
+</pre><h3 id="rfc.section.12.14.2"><a href="#rfc.section.12.14.2">12.14.2</a> <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"> <!ELEMENT <a href="#ELEMENT_propname">propname</a> EMPTY >
+</pre><h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="dav.properties" href="#dav.properties">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> <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="#iso.8601.date.and.time.profile" title="Appendix 2 - ISO 8601 Date and Time Profile">Appendix 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"> <!ELEMENT <a href="#PROPERTY_creationdate">creationdate</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.2"><a href="#rfc.section.13.2">13.2</a> <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"> <!ELEMENT <a href="#PROPERTY_displayname">displayname</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.3"><a href="#rfc.section.13.3">13.3</a> <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="http://tools.ietf.org/html/rfc2068#section-14.13" 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"> <!ELEMENT <a href="#PROPERTY_getcontentlanguage">getcontentlanguage</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.4"><a href="#rfc.section.13.4">13.4</a> <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="http://tools.ietf.org/html/rfc2068#section-14.14" 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"> <!ELEMENT <a href="#PROPERTY_getcontentlength">getcontentlength</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.5"><a href="#rfc.section.13.5">13.5</a> <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="http://tools.ietf.org/html/rfc2068#section-3.7" 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"> <!ELEMENT <a href="#PROPERTY_getcontenttype">getcontenttype</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.6"><a href="#rfc.section.13.6">13.6</a> <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="http://tools.ietf.org/html/rfc2068#section-3.11" 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"> <!ELEMENT <a href="#PROPERTY_getetag">getetag</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.7"><a href="#rfc.section.13.7">13.7</a> <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="http://tools.ietf.org/html/rfc2068#section-3.3.1" 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"> <!ELEMENT <a href="#PROPERTY_getlastmodified">getlastmodified</a> (#PCDATA) >
+</pre><h2 id="rfc.section.13.8"><a href="#rfc.section.13.8">13.8</a> <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"> <!ELEMENT <a href="#PROPERTY_lockdiscovery">lockdiscovery</a> (<a href="#ELEMENT_activelock">activelock</a>)* >
+</pre><h3 id="rfc.section.13.8.1"><a href="#rfc.section.13.8.1">13.8.1</a> Example - Retrieving the lockdiscovery Property</h3><div id="rfc.figure.u.84"></div><p>>>Request</p> <pre class="text2"> PROPFIND /container/ HTTP/1.1
+ Host: www.foo.bar
+ Content-Length: xxxx
+ Content-Type: text/xml; charset="utf-8"
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D='DAV:'>
+ <D:prop><D:lockdiscovery/></D:prop>
+ </D:propfind>
+</pre><div id="rfc.figure.u.85"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D='DAV:'>
+ <D:response>
+ <D:href>http://www.foo.bar/container/</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>0</D:depth>
+ <D:owner>Jane Smith</D:owner>
+ <D:timeout>Infinite</D:timeout>
+ <D:locktoken>
+ <D:href>
+ opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
+ </D:href>
+ </D:locktoken>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+</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> <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"> <!ELEMENT <a href="#PROPERTY_resourcetype">resourcetype</a> ANY >
+</pre><h2 id="rfc.section.13.10"><a href="#rfc.section.13.10">13.10</a> <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"> <!ELEMENT <a href="#PROPERTY_source">source</a> (<a href="#ELEMENT_link">link</a>)* >
+</pre><h3 id="rfc.section.13.10.1"><a href="#rfc.section.13.10.1">13.10.1</a> Example - A source Property</h3><div id="rfc.figure.u.88"></div><pre class="text"> <?xml version="1.0" encoding="utf-8" ?>
+ <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
+ <D:source>
+ <D:link>
+ <F:projfiles>Source</F:projfiles>
+ <D:src>http://foo.bar/program</D:src>
+ <D:dst>http://foo.bar/src/main.c</D:dst>
+ </D:link>
+ <D:link>
+ <F:projfiles>Library</F:projfiles>
+ <D:src>http://foo.bar/program</D:src>
+ <D:dst>http://foo.bar/src/main.lib</D:dst>
+ </D:link>
+ <D:link>
+ <F:projfiles>Makefile</F:projfiles>
+ <D:src>http://foo.bar/program</D:src>
+ <D:dst>http://foo.bar/src/makefile</D:dst>
+ </D:link>
+ </D:source>
+ </D:prop>
+</pre><p id="rfc.section.13.10.1.p.2">In this example the resource
+http://foo.bar/program has a source property that contains three links.
+Each link contains three elements, two of which, src and dst, are part
+of the DAV schema defined in this document, and one which is defined by
+the schema http://www.foocorp.com/project/ (Source, Library, and
+Makefile). A client which only implements the elements in the DAV spec
+will not understand the foocorp elements and will ignore them, thus
+seeing the expected source and destination links. An enhanced client
+may know about the foocorp elements and be able to present the user
+with additional information about the links. This example demonstrates
+the power of XML markup, allowing element values to be enhanced without
+breaking older clients.</p><h2 id="rfc.section.13.11"><a href="#rfc.section.13.11">13.11</a> <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"> <!ELEMENT <a href="#PROPERTY_supportedlock">supportedlock</a> (<a href="#ELEMENT_lockentry">lockentry</a>)* >
+</pre><h3 id="rfc.section.13.11.1"><a href="#rfc.section.13.11.1">13.11.1</a> Example - Retrieving the supportedlock Property</h3><div id="rfc.figure.u.90"></div><p>>>Request</p> <pre class="text2"> PROPFIND /container/ HTTP/1.1
+ Host: www.foo.bar
+ Content-Length: xxxx
+ Content-Type: text/xml; charset="utf-8"
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:prop><D:supportedlock/></D:prop>
+ </D:propfind>
+</pre><div id="rfc.figure.u.91"></div><p>>>Response</p> <pre class="text"> HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>http://www.foo.bar/container/</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+</pre><h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a id="instructions.for.processing.xml.in.dav" href="#instructions.for.processing.xml.in.dav">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> <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> 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> 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> <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> <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> 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> 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> 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> 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> 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> 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> 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="http://www.w3.org/TR/1998/REC-xml-19980210#sec-external-ent" 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> <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 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="#node.field.generation.without.the.ieee.802.address" title="Node Field Generation Without the IEEE 802 Address">Section 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> 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 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> 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="http://tools.ietf.org/html/rfc2026#section-10.4" 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> 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="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC 1766, March 1995.</td></tr> <tr><td class="reference"><b id="RFC2277">[RFC2277]</b></td><td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998.</td></tr> <tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997.</td></tr> <tr><td class="reference"><b id="RFC2396">[RFC2396]</b></td><td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998.</td></tr> <tr><td class="reference"><b id="REC-XML">[REC-XML]</b></td><td class="top"><a href="mailto:tbray@textuality.com" title="Textuality">Bray, T.</a>, <a href="mailto:jeanpa@microsoft.com" title="Microsoft">Paoli, J.</a>, and <a href="mailto:cmsmcq@uic.edu" title="University of Illinois at Chicago">C.M. Sperberg-McQueen</a>, “<a href="http://www.w3.org/TR/1998/REC-xml-19980210">Extensible Markup Language (XML) 1.0</a>”, W3C REC-xml-19980210, February 1998, <<a href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/1998/REC-xml-19980210</a>>.</td></tr> <tr><td class="reference"><b id="REC-XML-NAMES">[REC-XML-NAMES]</b></td><td class="top"><a href="mailto:tbray@textuality.com" title="Textuality">Bray, T.</a>, <a href="mailto:dmh@corp.hp.com" title="Hewlett-Packard Company">Hollander, D.</a>, and <a href="mailto:andrewl@microsoft.com" title="Microsoft">A. Layman</a>, “<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>”, W3C REC-xml-names-19990114, January 1999, <<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">http://www.w3.org/TR/1999/REC-xml-names-19990114</a>>.</td></tr> <tr><td class="reference"><b id="RFC2069">[RFC2069]</b></td><td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University">Franks, J.</a>, <a href="mailto:hallam@w3.org" title="CERN">Hallam-Baker, P.</a>, <a href="mailto:jeff@spyglass.com" title="Spyglass, Inc.">Hostetler, J.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:luotonen@netscape.com" title="Netscape Communications Corporation">Luotonen, A.</a>, <a href="mailto:eric@spyglass.com" title="Spyglass, Inc.">Sink, E.</a>, and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2069">An Extension to HTTP : Digest Access Authentication</a>”, RFC 2069, January 1997.</td></tr> <tr><td class="reference"><b id="RFC2068">[RFC2068]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="W3 Consortium">Frystyk, H.</a>, and <a href="mailto:timbl@w3.org" title="W3 Consortium">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997.</td></tr> <tr><td class="reference"><b id="ISO-639">[ISO-639]</b></td><td class="top"><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO 639:1988. Code for the representation of names of languages.”, 1988.</td></tr> <tr><td class="reference"><b id="ISO-8601">[ISO-8601]</b></td><td class="top"><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO 8601, Data elements and interchange formats-Information
+ interchange--Representation of dates and times”, June 1988.</td></tr> <tr><td class="reference"><b id="ISO-11578">[ISO-11578]</b></td><td class="top"><a href="http://www.iso.ch/">International Organization for Standardization</a>, “ISO/IEC 11578:1996. Information technology - Open
+ Systems Interconnection - Remote Procedure Call
+ (RPC)”, 1996.</td></tr> <tr><td class="reference"><b id="RFC2141">[RFC2141]</b></td><td class="top"><a href="mailto:jayhawk@ds.internic.net" title="AT&T">Moats, R.</a>, “<a href="http://tools.ietf.org/html/rfc2141">URN Syntax</a>”, RFC 2141, May 1997.</td></tr> <tr><td class="reference"><b id="UTF-8">[UTF-8]</b></td><td class="top"><a href="mailto:fyergeau@alis.com" title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC 2279, January 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="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996.</td></tr> <tr><td class="reference"><b id="RFC1807">[RFC1807]</b></td><td class="top"><a href="mailto:rlasher@forsythe.stanford.edu" title="Stanford University">Lasher, R.</a> and <a href="mailto:Cohen@myri.com" title="Myricom">D. Cohen</a>, “<a href="http://tools.ietf.org/html/rfc1807">A Format for Bibliographic Records</a>”, RFC 1807, June 1995.</td></tr> <tr><td class="reference"><b id="WF">[WF]</b></td><td class="top"><a href="mailto:lagoze@cs.cornell.edu" title="Digital Library Research Group, Cornell University">Lagoze, C.</a>, “<a href="http://www.dlib.org/dlib/july96/lagoze/07lagoze.html">The Warwick Framework: A Container Architecture for Diverse Sets of Metadata</a>”, July 1996, <<a href="http://www.dlib.org/dlib/july96/lagoze/07lagoze.html">http://www.dlib.org/dlib/july96/lagoze/07lagoze.html</a>>.<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., “USMARC Format for Bibliographic Data”, 1994.</td></tr> <tr><td class="reference"><b id="REC-PICS">[REC-PICS]</b></td><td class="top"><a href="mailto:jmiller@w3.org" title="World Wide Web Consortium">Miller, J.</a>, <a href="mailto:timk@spyglass.com">Krauskopf, T.</a>, <a href="mailto:presnick@research.att.com">Resnick, P.</a>, and <a href="mailto:treese@OpenMarket.com">W. Treese</a>, “<a href="http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html">PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1</a>”, W3C REC-PICS-labels-961031, October 1996, <<a href="http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html">http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html</a>>.</td></tr> <tr><td class="reference"><b id="RFC2291">[RFC2291]</b></td><td class="top"><a href="mailto:slein@wrc.xerox.com" title="Xerox Corporation">Slein, J.</a>, <a href="mailto:fabio@cs.unibo.it" title="University of Bologna">Vitali, F.</a>, <a href="mailto:ejw@ics.uci.edu" title="University of California">Whitehead, E.J.</a>, and <a href="mailto:dgd@cs.bu.edu" title="Boston University">D.G. Durand</a>, “<a href="http://tools.ietf.org/html/rfc2291">Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</a>”, RFC 2291, February 1998.</td></tr> <tr><td class="reference"><b id="RFC2413">[RFC2413]</b></td><td class="top"><a href="mailto:weibel@oclc.org" title="OCLC Online Computer Library Center, Inc., Office of Research">Weibel, S.L.</a>, <a href="mailto:jak@ckm.ucsf.edu" title="University of California, San Francisco, Center for Knowledge Management">Kunze, J.A.</a>, <a href="mailto:lagoze@cs.cornell.edu" title="Cornell University, University Library and Department of Computer Science">Lagoze, C.</a>, and <a href="mailto:misha.wolf@reuters.com" title="Reuters Limited">M. Wolf</a>, “<a href="http://tools.ietf.org/html/rfc2413">Dublin Core Metadata for Resource Discovery</a>”, RFC 2413, September 1998.</td></tr> <tr><td class="reference"><b id="RFC2376">[RFC2376]</b></td><td class="top"><a href="mailto:ejw@ics.uci.edu" title="Dept. of Information and Computer Science">Whitehead, E.J.</a> and <a href="mailto:murata@fxis.fujixerox.co.jp" title="Fuji Xerox Information Systems">M. Makoto</a>, “<a href="http://tools.ietf.org/html/rfc2376">XML Media Types</a>”, RFC 2376, July 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> <span class="postal-code">98052-6399</span></span></span><span class="vcardline">EMail: <a href="mailto:yarong@microsoft.com"><span class="email">yarong@microsoft.com</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> <span class="postal-code">92697-3425</span></span></span><span class="vcardline">EMail: <a href="mailto:ejw@ics.uci.edu"><span class="email">ejw@ics.uci.edu</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> <span class="postal-code">94043</span></span></span><span class="vcardline">EMail: <a href="mailto:asad@netscape.com"><span class="email">asad@netscape.com</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> <span class="postal-code">84097-2399</span></span></span><span class="vcardline">EMail: <a href="mailto:srcarter@novell.com"><span class="email">srcarter@novell.com</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> <span class="postal-code">84097-2399</span></span></span><span class="vcardline">EMail: <a href="mailto:dcjensen@novell.com"><span class="email">dcjensen@novell.com</span></a></span></address><h1 id="rfc.section.23"><a href="#rfc.section.23">23.</a> Appendices</h1><h2 id="rfc.section.23.1"><a href="#rfc.section.23.1">23.1</a> 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="#dav.properties" title="DAV Properties">13</a>.</p><div id="rfc.figure.u.92"></div><pre class="inline"> <!DOCTYPE webdav-1.0 [
+
+ <!--============ XML Elements from <a href="#xml.element.definitions" title="XML Element Definitions">Section 12</a> ==================-->
+
+ <!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>?) >
+
+ <!ELEMENT <a href="#ELEMENT_lockentry">lockentry</a> (<a href="#ELEMENT_lockscope">lockscope</a>, <a href="#ELEMENT_locktype">locktype</a>) >
+ <!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>?) >
+
+ <!ELEMENT <a href="#ELEMENT_locktype">locktype</a> (<a href="#ELEMENT_write">write</a>) >
+ <!ELEMENT <a href="#ELEMENT_write">write</a> EMPTY >
+
+ <!ELEMENT <a href="#ELEMENT_lockscope">lockscope</a> (<a href="#ELEMENT_exclusive">exclusive</a> | <a href="#ELEMENT_shared">shared</a>) >
+ <!ELEMENT <a href="#ELEMENT_exclusive">exclusive</a> EMPTY >
+ <!ELEMENT <a href="#ELEMENT_shared">shared</a> EMPTY >
+
+ <!ELEMENT <a href="#ELEMENT_depth">depth</a> (#PCDATA) >
+
+ <!ELEMENT <a href="#ELEMENT_owner">owner</a> ANY >
+
+ <!ELEMENT <a href="#ELEMENT_timeout">timeout</a> (#PCDATA) >
+
+ <!ELEMENT <a href="#ELEMENT_locktoken">locktoken</a> (<a href="#ELEMENT_href">href</a>+) >
+
+ <!ELEMENT <a href="#ELEMENT_href">href</a> (#PCDATA) >
+
+ <!ELEMENT <a href="#ELEMENT_link">link</a> (<a href="#ELEMENT_src">src</a>+, <a href="#ELEMENT_dst">dst</a>+) >
+ <!ELEMENT <a href="#ELEMENT_dst">dst</a> (#PCDATA) >
+ <!ELEMENT <a href="#ELEMENT_src">src</a> (#PCDATA) >
+
+ <!ELEMENT <a href="#ELEMENT_multistatus">multistatus</a> (<a href="#ELEMENT_response">response</a>+, <a href="#ELEMENT_responsedescription">responsedescription</a>?) >
+
+ <!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>?) >
+ <!ELEMENT <a href="#ELEMENT_status">status</a> (#PCDATA) >
+ <!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>?) >
+ <!ELEMENT <a href="#ELEMENT_responsedescription">responsedescription</a> (#PCDATA) >
+
+ <!ELEMENT <a href="#ELEMENT_prop">prop</a> ANY >
+
+ <!ELEMENT <a href="#ELEMENT_propertybehaviour">propertybehavior</a> (<a href="#ELEMENT_omit">omit</a> | <a href="#ELEMENT_keepalive">keepalive</a>) >
+ <!ELEMENT <a href="#ELEMENT_omit">omit</a> EMPTY >
+
+ <!ELEMENT <a href="#ELEMENT_keepalive">keepalive</a> (#PCDATA | <a href="#ELEMENT_href">href</a>+) >
+
+ <!ELEMENT <a href="#ELEMENT_propertyupdate">propertyupdate</a> (<a href="#ELEMENT_remove">remove</a> | <a href="#ELEMENT_set">set</a>)+ >
+ <!ELEMENT <a href="#ELEMENT_remove">remove</a> (<a href="#ELEMENT_prop">prop</a>) >
+ <!ELEMENT <a href="#ELEMENT_set">set</a> (<a href="#ELEMENT_prop">prop</a>) >
+
+ <!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>) >
+ <!ELEMENT <a href="#ELEMENT_allprop">allprop</a> EMPTY >
+ <!ELEMENT <a href="#ELEMENT_propname">propname</a> EMPTY >
+
+ <!ELEMENT <a href="#ELEMENT_collection">collection</a> EMPTY >
+
+ <!--=========== Property Elements from <a href="#dav.properties" title="DAV Properties">Section 13</a> ===============-->
+ <!ELEMENT <a href="#PROPERTY_creationdate">creationdate</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_displayname">displayname</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_getcontentlanguage">getcontentlanguage</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_getcontentlength">getcontentlength</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_getcontenttype">getcontenttype</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_getetag">getetag</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_getlastmodified">getlastmodified</a> (#PCDATA) >
+ <!ELEMENT <a href="#PROPERTY_lockdiscovery">lockdiscovery</a> (<a href="#ELEMENT_activelock">activelock</a>)* >
+ <!ELEMENT <a href="#PROPERTY_resourcetype">resourcetype</a> ANY >
+ <!ELEMENT <a href="#PROPERTY_source">source</a> (<a href="#ELEMENT_link">link</a>)* >
+ <!ELEMENT <a href="#PROPERTY_supportedlock">supportedlock</a> (<a href="#ELEMENT_lockentry">lockentry</a>)* >
+ ]>
+</pre><h2 id="rfc.section.23.2"><a href="#rfc.section.23.2">23.2</a> <a id="iso.8601.date.and.time.profile" href="#iso.8601.date.and.time.profile">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> 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> 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
+<A></A>. The second is to declare an XML element of the
+form <A/>. 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 <A></A>
+form if the associated DTD declares the element to be EMPTY (e.g.,
+<!ELEMENT A EMPTY>). If such a statement is included, then the
+empty element format, <A/> must be used. If the element is not
+declared to be EMPTY, then either form <A></A> or
+<A/> may be used for empty elements.</p><h3 id="rfc.section.23.3.2"><a href="#rfc.section.23.3.2">23.3.2</a> 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.23.3.2.1"><a href="#rfc.section.23.3.2.1">23.3.2.1</a> Example - XML Syntax Error</h4><p id="rfc.section.23.3.2.1.p.1">The following request body for a PROPFIND method is illegal.</p><div id="rfc.figure.u.94"></div><pre class="text"> <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:allprop/>
+ <D:propname/>
+ </D:propfind>
+</pre><p id="rfc.section.23.3.2.1.p.3">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.23.3.2.1.p.4">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.23.3.2.1.p.5">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.23.3.2.2"><a href="#rfc.section.23.3.2.2">23.3.2.2</a> Example - Unknown XML Element</h4><p id="rfc.section.23.3.2.2.p.1">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"> <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.foo.bar/standards/props/">
+ <E:expired-props/>
+ </D:propfind>
+</pre><p id="rfc.section.23.3.2.2.p.3">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"> <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.foo.bar/standards/props/">
+ </D:propfind>
+</pre><p id="rfc.section.23.3.2.2.p.5">As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in <a href="#instructions.for.processing.xml.in.dav" title="Instructions for Processing XML in DAV">Section 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.23.3.2.2.p.6">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"> <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.foo.bar/standards/props/">
+ <D:propname/>
+ <E:leave-out>*boss*</E:leave-out>
+ </D:propfind>
+</pre><p id="rfc.section.23.3.2.2.p.8">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> <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> 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> 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"> <del:glider xmlns:del="http://www.del.jensen.org/">
+ <del:glidername>
+ Johnny Updraft
+ </del:glidername>
+ <del:glideraccidents/>
+ </del:glider>
+</pre><p id="rfc.section.23.4.2.p.4">In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".</p><div id="rfc.figure.u.99"></div><pre class="text"> <bar:glider xmlns:del="http://www.del.jensen.org/">
+ <bar:glidername>
+ Johnny Updraft
+ </bar:glidername>
+ <bar:glideraccidents/>
+ </bar:glider>
+</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
+"http://www.del.jensen.org/" and then appended to the local name for
+each element tag. The resulting tag names in this example are exactly
+the same as for the previous example.</p><div id="rfc.figure.u.100"></div><pre class="text"> <foo:r xmlns:foo="http://www.del.jensen.org/glide">
+ <foo:rname>
+ Johnny Updraft
+ </foo:rname>
+ <foo:raccidents/>
+ </foo:r>
+</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 "http://www.del.jensen.org/glide" which is then
+appended to the local name for each element tag, the resulting tag
+names are identical to those in the previous examples.</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 “;AS IS” basis
+and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
+DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
+TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
+FITNESS FOR A PARTICULAR PURPOSE.</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) <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) <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) <a class="iref" href="#rfc.iref.46"><b>10.3</b></a></li><li class="indline1">423 Locked (status code) <a class="iref" href="#rfc.iref.47"><b>10.4</b></a></li><li class="indline1">424 Failed Dependency (status code) <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) <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 <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.a.1">12.1</a></li></ul></li><li class="indline1">allprop <ul class="ind"><li class="indline1">XML element <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 <a class="iref" href="#rfc.iref.c.1">3</a></li><li class="indline1">COPY method <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 <a class="iref" href="#rfc.iref.d.3"><b>9.1</b></a><ul class="ind"><li class="indline1">compliance class '1' <a class="iref" href="#rfc.iref.d.20"><b>15.1</b></a></li><li class="indline1">compliance class '2' <a class="iref" href="#rfc.iref.d.21"><b>15.2</b></a></li></ul></li><li class="indline1">DAV:collection resource type <a class="iref" href="#rfc.iref.d.7"><b>12.2</b></a></li><li class="indline1">DAV:creationdate property <a class="iref" href="#rfc.iref.d.9"><b>13.1</b></a></li><li class="indline1">DAV:displayname property <a class="iref" href="#rfc.iref.d.10"><b>13.2</b></a></li><li class="indline1">DAV:getcontentlanguage property <a class="iref" href="#rfc.iref.d.11"><b>13.3</b></a></li><li class="indline1">DAV:getcontentlength property <a class="iref" href="#rfc.iref.d.12"><b>13.4</b></a></li><li class="indline1">DAV:getcontenttype property <a class="iref" href="#rfc.iref.d.13"><b>13.5</b></a></li><li class="indline1">DAV:getetag property <a class="iref" href="#rfc.iref.d.14"><b>13.6</b></a></li><li class="indline1">DAV:getlastmodified property <a class="iref" href="#rfc.iref.d.15"><b>13.7</b></a></li><li class="indline1">DAV:lockdiscovery property <a class="iref" href="#rfc.iref.d.16"><b>13.8</b></a></li><li class="indline1">DAV:resourcetype property <a class="iref" href="#rfc.iref.d.17"><b>13.9</b></a></li><li class="indline1">DAV:source property <a class="iref" href="#rfc.iref.d.18"><b>13.10</b></a></li><li class="indline1">DAV:supportedlock property <a class="iref" href="#rfc.iref.d.19"><b>13.11</b></a></li><li class="indline1">Dead Property <a class="iref" href="#rfc.iref.d.1">3</a></li><li class="indline1">DELETE method <a class="iref" href="#rfc.iref.d.2"><b>8.6</b></a></li><li class="indline1">depth <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.d.6">12.1.1</a></li></ul></li><li class="indline1">Depth header <a class="iref" href="#rfc.iref.d.4"><b>9.2</b></a></li><li class="indline1">Destination header <a class="iref" href="#rfc.iref.d.5"><b>9.3</b></a></li><li class="indline1">dst <ul class="ind"><li class="indline1">XML element <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 <ul class="ind"><li class="indline1">XML element <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 <ul class="ind"><li class="indline1">DAV <a class="iref" href="#rfc.iref.h.1"><b>9.1</b></a></li><li class="indline1">Depth <a class="iref" href="#rfc.iref.h.2"><b>9.2</b></a></li><li class="indline1">Destination <a class="iref" href="#rfc.iref.h.3"><b>9.3</b></a></li><li class="indline1">If <a class="iref" href="#rfc.iref.h.4"><b>9.4</b></a></li><li class="indline1">Lock-Token <a class="iref" href="#rfc.iref.h.5"><b>9.5</b></a></li><li class="indline1">Overwrite <a class="iref" href="#rfc.iref.h.6"><b>9.6</b></a></li><li class="indline1">Status-URI <a class="iref" href="#rfc.iref.h.7"><b>9.7</b></a></li><li class="indline1">Timeout <a class="iref" href="#rfc.iref.h.8"><b>9.8</b></a></li></ul></li><li class="indline1">href <ul class="ind"><li class="indline1">XML element <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 <a class="iref" href="#rfc.iref.i.2"><b>9.4</b></a></li><li class="indline1">Internal Member URI <a class="iref" href="#rfc.iref.i.1">3</a></li><li class="indline1"><em>ISO-11578</em> <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> <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> <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 <ul class="ind"><li class="indline1">XML element <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 <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.l.5">12.4</a></li></ul></li><li class="indline1">Live Property <a class="iref" href="#rfc.iref.l.1">3</a></li><li class="indline1">LOCK method <a class="iref" href="#rfc.iref.l.2"><b>8.10</b></a></li><li class="indline1">Lock-Token header <a class="iref" href="#rfc.iref.l.3"><b>9.5</b></a></li><li class="indline1">lockentry <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.l.6">12.5</a></li></ul></li><li class="indline1">lockinfo <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.l.7">12.6</a></li></ul></li><li class="indline1">lockscope <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.l.8">12.7</a></li></ul></li><li class="indline1">locktoken <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.l.4">12.1.2</a></li></ul></li><li class="indline1">locktype <ul class="ind"><li class="indline1">XML element <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 <a class="iref" href="#rfc.iref.m.1">3</a></li><li class="indline1">Methods <ul class="ind"><li class="indline1">COPY <a class="iref" href="#rfc.iref.m.8"><b>8.8</b></a></li><li class="indline1">DELETE <a class="iref" href="#rfc.iref.m.6"><b>8.6</b></a></li><li class="indline1">LOCK <a class="iref" href="#rfc.iref.m.11"><b>8.10</b></a></li><li class="indline1">MKCOL <a class="iref" href="#rfc.iref.m.5"><b>8.3</b></a></li><li class="indline1">MOVE <a class="iref" href="#rfc.iref.m.10"><b>8.9</b></a></li><li class="indline1">PROPFIND <a class="iref" href="#rfc.iref.m.2"><b>8.1</b></a></li><li class="indline1">PROPPATCH <a class="iref" href="#rfc.iref.m.3"><b>8.2</b></a></li><li class="indline1">PUT <a class="iref" href="#rfc.iref.m.7"><b>8.7</b></a></li><li class="indline1">UNLOCK <a class="iref" href="#rfc.iref.m.12"><b>8.11</b></a></li></ul></li><li class="indline1">MKCOL method <a class="iref" href="#rfc.iref.m.4"><b>8.3</b></a></li><li class="indline1">MOVE method <a class="iref" href="#rfc.iref.m.9"><b>8.9</b></a></li><li class="indline1">multistatus <ul class="ind"><li class="indline1">XML element <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 <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 <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.o.3">12.12.2</a></li></ul></li><li class="indline1">Overwrite header <a class="iref" href="#rfc.iref.o.1"><b>9.6</b></a></li><li class="indline1">owner <ul class="ind"><li class="indline1">XML element <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 <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.6">12.11</a></li></ul></li><li class="indline1">Properties <ul class="ind"><li class="indline1">DAV:creationdate <a class="iref" href="#rfc.iref.p.11"><b>13.1</b></a></li><li class="indline1">DAV:displayname <a class="iref" href="#rfc.iref.p.12"><b>13.2</b></a></li><li class="indline1">DAV:getcontentlanguage <a class="iref" href="#rfc.iref.p.13"><b>13.3</b></a></li><li class="indline1">DAV:getcontentlength <a class="iref" href="#rfc.iref.p.14"><b>13.4</b></a></li><li class="indline1">DAV:getcontenttype <a class="iref" href="#rfc.iref.p.15"><b>13.5</b></a></li><li class="indline1">DAV:getetag <a class="iref" href="#rfc.iref.p.16"><b>13.6</b></a></li><li class="indline1">DAV:getlastmodified <a class="iref" href="#rfc.iref.p.17"><b>13.7</b></a></li><li class="indline1">DAV:lockdiscovery <a class="iref" href="#rfc.iref.p.18"><b>13.8</b></a></li><li class="indline1">DAV:resourcetype <a class="iref" href="#rfc.iref.p.19"><b>13.9</b></a></li><li class="indline1">DAV:source <a class="iref" href="#rfc.iref.p.20"><b>13.10</b></a></li><li class="indline1">DAV:supportedlock <a class="iref" href="#rfc.iref.p.21"><b>13.11</b></a></li></ul></li><li class="indline1">Property <a class="iref" href="#rfc.iref.p.1">3</a></li><li class="indline1">propertybehaviour <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.7">12.12</a></li></ul></li><li class="indline1">propertyupdate <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.8">12.13</a></li></ul></li><li class="indline1">propfind <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.9">12.14</a></li></ul></li><li class="indline1">PROPFIND method <a class="iref" href="#rfc.iref.p.2"><b>8.1</b></a></li><li class="indline1">propname <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.10">12.14.2</a></li></ul></li><li class="indline1">PROPPATCH method <a class="iref" href="#rfc.iref.p.3"><b>8.2</b></a></li><li class="indline1">propstat <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.p.5">12.9.1.1</a></li></ul></li><li class="indline1">PUT method <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> <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> <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> <a class="iref" href="#rfc.xref.REC-XML.5">17.7</a></li></ul></li><li class="indline1"><em>REC-XML-NAMES</em> <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 <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.r.4">12.13.1</a></li></ul></li><li class="indline1">Resource Types <ul class="ind"><li class="indline1">DAV:collection <a class="iref" href="#rfc.iref.r.1"><b>12.2</b></a></li></ul></li><li class="indline1">response <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.r.2">12.9.1</a></li></ul></li><li class="indline1">responsedescription <ul class="ind"><li class="indline1">XML element <a class="iref" href="#rfc.iref.r.3">12.9.2</a></li></ul></li><li class="indline1"><em>RFC1766</em> <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> <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> <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> <a class="iref" href="#rfc.xref.RFC2026.2">19</a></li></ul></li><li class="indline1"><em>RFC2068</em> <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">12.9.1.2</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