WEBDAV Working Group                            Y.Y. Goland, Microsoft
INTERNET DRAFT                          E.J. Whitehead, Jr., UC Irvine
<draft-ietf-webdav-protocol-05>
<draft-ietf-webdav-protocol-06>                     A. Faizi, Netscape
                                                   S.R. Carter, Novell
                                                     D. Jensen, Novell
Expires April, July, 1998                                    January 18, 1998                                  November 19, 1997

  Extensions for Distributed Authoring on the World Wide Web -- WEBDAV

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

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

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited. Please send comments to
   the Distributed Authoring and Versioning (WEBDAV) working group at
   <w3c-dist-auth@w3.org>, which may be joined by sending a message
   with subject "subscribe" to <w3c-dist-auth-request@w3.org>.

   Discussions of the WEBDAV working group are archived at
   <URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.

Abstract

   This document specifies a set of methods, headers, and content-types
   ancillary to HTTP/1.1 for the management of resource properties,
   creation and management of resource collections, namespace
   manipulation, and resource locking (collision avoidance), and efficient
   transmission of resource changes. avoidance).

Changes

1.1.

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

   [Editor's note: This section will not appear in the final form of
   this document.  Its purpose is to provide a concise list of changes
   from the previous revision of the draft for use by reviewers.]

   Added this change section.

   Removed scoping for namespaces so the namespace

   Rationale for
   every element is explicitly stated.

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

   Removed propfindresult, changes made in this was left over from revision of the old search
   format.

   Changed all draft
   can be found in the DAV XML element names to lower case.

   Changed mailing list archives at:

   http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0160.ht
   ml.

   Where the property format 200 OK status code was used to use Name indicate a successful
   response without a response entity body, 204 No Content is now used.
   Because PEP uses 420 and Namespace rather than
   name 421 status codes, and schema.

   Removed proploc attribute since PEP has been
   submitted as an Experimental RFC, the WebDAV 420 status code has
   been changed to 422, and removed section on GETting, DELETEing, the WebDAV 421 status code has been changed
   to 423.

   The 423 Destination Locked status code has been changed to 423
   Locked, and PUTing properties since we do not provide a mechanism for
   getting a URI for properties.  Also removed now covers all cases where an operand was locked,
   preventing the requirement that
   properties be URI addressable. execution of the method.

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

   Made all the HTTP error codes use the same format.

   Changed the name of the create element not needed in PROPPATCH to set, the new
   name seems to cause less confusion.

   Moved all headers this draft,
   but will be needed in the draft versioning draft.

   The Enforce-Live-Properties header was renamed to a single section.

   Deleted Property-Behavior,
   to more closely represent the state token section meaning of the draft and moved header now that the state
   token headers
   "omit" functionality is included. A keepalive field was added to the
   Property-Behavior header section of the draft. to make it more meaningful.

   Removed the state
   token header.

   Changed INDEX method, since the write lock section to state that a Lock-Token request
   header, not a state-token request header, is to functionality of INDEX can now
   be submitted on
   request performed by the PROPFIND method.  PROPFIND provides more
   flexibility in specifying the type and amount of property
   information returned than does INDEX, which is important for write locked resources.

   Created
   returning information on a "generic" XML element section for XML elements large number of resources.

   Clarified that get
   repeatedly re-used throughout the spec.  I moved LINK XML element to
   this section.

   Made multistatus and Schema discovery their own level one sections.

   Collected all the properties together.

   Removed all references performing a MOVE as a COPY, then DELETE, performed
   atomically, only applies to non-collection resources.

   Clarified the possibility semantics of properties have their
   own URIs.  This includes removing the property identifier section.

   Separated the section on web collections errors that are encountered in infinite
   depth move and namespaces into two
   separate sections.

   Collected all copy of a hierarchy of resources.  For errors copying
   internal nodes of the new response codes together into their own
   section.

   Changed hierarchy tree (i.e., collections), the XML multiresponse element name to multistatus.

   Added a stand alone section
   operation skips that subtree, and moves on levels of DAV compliance. I also went
   method by method, property by property, to specify compliance
   requirements.

   Added the next subtree.  If
   an introduction.

   Changed all error is encountered moving/copying a leaf of the "True" tree, then skip
   that resource, and "False" move on to "T" and "F".

   Altered the first two paragraphs of next leaf.

   Removed the Property Names section to
   make PATCH method.  This will be resubmitted as the relationship between a property's name and its schema document
   draft-ietf-webdav-patch-00.

   Added language that states that if a
   little clearer.  I also added some text in the same section defining PROPPATCH is invoked on a property name as null
   resource (e.g., a namespace deleted resource), an empty resource is created,
   and element. the PROPPATCH directives are performed on this new resource.

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

   Added a 409 Conflict error the source link definition (Section
   13.11) in Section 4.4.

   Changed all Values= to move Values:.  Also changed all "values" to cover attempts
   "value".

   References to move a
   collection with members.

   Changed the collection requirement state tokens are now restricted to read sections 9.7 and
   9.8.

   The property-behavior header has been turned into the collections SHOULD
   end with "/".  Also added a SHOULD about returning
   propertybehavior XML element because it contained a location list of URIs
   which can thus have unbounded size.  The lock-info header
   if has been
   turned into the client submits a URL lockinfo XML element for a collection without a trailing "/".

   Moved the owner same reason.  I have
   also made the same change of the Propfind header into the body due to size concerns.

   Replaced the iscollection xml element with resourcetype.

   Moved Propfind
   XML element.  We can put the DAV property to the DAV behavior header that is returned with
   OPTIONS.

   Folded the tree draft into this draft.  Changed the DELETE, COPY,
   and body
   because neither COPY nor MOVE sections to include their effect on collections as taken
   from the tree draft.  Created a Depth header section and have bodies. However we can't put
   lock-token, if-state-match, etc. in the
   general rules body because they may need
   to be used with PUT. However I don't consider this a big deal
   because I sincerely doubt that were in there will be cases where lock-token
   or if-state-match will see large numbers of entries.

   Also changed omit to mean "copy properties with best effort but
   failure is acceptable."

   Added the introduction external members property.

   Added language to 6.4 making it clear that any new resources created
   as the tree draft.  I
   also child of a write locked collection is added to the 102 response and response-status header.

   Removed the versioning section.

   Put all lock.

   Made the methods into lock-token response header from a single section.

   Replaced URL to multiple
   URLs.  But all the PROPFIND request body with a propfind header. Now URLs MUST refer to the
   response can be cached just using vary.

   Nuked resinfo exact same lock.

   <?XML version="1.0"> changed to the correct form: <?xml
   version="1.0"?>

   Changed the delete rule for INDEX and combined collections to read that if a delete in
   a collection member fails then it with multistatus which is
   now used for both INDEX and PROPFIND.  Stripped down INDEX as
   agreed.

   Removed the problem definition and proposed solution sections. We ancestors, not the progeny,
   who can always cut and paste them together from not be deleted in order to maintain the older version if we
   feel we need them but this draft is supposed namespace.

   Updated our reference to be a dry run for
   last call the XML spec.

   Added LOCK and last call documents do not have problem
   definition/proposed solution sections.

   Killed UNLOCK to the section on schema discovery, it list of methods covered by the write
   lock. This is controversial and we
   aren't going necessary so that a lock-token will have to be able to require it.  We should specify it
   submitted in a
   different spec.

   Added a section on notational conventions used within the document.

   Moved the terminology section order to make changes, otherwise we defeat the end whole
   purpose of requiring the document to provide
   better flow from lock-token.

   Changed the high-level introduction title of section 6.6 from Re-Issuing Write Locks to
   Refreshing Write Locks, made it illegal to make the specific
   introduction sections.

   Increased same lock
   request twice (you know you are making the numeric value of same request because you
   had to include the 4xx status codes introduced in
   this specification lock-token to avoid conflicts make it!) and instead made it legal
   to submit a LOCK method with the new revision of the
   HTTP/1.1 specification, which introduces two new 4xx status codes.

   Wrote internationalization concerns section.

   Added XML version number no body but with a lock-token header.
   I also added a refresh example.

   Put in a note that an empty request body for PROPFIND means to
   return all examples.

Contents

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

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

3.5. Property Names..................................................11
4. COLLECTIONS OF WEB RESOURCES......................................11
4.1. Collection Resources............................................11
4.2. Creation names and Retrieval values of Collection Resources..................12
4.3. HTTP URL Namespace Model........................................13
4.4. Source Resources and Output Resources...........................13
5. LOCKING...........................................................14

5.1. Exclusive Vs. Shared Locks......................................14
5.2. Required Support................................................15
5.3. Lock Tokens.....................................................16
5.4. opaquelocktoken Lock Token URI Scheme...........................16
5.5. Lock Capability Discovery.......................................16
5.6. Active Lock Discovery...........................................17
6. WRITE LOCK........................................................17
6.1. Methods Restricted by Write Locks...............................17

6.2. Write Locks and Properties......................................17
6.3. Write Locks and Null Resources..................................17
6.4. Write Locks and Collections.....................................18
6.5. Write Locks and COPY/MOVE.......................................18
6.6. Re-issuing Write Locks..........................................18
6.7. Write Locks and The Lock-Token Request Header...................18
7. NOTATIONAL CONVENTIONS............................................19

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

8.8. POST for Collections............................................29
8.9. DELETE..........................................................29
8.10. PUT............................................................31
8.11. COPY Method....................................................31
8.12. MOVE Method....................................................35
8.13. LOCK Method....................................................38

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

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

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

   I have added a section on Resource.............................54

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

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

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

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

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

   This document describes an extension to processing errors. I know, I know, it
   shouldn't be in the HTTP/1.1 protocol that
   allows clients standard. I will move it to perform remote web content authoring operations.
   This extension provides a coherent set of methods, headers, request
   entity body formats, our compliance draft
   as soon as we prepare the first version.

   Removed addlocks and response entity body formats that provide
   operations for:

   Properties: The ability to create, remove, replaced with the depth header and query information
   about Web pages, such as its author, creation date, etc. Also, the
   ability to link pages of any media type depth
   element.

   Changed all the as in namespace elements to related pages.

   Collections: The ability all lower case.

   Moved all XML element declarations to create sets of related documents, and the same section.  Removed the
   parent description.

   Updated the depth section to
   receive a listing of pages at a particular hierarchy level (like make it more generic, changed the
   wording for how COPY/MOVE are handled with write locks, require that
   ALL propfind responses include href, require that if a
   directory listing property is
   not found in a file system).

   Locking: The ability to keep more than one person from working propfind then a 404 Not Found must be returned, and
   made explicit that PROPFIND responses on resources with internal
   members are returned as a
   document at the same time. This prevents the "lost flat list with no significance to its
   ordering.

   Removed reference to efficient update problem" in which modifications are lost as first one author, then another
   writes their changes without merging the other author's changes

   Namespace Operations: The ability to copy introduction since
   PATCH is now gone.

   Rewrote the write lock and move Web resources

   Efficient Update: The ability to send changes which are proportional null resource section to deal with the size
   question of the change rather than retransmitting state of the entire
   resource.

   Requirements and rationale for these operations are described in a
   companion document, "Requirements for a Distributed Authoring resource when it is locked and
   Versioning Protocol for the World Wide Web" [Slein et al., 1997].

   The sections below provide a detailed introduction null.

   Changed www.ietf.org to resource
   properties (Section 3), collections of resources (Section 4), www.iana.org.

   Changed the response element and
   locking operations (Section 5).  These sections introduce added the
   abstractions manipulated by new propstat element.
   With the WebDAV-specific HTTP methods
   described in Section 8, "HTTP Methods for Distributed Authoring".

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter
   information either in prohibition that an Extensible Markup Language (XML) [Bray,
   Sperberg-McQueen, 1997] request entity body, or HREF can only appear once in an HTTP header.
   The use of XML to encode method parameters was motivated a
   multistatus response we can guarantee linear processing costs.

   Added Intellectual Property section, as required by the
   ability to add extra XML elements RFC 2026.

   Added IANA Considerations section.

   Added Authorization headers to existing structures, providing
   extensibility, LOCK and by XML's ability to encode information in ISO
   10646 character sets, providing internationalization support. As a
   rule of thumb, parameters are encoded UNLOCK examples.

   Changed lock tokens in XML entity bodies when they
   have unbounded length, or when they may be shown examples to use string format of UUID.

   Since the latest HTTP revision defines a human user 418 and
   hence require encoding in an ISO 10646 character set.  Otherwise,
   parameters are encoded within an HTTP header.  Section 9 describes 419 status code,
   the new HTTP headers used with WebDAV methods.

   In addition 418 status code has been changed to encoding method parameters, XML is used in WebDAV 422, 419 to
   encode the responses from methods, providing the extensibility 423, 422 to 424,
   and
   internationalization advantages 423 to 425.

   Changed implementation of XML for method output, as well as
   input. XML elements used in this specification are defined in
   Section 12.

   While the response codes provided by HTTP/1.1 are sufficient get* (e.g., getcontentlength)
   properties to
   describe the preponderance strength MUST.

   Changed definition of error conditions encountered by WebDAV
   methods, there are some errors that do not fall neatly into the
   existing categories.  New status codes developed for the WebDAV
   methods are defined in Section 10.  Since some WebDAV methods may
   operate over many resources, the multiresponse status type has been
   introduced to return status information for multiple resources.
   Multiresponse status is described in Section 11.

   The XML elements and DAV properties mechanism is employed by WebDAV to store information
   about the current state of the resource.  For example, when a lock
   is taken out on a resource, a lock information property describes
   the current state of the lock. Section 13 defines the properties
   used within the WebDAV specification.

   Finishing off the specification are use XML
   element definitions, rather than BNF.

   Renumbered all sections on what it means to be
   compliant with this specification (Section 14), on
   internationalization support (Section 15), and on security (Section
   16).

3. Data Model for Resource Properties

3.1.

Contents

STATUS OF THIS MEMO..................................................1
ABSTRACT.............................................................1
CHANGES..............................................................1
Changes since draft-ietf-webdav-protocol-06.txt......................1
CONTENTS.............................................................5
1 INTRODUCTION.......................................................9
2 DATA MODEL FOR RESOURCE PROPERTIES................................10
2.1  The Resource Property Model

   Properties are pieces of data that describe the state of a resource.
   Properties are data about data. Model....................................10
2.2  Existing Metadata Proposals....................................10
2.3  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, HTTP Headers....................................11
2.4  Property Values................................................11
2.5  Property Names.................................................12
3 COLLECTIONS OF WEB RESOURCES......................................12
3.1  Collection Resources...........................................12
3.2  Creation and an 'author' property might allow for the
   discovery of what authors have written which documents.

   The DAV property model consists of name/value pairs.  The name Retrieval of a
   property identifies the property's syntax and semantics, Collection Resources.................13
3.3  HTTP URL Namespace Model.......................................13
3.4  Source Resources and
   provides an address Output Resources..........................14
4 LOCKING...........................................................15
4.1  Exclusive Vs. Shared Locks.....................................15
4.2  Required Support...............................................16
4.3  Lock Tokens....................................................16
4.4  opaquelocktoken Lock Token URI Scheme..........................17
4.5  Lock Capability Discovery......................................17
4.6  Active Lock Discovery..........................................18
5 WRITE LOCK........................................................18
5.1  Methods Restricted by which to refer to that syntax Write Locks..............................18
5.2  Write Locks and semantics.

   There are two categories of properties: "live" Properties.....................................18
5.3  Write Locks and "non-live".  A
   live property has its syntax Null Resources.................................18
5.4  Write Locks and semantics enforced by the server.
   This represents the two cases of a) the value of a property is read-
   only, maintained by the server, Collections....................................19
5.5  Write Locks and b) the value of the property is
   maintained by the client, but server performs syntax checking on
   submitted values. A non-live property has its syntax COPY/MOVE......................................19
5.6  Refreshing Write Locks.........................................19
5.7  Write Locks and semantics
   enforced by the client; the server merely records the value The Lock-Token Request Header..................20
 5.7.1   Write Lock Token Example...................................20
6 NOTATIONAL CONVENTIONS............................................21
7 HTTP METHODS FOR DISTRIBUTED AUTHORING............................21
7.1  PROPFIND.......................................................21
 7.1.1   Example: Retrieving Named Properties.......................22
 7.1.2   Example: Using allprop to Retrieve All Properties..........23
 7.1.3   Example: Using propname to Retrieve all Property Names.....26
7.2  PROPPATCH......................................................28
 7.2.1   Status Codes...............................................28
 7.2.2   Example....................................................28
7.3  MKCOL Method...................................................30
 7.3.1   Request....................................................30
 7.3.2   Response Codes.............................................30
 7.3.3   Example....................................................31
7.4  ADDREF Method..................................................31
 7.4.1   The Request................................................31
 7.4.2   Example....................................................31
7.5  DELREF Method..................................................32
 7.5.1   The Request................................................32
 7.5.2   Example....................................................32
7.6  GET, HEAD for Collections......................................32
7.7  POST for Collections...........................................33
7.8  DELETE.........................................................33
 7.8.1   DELETE for Non-Collection Resources........................33
 7.8.2   DELETE for Collections.....................................33
7.9  PUT............................................................34
 7.9.1   PUT for Non-Collection Resources...........................34
 7.9.2   PUT for Collections........................................35
7.10 COPY Method....................................................35
 7.10.1  COPY for HTTP/1.1 resources................................35
 7.10.2  COPY for Properties........................................35
 7.10.3  COPY for Collections.......................................36
 7.10.4  Type Interactions..........................................37
 7.10.5  Status Codes...............................................37
 7.10.6  Overwrite Example..........................................38
 7.10.7  No Overwrite Example.......................................38
 7.10.8  Collection Example.........................................38
7.11 MOVE Method....................................................39
 7.11.1  MOVE for Collections.......................................40
 7.11.2  Status Codes...............................................40
 7.11.3  Non-Collection Example.....................................41
 7.11.4  Collection Example.........................................41
7.12 LOCK Method....................................................42
 7.12.1  Operation..................................................43
 7.12.2  The Effect of the
   property verbatim.

3.2. Existing Metadata Proposals Locks on 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 [Miller et al., 1996], PICS-NG, the Rel/Rev draft
   [Maloney, 1996], Web Collections, XML [Bray, Sperberg-McQueen,
   1997], several proposals on representing relationships within HTML,
   digital signature manifests (DCMF), Collections..........43
 7.12.3  Locking Replicated Resources...............................43
 7.12.4  Depth and Locking..........................................43
 7.12.5  Interaction with other Methods.............................44
 7.12.6  Lock Compatibility Table...................................44
 7.12.7  Lock Response..............................................44
 7.12.8  Status Codes...............................................44
 7.12.9  Example - Simple Lock Request..............................45
 7.12.10  Example - Refreshing a position paper on Web
   metadata architecture [Berners-Lee, 1997].  Work on PICS-NG and Web
   Collections has been subsumed by the Resource Definition Framework
   (RDF) metadata activity Write Lock.........................46
 7.12.11  Example - Multi-Resource Lock Request.....................47
7.13 UNLOCK Method..................................................48
 7.13.1  Example....................................................48
8 HTTP HEADERS FOR DISTRIBUTED AUTHORING............................49
8.1  Collection-Member Header.......................................49
8.2  DAV Header.....................................................49
8.3  Depth Header...................................................49
8.4  Destination Header.............................................50
8.5  If-None-State-Match............................................50
8.6  If-State-Match.................................................51
8.7  Lock-Token Request Header......................................51
8.8  Lock-Token Response Header.....................................52
8.9  Overwrite Header...............................................53
8.10 Status-URI Response Header.....................................53
8.11 Timeout Header.................................................53
9 STATUS CODE EXTENSIONS TO HTTP/1.1................................54
9.1  102 Processing.................................................54
9.2  207 Multi-Status...............................................55
9.3  422 Unprocessable Entity.......................................55
9.4  423 Insufficient Space on Resource.............................55
9.5  424 Method Failure.............................................55
9.6  425 Locked.....................................................55
10  MULTI-STATUS RESPONSE...........................................55
11  XML ELEMENT DEFINITIONS.........................................55
11.1 activelock XML Element.........................................56
 11.1.1  depth XML Element..........................................56
 11.1.2  locktoken XML Element......................................56
 11.1.3  timeout XML Element........................................56
11.2 collection XML Element.........................................56
11.3 href XML Element...............................................56
11.4 link XML Element...............................................57
 11.4.1  dst XML Element............................................57
 11.4.2  src XML Element............................................57
11.5 lockentry XML Element..........................................57
11.6 lockinfo XML Element...........................................57
11.7 lockscope XML Element..........................................58
 11.7.1  exclusive XML Element......................................58
 11.7.2  shared XML Element.........................................58
11.8 locktype XML Element...........................................58
 11.8.1  write XML Element..........................................58
11.9 multistatus XML Element........................................58
 11.9.1  response XML Element.......................................59
 11.9.2  responsedescription XML Element............................59
11.10 owner XML Element.............................................60
11.11 prop XML element..............................................60
11.12 propertybehavior XML element..................................60
 11.12.1  keepalive XML element.....................................60
 11.12.2  omit XML element..........................................61
11.13 propertyupdate XML element....................................61
 11.13.1  remove XML element........................................61
 11.13.2  set XML element...........................................62
11.14 propfind XML Element..........................................62
 11.14.1  allprop XML Element.......................................62
 11.14.2  propname XML Element......................................62
12  DAV PROPERTIES..................................................62
12.1 creationdate Property..........................................63
12.2 displayname Property...........................................63
12.3 externalmembers Property.......................................63
12.4 getcontentlanguage Property....................................63
12.5 getcontentlength Property......................................64
12.6 getcontenttype Property........................................64
12.7 getetag Property...............................................64
12.8 getlastmodified Property.......................................64
12.9 lockdiscovery Property.........................................65
 12.9.1  Example....................................................65
12.10 resourcetype Property.........................................66
12.11 source Property...............................................66
 12.11.1  Example...................................................67
12.12 supportedlock Property........................................67
 12.12.1  Example...................................................68
13  DAV COMPLIANCE CLASSES..........................................68
13.1 Class 1........................................................69
13.2 Class 2........................................................69
14  INTERNATIONALIZATION CONSIDERATIONS.............................69
15  SECURITY CONSIDERATIONS.........................................70
15.1 Authentication of Clients......................................71
15.2 Denial of the World Wide Web Consortium, which
   consists Service..............................................71
15.3 Security through Obscurity.....................................72
15.4 Privacy Issues Connected to Locks..............................72
15.5 Privacy Issues Connected to Properties.........................72
15.6 Reduction of a network-based data model Security due to Source Link.......................72
16  IANA CONSIDERATIONS.............................................73
17  TERMINOLOGY.....................................................73
18  COPYRIGHT.......................................................74
19  INTELLECTUAL PROPERTY...........................................74
20  ACKNOWLEDGEMENTS................................................75
21  REFERENCES......................................................76
22  AUTHORS' ADDRESSES..............................................78
23  APPENDICES......................................................79
23.1 Appendix 1 - WebDAV Document Type Definition...................79
23.2 Appendix 2 - ISO 8601 Date and an Time Profile....................80
23.3 Appendix 3 - Notes on Processing XML representation of Elements..................81
 23.3.1  XML Syntax Error Example...................................81
 23.3.2  Unknown XML Element Example................................81

1  Introduction

   This document describes an extension to the HTTP/1.1 protocol that model.

   Some proposals come from
   allows clients to perform remote web content authoring operations.
   This extension provides a digital library perspective.  These
   include the Dublin Core [Weibel et al., 1995] metadata coherent set of methods, headers, request
   entity body formats, and the
   Warwick Framework [Lagoze, 1996], a container architecture for
   different metadata schemas. response entity body formats that provide
   operations for:

   Properties: The literature includes many examples
   of metadata, including MARC [MARC, 1994], a bibliographic metadata
   format, ability to create, remove, and RFC 1807 [Lasher, Cohen, 1995], a technical report
   bibliographic format employed by the Dienst system. Additionally, query information
   about Web pages, such as their authors, creation dates, etc. Also,
   the proceedings ability to link pages of any media type to related pages.

   Collections: The ability to create sets of related documents, and to
   receive a listing of pages at a particular hierarchy level (like a
   directory listing in a file system).

   Locking: The ability to keep more than one person from working on a
   document at the first IEEE Metadata conference describe
   many community-specific metadata sets.

   Participants of same time. This prevents the 1996 Metadata II Workshop "lost update problem,"
   in Warwick, UK
   [Lagoze, 1996], noted that, "new metadata sets will develop which modifications are lost as first one author, then another
   writes changes without merging the
   networked infrastructure matures" other author's changes

   Namespace Operations: The ability to copy and "different communities will
   propose, design, move Web resources

   Requirements and be responsible rationale for different types of
   metadata." These observations can be corroborated by noting that
   many community-specific sets of metadata already exist, these operations are described in a
   companion document, "Requirements for a Distributed Authoring and there is
   significant motivation
   Versioning Protocol for the development of new forms of metadata
   as many communities increasingly make their data available in
   digital form, requiring World Wide Web" [Slein et al., 1997].

   The sections below provide a metadata format detailed introduction to assist data location
   and cataloging.

3.3. Properties resource
   properties (Section 2), collections of resources (Section 3), and
   locking operations (Section 4).  These sections introduce the
   abstractions manipulated by the WebDAV-specific HTTP Headers

   Properties already exist, methods
   described in a limited sense, Section 7, "HTTP Methods for Distributed Authoring".

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP message headers.  However, Unlike HTTP/1.1, WebDAV, encodes method parameter
   information either in distributed authoring environments a
   relatively large number an Extensible Markup Language (XML) [Bray,
   Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
   header.  The use of properties are needed XML to describe encode method parameters was motivated by
   the
   state of a resource, ability to add extra XML elements to existing structures,
   providing extensibility, and setting/returning them all through HTTP
   headers is inefficient.  Thus a mechanism is needed which allows a
   principal by XML's ability to identify encode information
   in ISO 10646 character sets, providing internationalization support.
   As a set rule of properties thumb, parameters are encoded in which the principal is
   interested and to then set or retrieve just those properties.

3.4. Property Values

   The value of a property is expressed as a well-formed XML document. 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 because entity bodies when
   they will
   still have the data specified in the original schema and will ignore
   elements unbounded length, or when they do not understand.  XML's support for multiple
   character sets allows human-readable properties to may be encoded shown to a human
   user and
   read hence require encoding in a an ISO 10646 character set familiar to set.
   Otherwise, parameters are encoded within HTTP headers.  Section 8
   describes the user.

3.5. Property Names

   A property name is a universally unique identifier that is
   associated new HTTP headers used with a schema that provides information about WebDAV methods.

   In addition to encoding method parameters, XML is used in WebDAV to
   encode the syntax responses from methods, providing the extensibility and semantics
   internationalization advantages of the property.

   Because a property's name is universally unique, clients can depend
   upon consistent behavior XML for a particular property across multiple
   resources, so long method output, as that property is "live" on the resources in
   question.

   The well as
   input. XML namespace mechanism, which is based on URIs, is elements used in this specification are defined in
   Section 11.

   While the status codes provided by HTTP/1.1 are sufficient to name
   properties because it provides a mechanism
   describe most error conditions encountered by WebDAV methods, there
   are some errors that do not fall neatly into the existing
   categories.  New status codes developed for the WebDAV methods are
   defined in Section 9.  Since some WebDAV methods may operate over
   many resources, the Multi-Status status type has been introduced to prevent namespace
   collisions and
   return status information for varying degrees of administrative control.

   The property namespace is flat; that is, no hierarchy of properties multiple resources.  Multi-Status
   response is explicitly recognized.  Thus, if a property A and a described in Section 10.

   WebDAV employs the property A/B
   exist on a resource, there is no recognition mechanism to store information about the
   current state of any relationship
   between the two properties.  It is expected that resource.  For example, when a separate
   specification will eventually be produced which will address issues
   relating to hierarchical properties.

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

4. Collections of Web Resources

   This section provides a description of a new type describes the current
   state of Web resource, the collection, and discusses its interactions with lock. Section 12 defines the HTTP URL
   namespace. properties used within the
   WebDAV specification.

   Finishing off the specification are sections on what it means to be
   compliant with this specification (Section 13), on
   internationalization support (Section 14), and on security (Section
   15).

2  Data Model for Resource Properties

2.1 The purpose Resource Property Model

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

   Properties are used in distributed authoring environments to model
   collection-like objects (e.g., filesystem directories) within provide
   for efficient discovery and management of resources.  For example, a
   server's namespace.

   All DAV compliant
   'subject' property might allow for the indexing of all resources MUST support by
   their subject, and an 'author' property might allow for the HTTP URL namespace
   discovery of what authors have written which documents.

   The DAV property model specified herein.

4.1. Collection Resources

   A collection is a resource whose state consists of an unordered list name/value pairs.  The name of internal members, a
   property identifies the property's syntax and semantics, and
   provides an unordered list address by which to refer to that syntax and semantics.

   There are two categories of external members, properties: "live" and a
   set "dead".  A live
   property has its syntax and semantics enforced by the server. Live
   properties include cases where a) the value of properties.  An internal member resource MUST have a URI that property is immediately relative to read-
   only, maintained by the base URI server, and b) the value of the collection, that is,
   a relative URI in which "../" property is illegal, which MUST begin with "./"
   and which SHOULD contain a "/" at
   maintained by the end of client, but the URI if server performs syntax checking on
   submitted values. A dead property has its syntax and semantics
   enforced by the internal
   member resource is itself a collection.

   An external member resource MUST be an absolute URI that is not an
   internal URI.  Any given internal or external URI MUST only belong
   to client; the collection once, i.e., it is illegal to have multiple
   instances server merely records the value of the same URI
   property verbatim.

2.2 Existing Metadata Proposals
   Properties have long played an essential role in the maintenance of
   large document repositories, and many current proposals contain some
   notion of a collection.  Properties defined property, or discuss web metadata more generally.  These
   include PICS [Miller et al., 1996], PICS-NG, XML [Bray, Paoli,
   Sperberg-McQueen, 1998], Web Collections, and several proposals on
   collections behave exactly as do properties
   representing relationships within HTML. Work on non-collection
   resources.

   There is PICS-NG and Web
   Collections has been subsumed by the Resource Definition Framework
   (RDF) metadata activity of the World Wide Web Consortium. RDF
   consists of a standing convention network-based data model and an XML representation of
   that when a collection is referred to
   by its name without model.

   Some proposals come from a trailing slash, digital library perspective.  These
   include the trailing slash is
   automatically appended.  Due to this, Dublin Core [Weibel et al., 1995] metadata set and the
   Warwick Framework [Lagoze, 1996], a resource MAY accept container architecture for
   different metadata schemas.  The literature includes many examples
   of metadata, including MARC [MARC, 1994], a URI
   without a trailing "/" to point to a collection. In this case it
   SHOULD return bibliographic metadata
   format, and RFC 1807 [Lasher, Cohen, 1995], a location header in technical report
   bibliographic format employed by the response pointing to Dienst system. Additionally,
   the URL
   ending with proceedings from the "/".  For example, if a client performs an INDEX on
   http://foo.bar/blah (no trailing slash), first IEEE Metadata conference describe
   many community-specific metadata sets.

   Participants of the resource
   http://foo.bar/blah/ (trailing slash) MAY respond 1996 Metadata II Workshop in Warwick, UK
   [Lagoze, 1996], noted that "new metadata sets will develop as if the
   operation were invoked on it,
   networked infrastructure matures" and SHOULD return a location header
   with http://foo.bar/blah/ in it.

4.2. Creation "different communities will
   propose, design, and Retrieval of Collection Resources

   This document specifies the MKCOL method to create new collection
   resources, rather than using the existing HTTP/1.1 PUT or POST
   method, for the following reasons

   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 be responsible for a collection different types of
   metadata." These observations can readily be constructed corroborated by noting that
   many community-specific sets of metadata already exist, and there is
   significant motivation for use with PUT, the implications development of sending such a description to the server are
   undesirable.  For example, if a description new forms of a collection that
   omitted some existing resources were PUT to a server, this might be
   interpreted metadata
   as many communities increasingly make their data available in
   digital form, requiring a command to remove those members.  This would extend
   PUT metadata format to perform DELETE functionality, which is undesirable since it
   changes the semantics of PUT, assist data location
   and makes it difficult to control
   DELETE functionality with an access control scheme based on methods.

   While the POST method is sufficiently open-ended that cataloging.

2.3 Properties and HTTP Headers

   Properties already exist, in a _create limited sense, in HTTP message
   headers.  However, in distributed authoring environments 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
   relatively large number of POST.

   This document specifies the INDEX method for listing properties are needed to describe the contents
   state of a collection, rather than relying on the existing HTTP/1.1 GET
   method.  This resource, and setting/returning them all through HTTP
   headers is to avoid conflict with the de-facto standard
   practice of redirecting inefficient.  Thus a GET request on mechanism is needed which allows a directory
   principal to its
   index.html resource.

   The exact definition identify a set of properties in which the behavior of GET and PUT on collections principal is defined later in this document.

4.3. HTTP URL Namespace Model
   interested and to set or retrieve just those properties.

2.4 Property Values

   The HTTP URL Namespace is value of a hierarchical namespace where the
   hierarchy property is delimited with the "/" character.  DAV compliant
   resources MUST maintain the consistency of the HTTP URL namespace.
   Any attempt to create expressed as a resource (excepting the root member of well-formed XML document.

   XML has been chosen because it is a
   namespace) flexible, self-describing,
   structured data format that would not be the internal member supports rich schema definitions, and
   because of a collection
   MUST fail. For example, if the collection http://www.foo.bar.org/a/
   exists, but http://www.foo.bar.org/a/b/does 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 exist, an attempt 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
   create http://www.foo.bar.org/a/b/c must fail.

4.4. Source Resources be encoded and Output Resources

   For many resources, read in a character set
   familiar to the entity returned by user.

2.5 Property Names

   A property name is a GET method exactly
   matches universally unique identifier that is
   associated with a schema that provides information about the persistent state syntax
   and semantics of the resource, property.

   Because a property's name is universally unique, clients can depend
   upon consistent behavior for example, a GIF
   file stored particular property across multiple
   resources, so long as that property is "live" on a disk.  For this simple case, the URL at resources in
   question.

   The XML namespace mechanism, which a
   resource is accessed based on URIs, is identical used to the URL at which the source
   (the persistent state) name
   properties because it prevents namespace collisions and provides for
   varying degrees of the resource administrative control.

   The property namespace is accessed.  This flat; that is, no hierarchy of properties
   is also 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 case for HTML source files two properties.  It is expected that are not processed by the server
   prior to transmission.

   However, the server can sometimes process HTML resources before they
   are transmitted as a return entity body.  For example, server-side-
   include directives within an HTML file instruct a server separate
   specification will eventually be produced which will address issues
   relating to replace hierarchical properties.

   Finally, it is not possible to define the directive with another value, such same property twice on a
   single resource, as the current date.  In this
   case, what is returned by GET (HTML plus date) differs from would cause a collision in the
   persistent state resource's
   property namespace.

3  Collections of Web Resources

   This section provides a description of a new type of Web resource,
   the resource (HTML plus directive).  Typically
   there is no way to access the HTML resource containing the
   unprocessed directive.

   Sometimes the entity returned by GET is collection, and discusses its interactions with the output HTTP Uniform
   Resource Locator (URL) namespace. The purpose of a data-
   producing process that collection
   resource is described by one or more source resources
   (that may not even have to model collection-like objects (e.g., filesystem
   directories) within a location in server's namespace.

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

3.1 Collection Resources

   A single
   data-producing process may dynamically generate the collection is a resource whose state consists of a
   potentially large number an unordered list
   of output resources.  An example internal members, an unordered list of this is external members, and a CGI script that describes
   set of properties.  An internal member resource MUST have a "finger" gateway process URI that maps
   part of
   is immediately relative to the namespace base URI of a server into finger requests, such as
   http://www.foo.bar.org/finger_gateway/user@host.

   In the absence of distributed authoring capabilities, it is
   acceptable to have no mapping of source resource(s) to collection.  That is,
   the internal member's URI
   namespace. In fact, preventing access is equal to the source resource(s) has
   desirable security benefits.  However, if remote editing parent collection's URI
   plus an additional segment where segment is defined in Section 3.2.1
   of the
   source resource(s) RFC 2068 [Fielding et al., 1996].

   An external member resource is desired, the source resource(s) should be
   given a location in the URI namespace.  This source location should resource that could not be one of the locations at which an
   internal member resource. Any given internal or external Member MUST
   only belong to the generated output is
   retrievable, since in general collection once, i.e., it is impossible for the server illegal to
   differentiate requests for source resources from requests for
   process output resources.  There is often a many-to-many
   relationship between source resources and output resources.

   On WebDAV compliant servers, for all output resources which have a
   single source resource (and that source resource has a URI), the URI
   multiple instances of the source resource SHOULD be stored same URI in a link collection.  Properties
   defined on the output
   resource with type http://www.ietf.org/standards/dav/source.  Note collections behave exactly as do properties on non-
   collection resources.

   There is a standing convention that when a collection is referred to
   by storing the source URIs in links on the output resources,
   the burden of discovering its name without a trailing slash, the source trailing slash is placed on the authoring
   client.

5. Locking

   The ability
   automatically appended.  Due to lock this, a resource provides MAY accept a mechanism for serializing
   access URI
   without a trailing "/" to point to that resource.  Using a lock, an authoring client can
   provide collection. In this case it
   SHOULD return a reasonable guarantee that another principal will not
   modify a resource while it is being edited.  In this way, location header in the response pointing to the URL
   ending with the "/".  For example, if a client
   can prevent invokes a method on
   http://foo.bar/blah (no trailing slash), the "lost update" problem.

   This specification allows locks to vary over two client-specified
   parameters, resource
   http://foo.bar/blah/ (trailing slash) MAY respond as if the number of principals involved (exclusive vs. shared)
   operation were invoked on it, and SHOULD return a location header
   with http://foo.bar/blah/ in it.  In general clients SHOULD use the type
   "/" form of access to be granted.  Furthermore, this collection names.

3.2 Creation and Retrieval of Collection Resources

   This document
   only provides specifies the definition of locking MKCOL method to create new collection
   resources, rather than using the existing HTTP/1.1 PUT or POST
   method, for one lock access type, the write lock.  However, following reasons

   In HTTP/1.1, the syntax PUT method is extensible, and permits defined to store the
   eventual specification of other access types.

5.1. Exclusive Vs. Shared Locks

   The most basic form of lock is an exclusive lock.  This is a lock
   where request body at
   the access right in question is only granted to location specified by the Request-URI.  While a single
   principal.  The need description
   format for this arbitration results from a desire to
   avoid having to constantly merge results.

   However, there are times when collection can readily be constructed for use with PUT,
   the goal implications of sending such a lock is not to exclude
   others from exercising an access right but rather description to provide the server are
   undesirable.  For example, if a
   mechanism for principals to indicate that they intend description of a collection that
   omitted some existing resources were PUT to exercise
   their access right.  Shared locks are provided for a server, this case.  A
   shared lock allows multiple principals to receive might be
   interpreted as a lock.  Hence any
   principal 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 appropriate an access can get control scheme based on methods.

   While the lock.

   With shared locks there are two trust sets POST method is sufficiently open-ended that affect a resource.
   The first trust set "create a
   collection" POST command could be constructed, this is created by access permissions.  Principals
   who are trusted, for example, may have permission undesirable
   because it would be difficult to write the
   resource.  Those who are not, don't.  Among those who have separate access
   permission to write the resource, control for
   collection creation from other uses of POST.

   The exact definition of the set behavior of principals who have
   taken out a shared lock also must trust each other, creating GET and PUT on collections
   is defined later in this document.

3.3 HTTP URL Namespace Model

   The HTTP URL Namespace is a
   (typically) smaller trust set within hierarchical namespace where the access permission write
   set.

   Starting
   hierarchy is delimited with every possible principal on the Internet, in most
   situations "/" character.  DAV compliant
   resources MUST maintain the vast majority consistency of these principals will not have write
   access the HTTP URL namespace.
   Any attempt to create a given resource.  Of resource (excepting 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 root member of principals who
   have write permission) and use a shared lock, which informs their
   collaborators
   namespace) that would not be the internal member of a principal is potentially working on collection
   MUST fail. For example, if the
   resource.

   The WebDAV extensions to HTTP do collection http://www.foo.bar.org/a/
   exists, but http://www.foo.bar.org/a/b/does not need exist, an attempt to provide all
   create http://www.foo.bar.org/a/b/c must fail.

3.4 Source Resources and Output Resources

   For many resources, the entity returned by a GET method exactly
   matches the persistent state of the
   communications paths necessary resource, 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 example, a GIF
   file stored on a disk.  For this simple case, the screen,
   telephone conversation, Email, etc.)  The intent of URL at which a shared lock is
   to let collaborators know who else
   resource is potentially working on a
   resource.

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

   However, the server can sometimes process HTML resources before they
   are transmitted as a lock owner leaves
   without unlocking return entity body.  For example, server-side-
   include directives within an HTML file instruct a resource.  While both timeouts and
   administrative action can be used server to remove an offending lock,
   neither mechanism may be available when needed; replace
   the timeout may be
   long or directive with another value, such as the administrator may not be available.

   Despite their potential problems, exclusive write locks are
   extremely useful, since often a guarantee of freedom current date.  In this
   case, what is returned by GET (HTML plus date) differs from overwrite
   conflicts the
   persistent state of the resource (HTML plus directive).  Typically
   there is what no way to access the HTML resource containing the
   unprocessed directive.

   Sometimes the entity returned by GET is needed. This specification provides both
   exclusive write locks and the less strict mechanism output of shared locks.

5.2. Required Support

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

   The reason for this flexibility is
   a CGI script that locking policy strikes to
   the very heart describes a "finger" gateway process that maps
   part of the resource management and versioning systems
   employed by various storage repositories.  These repositories
   require control over what sort namespace 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 a server into finger requests, such as
   http://www.foo.bar.org/finger_gateway/user@host.

   In the absence of distributed authoring capabilities, it is sufficiently
   different
   acceptable to merit exclusion have no mapping of certain locking features, this
   specification leaves locking as source resource(s) to the sole axis URI
   namespace. In fact, preventing access to the source resource(s) has
   desirable security benefits.  However, if remote editing of negotiation within
   WebDAV.

5.3. Lock Tokens

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

   Lock token URIs are required server to be unique across all
   differentiate requests for source resources from requests for
   process output resources.  There is often a many-to-many
   relationship between source resources and output resources.

   On WebDAV compliant servers, for all time. This uniqueness constraint allows lock tokens to be
   submitted across output resources and servers without fear of confusion.

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

5.4. opaquelocktoken Lock Token URI Scheme

   The opaquelocktoken URI scheme is designed to source resource SHOULD be unique across all
   resources for all time.  Due to this uniqueness quality, a client
   MAY submit an opaque lock token stored in a Lock-Token request header and
   an if-state[-not]-match header link on a resource other than the one that
   returned it.

   All resources MUST recognize output
   resource with type http://www.iana.org/standards/dav/source (see
   Section 12.11 for a description of the opaquelocktoken scheme and, at
   minimum, recognize source link).  Note that the lock token was not generated by
   storing the
   resource.  Note, however, that resources are not required to
   generate opaquelocktokens source URIs in LOCK method responses.

   In order to guarantee uniqueness across all resources for all time links on the opaquelocktoken requires output resources, the use burden
   of discovering the GUID mechanism.

   Opaquelocktoken generators, however, have source is placed on the authoring client.

4  Locking

   The ability to lock a choice of how they
   create these tokens.  They can either generate resource provides a new GUID mechanism for every
   lock token they create, which is potentially very expensive, or they serializing
   access to that resource.  Using a lock, an authoring client can create
   provide a single GUID and then add extension characters.  If the
   second method is selected then the program generating the extensions
   MUST reasonable guarantee that the same extension another principal will never be used twice with
   the associated GUID.

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

5.5. Lock Capability Discovery

   Since server lock support not
   modify a resource while it is optional, being edited.  In this way, a client trying to lock a
   resource on a server
   can either try prevent the lock and hope for "lost update" problem.

   This specification allows locks to vary over two client-specified
   parameters, the best,
   or perform some form number of discovery to determine what lock
   capabilities principals involved (exclusive vs. shared)
   and the server supports.  This is known as lock capability
   discovery.  Lock capability discovery differs from discovery type of
   supported access control types, since there may to be granted. This document defines locking
   for only one access control
   types without corresponding lock types.  A client can determine what
   lock types the server supports by retrieving the supportedlock
   property.

   Any DAV compliant resource that supports the LOCK method MUST
   support type, write. However, the supportedlock property.

5.6. Active Lock Discovery

   If another principal locks a resource that a principal wishes to
   access, it syntax is useful for the second principal to be able to find out
   who the first principal is.  For this purpose extensible,
   and permits the lockdiscovery
   property eventual specification of locking for other access
   types.

4.1 Exclusive Vs. Shared Locks

   The most basic form of lock is provided. an exclusive lock.  This property lists all outstanding locks,
   describes their type, and provides their is a lock token.

   Any DAV compliant resource that supports the LOCK method MUST
   support the lockdiscovery property.

6. Write Lock

   This section describes the semantics specific to
   where the write access
   type for locks.  The write lock right in question is only granted to a specific instance single
   principal.  The need for this arbitration results from a desire to
   avoid having to constantly merge results.

   However, there are times when the goal of a lock
   type, and is the only lock type described in not to exclude
   others from exercising an access right but rather to provide a
   mechanism for principals to indicate that they intend to exercise
   their access right.  Shared locks are provided for this specification.  A
   DAV compliant resource MAY support the write lock.

6.1. Methods Restricted by Write Locks case.  A write
   shared lock prevents allows multiple principals to receive a lock.  Hence any
   principal without the lock from successfully
   executing a PUT, POST, PATCH, PROPPATCH, MOVE, DELETE, MKCOL, ADDREF
   or DELREF on the locked resource.  All other current methods, GET in
   particular, function independent of with appropriate access can get the lock.

   Note, however, that as new methods

   With shared locks there are two trust sets that affect a resource.
   The first trust set is created it will be necessary by access permissions.  Principals
   who are trusted, for example, may have permission to specify how they interact with a write lock.

6.2. Write Locks and Properties

   While the
   resource.  Those who are not, don't.  Among those without a who have access
   permission to write lock may not alter the resource, the set of principals who have
   taken out a property on shared lock also must trust each other, creating a
   resource it is still
   (typically) smaller trust set within the access permission write
   set.

   Starting with every possible for principal on the values of live properties to
   change, even while locked, due to Internet, in most
   situations the requirements vast majority of their schemas.
   Only dead properties and live properties defined to respect locks
   are guaranteed these principals will not to change while have write locked.

6.3. Write Locks and Null Resources

   It is possible
   access to assert a given resource.  Of the small number who do have write lock on a null resource in order
   access, some principals may decide to
   lock the name.  Please note, however, that locking a null resource
   effectively makes the resource non-null, as the resource now has
   lock related properties defined on it.

6.4. Write Locks and Collections

   A guarantee their edits are free
   from overwrite conflicts by using exclusive write lock on a collection prevents the addition or removal of
   members locks.  Others may
   decide they trust their collaborators will not overwrite their work
   (the potential set of collaborators being the collection.  As set of principals who
   have write permission) and use a consequence, when shared lock, which informs their
   collaborators that a principal
   issues a request may be working on the resource.

   The WebDAV extensions to create a new internal member of a collection
   using PUT or POST, or HTTP do not need to remove an existing internal member provide all of a
   collection the
   communications paths necessary for principals to coordinate their
   activities.  When using DELETE, this request MUST fail if 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 principal
   does not have screen,
   telephone conversation, Email, etc.)  The intent of a write shared lock is
   to let collaborators know who else may be working on the collection.

   However, if a resource.

   Shared locks are included because experience from web distributed
   authoring systems has indicated that exclusive write locks are often
   too rigid.  An exclusive write lock request is issued used to enforce a collection
   containing internal member resources that are currently locked in a
   manner which conflicts with the particular
   editing process: take out exclusive write lock, read the request MUST fail
   with a 409 Conflict status code.

6.5. Write Locks and COPY/MOVE

   The owner of a resource,
   perform edits, write lock MUST NOT execute a MOVE method on a
   resource he has locked. the resource, release the lock.  This specification intentionally does not
   define what happens if a MOVE method request is made on a locked
   resource by editing
   process has the lock's owner.

   A COPY method invocation MUST NOT duplicate any write problem that locks active
   on the source.

6.6. Re-issuing Write Locks

   If are not always properly released,
   for example when a principal already owns program crashes, or when a write lock on owner leaves
   without unlocking a resource, any future
   requests for the same type of write resource.  While both timeouts and
   administrative action can be used to remove an offending lock, on the same resource,
   while the principal's previous write lock is in effect, MUST result
   in a successful response with
   neither mechanism may be available when needed; the same lock token as provided for timeout may be
   long or the currently existing lock.  Two lock requests are defined to administrator may not be
   identical if available.

   Despite their Lock-Info headers potential problems, exclusive write locks are identical.

6.7. Write Locks and The Lock-Token Request Header

   If
   extremely useful, since often a user agent guarantee of freedom from overwrite
   conflicts is what is needed. This specification provides both
   exclusive write locks and the less strict mechanism of shared locks.

4.2 Required Support

   A WebDAV compliant server 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 support locking in any
   form.  If the
   lock taken out by Program A, yet performs a PUT server does support locking it MAY choose to the locked
   resource.  In this scenario, the PUT succeeds because locks are
   associated with a principal, not a program, support
   any combination of exclusive and thus program B,
   because it is acting with principal A's credential, shared locks for any access types.

   The reason for this flexibility is allowed to
   perform the PUT.  However, had program B known about the lock, it
   would not have overwritten the resource, preferring instead that locking policy strikes to
   present a dialog box describing
   the conflict to very heart of the user.  Due to
   this scenario, a mechanism 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 needed to prevent sufficiently
   different programs
   from accidentally ignoring locks taken out by other programs with
   the same authorization.

   In order to prevent these collisions merit exclusion of certain locking features, this
   specification leaves locking as the sole axis of negotiation within
   WebDAV.

4.3 Lock Tokens

   A lock token request header is introduced.  Please refer to the Lock Token Request Header
   section for details and requirements.

6.7.1. Write Lock Token Example

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

   HTTP/1.1 200 OK

   In this example, both a URI that identifies a particular lock.  A lock
   token is returned by every successful LOCK operation in the source Lock-
   Token response header, and destination can also be discovered through lock
   discovery on a resource.

   Lock token URIs are locked so two required to be unique across all resources for
   all time. This uniqueness constraint allows lock tokens must to be submitted.  If only one
   submitted across resources and servers without fear of confusion.

   This specification provides a lock token URI scheme called
   opaquelocktoken that meets the two uniqueness requirements.  However
   resources was
   locked, then only one token would have are free to return any URI scheme so long as it meets the
   uniqueness requirements.

4.4 opaquelocktoken Lock Token URI Scheme

   The opaquelocktoken URI scheme is designed to be submitted.

7. Notational Conventions

   Since unique across all
   resources for all time.  Due to this document describes uniqueness quality, a set of extensions to client
   MAY submit an opaque lock token in a Lock-Token request header and
   an If-[None]-State-Match header on a resource other than the HTTP/1.1
   protocol, one
   that returned it.

   All resources MUST recognize the augmented BNF used herein opaquelocktoken scheme and, at
   minimum, recognize that the lock token was not generated by the
   resource.  Note, however, that resources are not required to describe protocol
   elements is exactly
   generate opaquelocktokens in LOCK method responses.

   In order to guarantee uniqueness across all resources for all time
   the same opaquelocktoken requires the use of the Universally Unique
   Identifier (UUID, also known as a Globally Unique Identifier, or
   GUID) mechanism, as described in Section 2.1 [Leach, Salz, 1998].

   Opaquelocktoken generators, however, have a choice of RFC
   2068, _Hypertext Transfer Protocol -- HTTP/1.1_ [Fielding et al.,
   1997].  Since this augmented BNF uses the basic production rules
   provided in Section 2.2 of RFC 2068, how they
   create these rules apply to this
   document as well.

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

8. HTTP Methods tokens.  They can either generate a new UUID for Distributed Authoring

8.1. PROPFIND

   The PROPFIND method retrieves properties defined on the Request-URI,
   if it every
   lock token they create, which is a non-collection resource, potentially very expensive, or on the Request-URI they
   can create a single UUID and
   potentially its member resources, if then add extension characters.  If the resource
   second method is a collection.
   All DAV compliant resources MUST support selected then the PROPFIND method.

   A client MAY submit a Depth header with a PROPFIND on a collection
   with a value of "0", "1" or "infinity".  DAV compliant servers program generating the extensions
   MUST
   support guarantee that the "0", "1" and "infinity" behaviors. By default, same extension will never be used twice with
   the
   PROPFIND method on a collection without a Depth header MUST act as
   if a Depth associated UUID.

   OpaqueLockToken-URI = infinity header was included.

   A client MUST submit a Propfind request header describing what
   information is being requested.  It "opaquelocktoken:" UUID [Extension]  ; The
   UUID production is possible to request
   particular property values, all property values, or a list of the
   names string form of the resource's properties.

   The response is a text/xml message body that contains a multistatus
   XML element UUID, as defined in [Leach,
   Salz, 1998]. Note that describes the results white space (LWS) is not allowed between
   elements of the attempts this production.

   Extension = path  ; path is defined in Section 3.2.1 of RFC 2068
   [Fielding et al., 1996]

4.5 Lock Capability Discovery

   Since server lock support is optional, a client trying to retrieve
   the various properties.  If lock a property was successfully retrieved
   then its value MUST be returned in
   resource on a prop XML element.  If server can either try the scope lock and hope for the best,
   or perform some form of PROPFIND covers more than a single resource, as is discovery to determine what lock
   capabilities the case with
   Depth values server supports.  This is known as lock capability
   discovery.  Lock capability discovery differs from discovery of "1" and "infinity", each response XML element MUST
   contain an href XML element which identifies
   supported access control types, since there may be access control
   types without corresponding lock types.  A client can determine what
   lock types the resource on which server supports by retrieving the properties in supportedlock
   property.

   Any DAV compliant resource that supports the prop XML element are defined. In LOCK method MUST
   support the case of
   allprop and propname, if supportedlock property.

4.6 Active Lock Discovery

   If another principal locks a resource that a principal does not have wishes to
   access, it is useful for the right second principal to know
   if a particular property exists, an error MUST NOT be returned.  The
   results of 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 provides their lock token.

   Any DAV compliant resource that supports the LOCK method SHOULD NOT be cached.

8.1.1. Example: Retrieving Named Properties

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

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

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

   In this example, PROPFIND is executed on

5  Write Lock

   This section describes the collection
   http://www.foo.bar/files/. semantics specific to the write access
   type for locks.  The specified depth write lock is a specific instance of a lock
   type, and is zero, hence the
   PROPFIND applies only to lock type described in this specification.  A
   DAV compliant resource MAY support the collection itself, write lock.

5.1 Methods Restricted by Write Locks

   A write lock prevents a principal without the lock from successfully
   executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, MKCOL,
   ADDREF or DELREF on the locked resource.  All other current methods,
   GET in particular, function independent of the lock.

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

5.2 Write Locks and Properties

   While those without a write lock may not to any alter a property on a
   resource it is still possible for the values of
   its members.  The Propfind header specifies live properties to
   change, even while locked, due to the name requirements of four their schemas.
   Only dead properties whose values are being requested. In this case only two and live properties were returned, since the principal issuing the request
   did defined to respect locks
   are guaranteed not have sufficient access rights to see the third change while write locked.

5.3 Write Locks and fourth
   properties.

8.1.2. Example: Using allprop Null Resources

   It is possible to Retrieve All Properties

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

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

   <?XML version="1.0">
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "S"?>
   <?namespace href = "http://www.foo.bar/boxschema/" AS = R"?>
   <S:multistatus>
     <S:response>
          <S:href>http://www.foo.bar/container/</S:href>
          <S:prop>
               <R:bigbox>
                    <R:BoxType>Box type A</R:BoxType>
               </R:bigbox>
               <R:author>
                    <R:Name>Hadrian</R:Name>
               </R:author>
          </S:prop>
          <S:status>HTTP 1.1 200 OK</S:status>
     </S:response>
     <S:response>
          <S:href>http://www.foo.bar/container/index.html</S:href>
          <S:prop>
               <R:bigbox>
                    <R:BoxType>Box type B</R:BoxType>
               </R:bigbox>
          </S:prop>
          <S:status>HTTP 1.1 200 OK</S:status>
     </S:response>
   </S:multistatus>
   In this example, PROPFIND was invoked assert a write lock on the resource
   http://www.foo.bar/container/ with a Depth header of 1, meaning the
   request applies null resource in order to
   lock the name.  A write locked null resource acts in all ways as a
   null resource other than it MUST respond to a PROPFIND request and its children,
   MUST support the lockdiscovery and supportedlock properties.

   Until a Propfind
   header of "allprop", meaning method such as PUT or MKCOL is executed, the request should return resource stays
   in the name and
   value null state with the exception of all properties defined on each resource.

   The resource http://www.foo.bar/container/ has two properties
   defined on it, named http://www.foo.bar/boxschema/bigbox, and
   http://www.foo.bar/boxschema/author, while the behavior stated above.

   If the resource
   http://www.foo.bar/container/index.html has only is unlocked without a single PUT, MKCOL, or similar method
   having been executed, the resource
   defined is no longer required to support
   the PROPFIND method or the lockdiscovery and supportedlock
   properties.

5.4 Write Locks and Collections

   A write lock on it, named http://www.foo.bar/boxschema/bigbox, another
   instance a collection prevents the addition or removal of
   members of the "bigbox" property type.

8.1.3. Example: Using propname to Retrieve all Property Names

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

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

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

   In this example, PROPFIND is invoked on the collection resource
   http://www.foo.bar/container/, with by non-lock owners.  As a Propfind header set consequence,
   when a principal issues a request to
   "propname", meaning the name of all properties should be returned.
   Since no depth header is present, it assumes its default value create a new internal member of
   "infinity", meaning the name
   a write locked collection using PUT or POST, or to remove an
   existing internal member of a write locked collection using DELETE,
   this request MUST fail if the properties principal does not have a write lock
   on the collection.

   However, if a write lock request is issued to a collection and
   all its progeny should be returned.

   Consistent
   containing internal member resources that are currently locked in a
   manner which conflicts with the previous example, resource
   http://www.foo.bar/container/ has two properties defined on it,
   http://www.foo.bar/boxschema/bigbox, and
   http://www.foo.bar/boxschema/author.  The resource
   http://www.foo.bar/container/index.html, write lock, the request MUST fail
   with a 425 Locked status code.

   If a lock owner causes a resource to be added as an internal member
   of a locked collection then the "container"
   collection, has only one property defined on it,
   http://www.foo.bar/boxschema/bigbox.

8.2. PROPPATCH

   The PROPPATCH method processes instructions specified in the request
   body new resource is automatically added
   to set and/or remove properties defined on the lock.  This is the only mechanism that allows a resource
   identified by Request-URI.

   All DAV compliant resources MUST support the PROPPATCH method and
   MUST process instructions that are specified using to

   be added to a write lock.  Thus, for example, if the
   propertyupdate, set, collection
   /a/b/ is write locked and remove XML elements of the DAV schema.
   Execution of the directives in this method is, of course, subject resource /c is moved to /a/b/c then
   /a/b/c will be added to
   access control constraints.  DAV compliant resources MUST support the setting of arbitrary dead properties.

   The request message body of a PROPPATCH write lock.

5.5 Write Locks and COPY/MOVE

   A COPY method invocation MUST contain at least
   one propertyupdate XML element.  Instruction processing MUST occur
   in NOT duplicate any write locks active
   on the order instructions are received (i.e., from top to bottom),
   and MUST be performed atomically.

8.2.1. propertyupdate XML element

   Name:       propertyupdate
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To contain a request to alter source.  However, as previously noted, if the properties on COPY copies the
   resource into a
   resource.
   Parent:     None
   Values=     1*(set | remove)
   Description: This XML element collection that is a container for depth locked then the information
   required resource
   will be added to modify the properties on lock.

   A MOVE does not move the write lock with the resource.  This XML element
   is multi-valued.

8.2.2. set XML element

   Name:       set
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To set There are two
   exceptions to this rule. First, as noted in section 5.4, if the DAV properties specified inside MOVE
   makes the set XML
   element.
   Parent:     propertyupdate
   Values=     prop
   Description: This XML element MUST contain only resource a prop XML element.
   The elements contained by prop specify the name and value child of
   properties that are set on the Request-URI.  If a property already
   exists then its value collection that is replaced.

8.2.3. remove XML element

   Name:       remove
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To remove the DAV properties specified inside the remove
   XML element.
   Parent:     propertyupdate
   Values=     prop
   Description: Remove specifies that depth locked then
   the properties specified in prop
   should resource will be removed.  Specifying under the removal of same lock. Second, if a property depth locked
   resource is moved to a destination that does
   not exist is not an error.  All the elements in prop MUST be empty,
   as only within the names scope of properties to be removed are required.

8.2.4. Response Codes

   200 OK - The command succeeded.  As there can be the
   same depth lock (e.g., within the namespace tree covered by the
   lock), the moved resource is still a mixture member of sets
   and removes in the lock. In both
   cases a body, Lock-Token header MUST be submitted containing a 201 Create seems inappropriate.

   403 Forbidden - The client, lock token
   for reasons the server chooses not to
   specify, cannot alter one of lock on the properties.

   405 Conflict - The source, if locked, and on the destination.

5.6 Refreshing Write Locks

   A client has provided MUST NOT submit the same write lock request twice.  Note
   that a value whose semantics are
   not appropriate for client is always aware it is resubmitting the property.  This includes trying same lock
   request because it must include the Lock-Token header in order to set read-
   only properties.

   413 Request Entity Too Long - If
   make the request for a particular property resource that is too long
   to be recorded then already locked.

   However, a composite XML error will client MAY submit a LOCK method with a Lock-Token header
   but without a body.  This form of LOCK MAY only be returned
   indicating the offending property.

8.2.5. Example

   PROPPATCH /bar.html HTTP/1.1
   Host: www.foo.com
   Content-Type: text/xml
   Content-Length: xxxx

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

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

   In this example, the client requests used to "refresh"
   a lock.  Currently, refreshing a lock only means that any timers
   associated with the lock are re-set.

   A server to set MAY return a Timeout header with a lock refresh that is
   different than the value 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 http://www.w3.com/standards/z39.50/Authors property, and
   client.

   If an error is received in response to
   remove the property http://www.w3.com/standards/z39.50/Copyright-
   Owner.  Since a refresh LOCK request the Copyright-Owner property could not be removed, no
   property modifications occur.  The Method Failure response code for
   client MUST assume that the Authors property indicates this action would have succeeded if
   it were lock was not for the conflict with removing the Copyright-Owner
   property.

8.3. MKCOL Method refreshed.

5.7 Write Locks and The MKCOL method Lock-Token Request Header

   If a user agent is used not required to create have knowledge about a new collection. All DAV
   compliant resources MUST support the MKCOL method.

8.3.1. Request

   MKCOL creates lock when
   requesting an operation on a new collection resource at locked resource, the location specified following scenario
   might occur.  Program A, run by
   the Request-URI.  If the Request-URI exists, then MKCOL must fail.
   During MKCOL processing, User A, takes out a server MUST make the Request-URI write lock on a member
   of its parent collection.  If
   resource.  Program B, also run by User A, has no such ancestor exists, the method
   MUST fail.  When the MKCOL operation creates a new collection
   resource, all ancestors MUST already exist, or knowledge of the method MUST fail
   with a 409 Conflict status code.  For example, if
   lock taken out by Program A, yet performs a request PUT to
   create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/
   exists, the request MUST fail.

   When MKCOL is invoked without a request body, locked
   resource.  In this scenario, the newly created
   collection has no members.

   A MKCOL request message MAY contain PUT succeeds because locks are
   associated with a message body.  The behavior of principal, not a MKCOL request when the body program, and thus program B,
   because it is present acting with principal A's credential, is limited allowed to creating
   collections, members of a collection, bodies of members and
   properties on
   perform the collections or members.  If PUT.  However, had program B known about the server receives a
   MKCOL request entity type lock, it does
   would not support or understand it MUST
   respond with have overwritten the resource, preferring instead to
   present a 415 Unsupported Media Type status code.  The exact
   behavior of MKCOL for various request media types is undefined in dialog box describing the conflict to the user.  Due to
   this document, and will be specified in separate documents.

8.3.2. Response Codes

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

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

   403 Forbidden - This indicates at least one of two conditions: 1)
   The server does not allow mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by other programs with
   the creation of collections at same authorization.

   In order to prevent these collisions the given
   location Lock-Token request header,
   defined in its namespace, and 2) The parent collection of Section 8.7, is introduced.

5.7.1     Write Lock Token Example

   >>Request

   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   Lock-Token: <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
   Authorization: Digest username="fielding",
      realm="fielding@ics.uci.edu", nonce="...",
      uri="/~fielding/index.html", response="...",
      opaque="..."

   >>Response

   HTTP/1.1 204 No Content

   In this example, even though both the
   Request-URI exists but cannot accept members.

   405 Method Not Allowed - MKCOL can source and destination are
   locked, only one lock token must be executed submitted, for the lock on the
   destination.  This is due to the source resource not being modified
   during a
   deleted/non-existent resource.

   409 Conflict - A collection cannot be made at COPY, and hence unaffected by the Request-URI until
   one or more intermediate collections have been created.

   415 Unsupported Media Type- write lock. The server does not support
   Authorization header provides the Digest authentication credentials
   for the principal making the request
   type of (note that the body.

   419 Insufficient Space on Resource - The resource does not nonce, response,
   and opaque fields have
   sufficient space to record the state of not been calculated for this example). The
   source and the resource after destination resources are both located within the
   execution
   same authentication realm, therefore only one set of Authorization
   credentials needs to be submitted.

6  Notational Conventions

   Since this method.

8.3.3. Example

   This example creates document describes a collection called /webdisc/xfiles/ on set of extensions to the
   server www.server.org.

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

8.4. INDEX Method

   The INDEX method is
   protocol, the augmented BNF used herein to enumerate describe protocol
   elements is exactly the members same as described in Section 2.1 of a resource.
   All DAV compliant resources MUST support
   [Fielding et al., 1997].  Since this augmented BNF uses the INDEX basic
   production rules provided in Section 2.2 of [Fielding et al., 1997],
   these rules apply to this document as well.

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

7  HTTP Methods for Distributed Authoring

7.1 PROPFIND

   The PROPFIND method retrieves properties defined on the Request-URI,
   if they the resource does not have members.

8.4.1. The Request

   For a collection, INDEX MUST return a list of any internal members, or on the
   Request-URI and potentially its member resources, if the resource
   does have internal members.  All
   WebDAV DAV compliant resources MUST
   support the text/xml response entity
   described below.  The INDEX result for a collection PROPFIND method.

   A client MAY also return submit a list Depth header with a value of "0", "1", or
   "infinity" with a PROPFIND on a resource with internal members.  DAV
   compliant servers MUST support the members of child collections, to any depth.

   Collections that respond to an INDEX "0", "1" and "infinity"
   behaviors. By default, the PROPFIND method with without a text/xml entity Depth header
   MUST contain act as if a single multistatus XML element which contains "Depth: infinity" header was included.

   A client MAY submit a
   response propfind XML element for each member.

   A resource that supports INDEX MUST return in the resourcetype property
   for each member.

   Note that body of the prop XML element MAY contain additional properties.

8.4.2. Example

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

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

   <?XML version="1.0">
   <?namespace href = _http://www.ietf.org/standards/dav/_ as = _D_?>
   <D:multistatus>
     <D:response>
          <D:href>http://www.microsoft.com/user/yarong/dav_drafts/
          </D:href>
          <D:prop>
               <D:resourcetype>
                    <D:collection/>
               </D:resourcetype>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
     <D:response>
          <D:href>
          http://www.microsoft.com/user/yarong/dav_drafts/base
          </D:href>
          <D:prop>
               <D:resourcetype/>
          </D:prop>
          <D:status>HTTP 1.1 200 OK</D:status>
     </D:response>
   </D:multistatus>
8.5. ADDREF Method

   The ADDREF
   request method describing what information is used to add external members being requested.  It
   is possible to request particular property values, all property
   values, or a resource.
   All DAV compliant collection resources MUST support list of the ADDREF
   method.  All other DAV compliant resources MAY support names of the ADDREF
   method resource's properties.  A
   client MAY choose not to submit a request body.  An empty request
   body MUST be treated as appropriate.

8.5.1. The Request a request for the names and values of all
   properties.

   The ADDREF method adds response is a text/xml message body that contains a multistatus
   XML element that describes the URI specified in results of the Collection-Member
   header as an external member attempts to retrieve
   the collection specified by the
   Request-URI.  The various properties.  If a property was successfully retrieved
   then its value in the Collection-Member header MUST be returned in a prop XML element.

   If there is an
   absolute URI meeting error retrieving a property then a proper error
   result must be included.  Requests to retrieve the requirements value of an external member URI.

   It is a
   property which does not exist is an error if the URI specified in and MUST be noted with a
   response XML element which contains a 404 Not Found status value.

   Consequently, the Collection-Member
   header already exists as an external multistatus XML element for a resource with
   members MUST include a response XML element for each member of the collection.
   However, after processing the ADDREF there
   resource, to whatever depth was requested. Each response XML element
   MUST be only one instance
   of the URI in contain an href XML element that identifies the collection.  If resource on
   which the URI specified properties in the
   Collection-Member header already exists as an prop XML element are defined.  Results
   for a PROPFIND on a resource with internal member members are returned as a
   flat list whose order of entries is not significant.

   In the
   collection, case of allprop and propname, if a principal does not have
   the ADDREF method MUST fail with right to know if a 412 Precondition
   Failed status code.

8.5.2. Example

   ADDREF /~ejw/dav/ particular property exists then a 404 Not
   Found MUST be returned.

   The results of this method SHOULD NOT be cached.

7.1.1     Example: Retrieving Named Properties

   >>Request

   PROPFIND  /files/ HTTP/1.1
   Host: www.ics.uci.edu
   Collection-Member: http://www.ietf.org/standards/dav/ www.foo.bar
   Depth: 0
   Content-type: text/xml
   Content-Length: xyz

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:href>http://www.foo.bar/boxschema/bigbox</D:href>
     <D:href>http://www.foo.bar/boxschema/author</D:href>
     <D:href>http://www.foo.bar/boxschema/DingALing</D:href>
     <D:href>http://www.foo.bar/boxschema/Random</D:href>
   </D:propfind>

   >>Response

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

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.foo.bar/boxschema" as="R"?>
   <D:multistatus>
     <D:response>
          <D:href>http://www.foo.bar/files/</D:href>
          <D:propstat>
               <D:prop>
                    <R:bigbox>
                         <R:BoxType>Box type A</R:BoxType>
                    </R:bigbox>
                    <R:author>
                         <R:Name>J.J. Johnson</R:Name>
                    </R:author>
               </D:prop>
               <D:status>HTTP/1.1 200 OK

   This example adds 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 URI http://www.ietf.org/standards/dav/ as DingALing property.
               </D:responsedescription>
          </D:propstat>
     </D:response>
     <D:responsedescription> There has been an
   external member resource of access violation error.
     </D:responsedescription>
   </D:multistatus>

   In this example, PROPFIND is executed on the collection
   http://www.ics.uci.edu/~ejw/dav/.

8.6. DELREF Method
   http://www.foo.bar/files/.  The DELREF method specified depth is used to remove external members from a
   resource.  All DAV compliant collection resources MUST support the
   DELREF method.  All other DAV compliant resources MUST support zero, hence the
   DELREF method
   PROPFIND applies only if they support to the ADDREF method.

8.6.1. The Request collection itself, and not to any of
   its members.  The DELREF method removes the URI specified in propfind XML element specifies the Collection-Member
   header from name of four
   properties whose values are being requested. In this case only two
   properties were returned, since the collection specified by principal issuing the Request-URI.

   DELREFing a URI which is request
   did not a member of have sufficient access rights to see the collection is not an
   error.  DELREFing an internal member MUST fail with a 412
   Precondition Failed status code.

8.6.2. Example

   DELREF /~ejw/dav/ third and fourth
   properties.

7.1.2     Example: Using allprop to Retrieve All Properties

   >>Request

   PROPFIND  /container/ HTTP/1.1
   Host: www.ics.udi.edu
   Collection-Member: http://www.ietf.org/standards/dav/ www.foo.bar
   Depth: 1
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:allprop/>
   </D:propfind>

   >>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx
   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="S"?>
   <?namespace href="http://www.foo.bar/boxschema/" as="R"?>
   <S:multistatus>
     <S:response>
          <S:href>http://www.foo.bar/container/</S:href>
          <S:propstat>
               <S:prop>
                    <R:bigbox>
                         <R:BoxType>Box type A</R:BoxType>
                    </R:bigbox>
                    <R:author>
                         <R:Name>Hadrian</R:Name>
                    </R:author>
                   <S:creationdate>
                     1997-12-01T17:42:21-08:00
                   </S:creationdate>
                   <S:displayname>
                     Example collection
                   </S:displayname>
                   <S:externalmembers>
                     <S:href>http://www.acme.com/front/</S:href>
                   </S:externalmembers>
                   <S:resourcetype><S:collection/></S:resourcetype>
                   <S:supportedlock>
                     <S:lockentry>
                       <S:exclusive/><S:write/>
                     </S:lockentry>
                     <S:lockentry>
                       <S:shared/><S:write/>
                     </S:lockentry>
                   </S:supportedlock>
               </S:prop>
               <S:status>HTTP 1.1 200 OK

   This example removes the URI http://www.ietf.org/standards/dav/, an
   external member resource, from OK</S:status>
          </S:propstat>
     </S:response>
     <S:response>
          <S:href>http://www.foo.bar/container/front.html</S:href>
          <S:propstat>
               <S:prop>
                    <R:bigbox>
                         <R:BoxType>Box type B</R:BoxType>
                    </R:bigbox>
                   <S:creationdate>
                     1997-12-01T18:27:21-08:00
                   </S:creationdate>
                   <S:displayname>
                     Example HTML resource
                   </S:displayname>
                   <S:getcontentlength>
                     4525
                   </S:getcontentlength>
                   <S:getcontenttype>
                     text/html
                   </S:getcontenttype>
                   <S:getetag>
                     zzyzx
                      </S:getetag>
                   <S:getlastmodified>
                     Monday, 12-Jan-98 09:25:56 GMT
                   </S:getlastmodified>
                   <S:resourcetype/>
                   <S:supportedlock>
                     <S:lockentry>
                       <S:exclusive/><S:write/>
                     </S:lockentry>
                     <S:lockentry>
                       <S:shared/><S:write/>
                     </S:lockentry>
                   </S:supportedlock>
               </S:prop>
               <S:status>HTTP 1.1 200 OK</S:status>
          </S:propstat>
     </S:response>
   </S:multistatus>

   In this example, PROPFIND was invoked on the collection
   http://www.ics.uci.edu/~ejw/dav/.

8.7. GET, HEAD for Collections

   The semantics of GET are unchanged when applied to resource
   http://www.foo.bar/container/ with a collection,
   since GET is defined as, _retrieve whatever information (in the form Depth header of an entity) is identified by 1, meaning the Request-URI_ [Fielding et al.,
   1997].  GET when applied
   request applies to a collection MAY return the contents of
   an _index.html_ resource, resource and its children, and a human-readable view of propfind XML
   element containing the contents of allprop XML element, meaning the collection, or something else altogether, and hence it is
   possible request
   should return the result name and value of a GET on a collection will bear no
   correlation to the state of the collection.

   Similarly, since the definition of HEAD is a GET without a response
   message body, the semantics of HEAD all properties defined on each
   resource.

   The resource http://www.foo.bar/container/ has seven properties
   defined on it, named http://www.foo.bar/boxschema/bigbox,
   http://www.foo.bar/boxschema/author,
   http://www.iana.org/standards/dav/creationdate,
   http://www.iana.org/standards/dav/displayname,
   http://www.iana.org/standards/dav/externalmembers,
   http://www.iana.org/standards/dav/resourcetype, and
   http://www.iana.org/standards/dav/supportedlock.  The last five
   properties are unmodified when applied to
   collection resources.

8.8. POST for Collections WebDAV-specific, defined in Section 12.  Since by definition the actual function performed by POST GET is
   determined by the server and often depends
   not supported on the particular this resource, the behavior of POST when applied to collections cannot be
   meaningfully modified because it is largely undefined.  Thus the
   semantics of POST get-* properties (e.g., get-
   content-length) are unmodified when applied to a collection.

8.9. DELETE

8.9.1. DELETE Method for Non-Collection Resources

   If the DELETE method is issued to not defined on this resource. The DAV-specific
   properties assert that "container" was created on December 1, 1997,
   at 5:42:21PM, in a non-collection resource which is
   an internal member time zone 8 hours west of GMT (creationdate), has
   a collection, then during DELETE processing a
   server MUST remove the Request-URI from its parent collection.  A
   server MAY remove the URI name of "Example collection" (displayname), a deleted single external
   member resource, http://www.acme.com/front/ (externalmembers), a
   collection resource from any collections type (resourcetype), and supports exclusive
   write and shared write locks (supportedlock).

   The resource http://www.foo.bar/container/front.html has nine
   properties defined on it, named http://www.foo.bar/boxschema/bigbox
   (another instance of which the resource is an external member.

8.9.2. DELETE for Collections "bigbox" property type),
   http://www.iana.org/standards/dav/creationdate,
   http://www.iana.org/standards/dav/displayname,
   http://www.iana.org/standards/dav/getcontentlength,
   http://www.iana.org/standards/dav/getcontenttype,
   http://www.iana.org/standards/dav/getetag,
   http://www.iana.org/standards/dav/getlastmodified,
   http://www.iana.org/standards/dav/resourcetype, and
   http://www.iana.org/standards/dav/supportedlock.  The DELETE method on a collection MUST act as if a Depth = Infinity
   header DAV-specific
   properties assert that "front.html" was used created on it.  A client MUST NOT submit December 1, 1997,
   at 6:27:21PM, in a Depth header on time zone 8 hours west of GMT (creationdate), has
   a
   DELETE on name of "Example HTML resource" (displayname), a collection with any value but Infinity.

   DELETE instructs that the collection specified in the request-URI,
   the records of its external member resources, and all its internal
   member resources, are to be deleted.

   If any member cannot be deleted then all content length of the member's progeny
   MUST NOT be deleted, so as to maintain the namespace.

   Any headers included with DELETE MUST be applied in processing every
   resource to be deleted.  In this case,
   4525 (getcontentlength), a header MIME type of special interest
   is the Destroy header, which specifies the method to be used to
   delete all resources in the scope "text/html"
   (getcontenttype), an entity tag of the DELETE.

   When the DELETE method "zzyzx" (getetag), was last
   modified on Monday, January 12, 1998, at 09:25:56 GMT
   (getlastmodified), has completed processing an undefined resource type, meaning that it MUST return a
   consistent namespace.

   The response SHOULD be
   is not a Multi-Status response that describes the
   result of the DELETE on each affected resource.

8.9.2.1. Example

   DELETE collection (resourcetype), and supports both exclusive
   write and shared write locks (supportedlock).

7.1.3     Example: Using propname to Retrieve all Property Names

   >>Request

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

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:propname/>
   </D:propfind>

   >>Response

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

   <?XML version="1.0"> xxxx

   <?xml version="1.0"?>
   <?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
   <d:multistatus>
     <d:response>
          <d:href>http://www.foo.bar/container/resource1</d:href>
          <d:href>http://www.foo.bar/container/resource2</d:href>
          <d:status>HTTP/1.1 href="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.foo.bar/boxschema/" as="R"?>
   <D:multistatus>
     <D:response>
          <D:href>http://www.foo.bar/container/</D:href>
          <D:propstat>
               <D:prop>
                    <R:bigbox/>
                    <R:author/>
                   <D:creationdate/>
                   <D:displayname/>
                   <D:externalmembers/>
                   <D:resourcetype/>
                   <D:supportedlock/>
               </D:prop>
               <D:status>HTTP 1.1 200 OK</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/</d:href>
          <d:status>HTTP/1.1 420 Method Failure</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/resource3</d:href>
          <d:status>HTTP/1.1 412 Precondition Failed</d:status>
     </d:response>
   </d:multistatus> OK</D:status>
          </D:propstat>
     </D:response>
     <D:response>
          <D:href>http://www.foo.bar/container/front.html</D:href>
          <D:propstat>
               <D:prop>
                    <R:bigbox/>
                   <D:creationdate/>
                   <D:displayname/>
                   <D:get-content-length/>
                   <D:get-content-type/>
                   <D:get-etag/>
                   <D:get-last-modified/>
                   <D:resourcetype/>
                   <D:supportedlock/>
               </D:prop>
               <D:status>HTTP 1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

   In this example the attempt to delete
   http://www.foo.bar/container/resource3 failed because example, PROPFIND is invoked on the server was
   unable to guarantee that resource3 would not be able to be
   undeleted.  Consequently, collection resource
   http://www.foo.bar/container/, with a propfind XML element
   containing the attempt to delete
   http://www.foo.bar/container/ also failed, but resource1 and
   resource2 were deleted. Even though a Depth header has not been
   included, a depth of infinity is assumed because propname XML element, meaning the method is on a
   collection. As this example illustrates, DELETE processing need not name of all
   properties should be atomic.

8.10. PUT

8.10.1. PUT for Non-Collection Resources

   A PUT performed on an existing resource replaces returned.  Since no depth header is present, it
   assumes its default value of "infinity", meaning the GET response
   entity name of the resource.  Properties defined
   properties on the resource MAY collection and all its progeny should be
   recomputed during PUT processing.  For returned.

   Consistent with the previous example, if resource
   http://www.foo.bar/container/ has seven properties defined on it,
   http://www.foo.bar/boxschema/bigbox, and
   http://www.foo.bar/boxschema/author,
   http://www.iana.org/standards/dav/creationdate,
   http://www.iana.org/standards/dav/displayname,
   http://www.iana.org/standards/dav/externalmembers,
   http://www.iana.org/standards/dav/resourcetype, and
   http://www.iana.org/standards/dav/supportedlock.  The resource
   http://www.foo.bar/container/index.html, a server
   recognizes the content type member of the "container"
   collection, has nine properties defined on it,
   http://www.foo.bar/boxschema/bigbox,
   http://www.iana.org/standards/dav/creationdate,
   http://www.iana.org/standards/dav/displayname,
   http://www.iana.org/standards/dav/get-content-length,
   http://www.iana.org/standards/dav/get-content-type,
   http://www.iana.org/standards/dav/get-etag,
   http://www.iana.org/standards/dav/get-last-modified,
   http://www.iana.org/standards/dav/resourcetype, and
   http://www.iana.org/standards/dav/supportedlock.

7.2 PROPPATCH

   The PROPPATCH method processes instructions specified in the request body, it may be able
   body to
   automatically extract information that could be profitably exposed
   as properties.

   A PUT that would result in set and/or remove properties defined on the creation of a resource without an
   appropriately scoped parent collection
   identified by Request-URI.

   All DAV compliant resources MUST fail with a 405 Method
   Not Allowed.

8.10.2. PUT for Collections

   As defined in the HTTP/1.1 specification [Fielding et al., 1997], support the "PUT PROPPATCH method requests and
   MUST process instructions that are specified using the enclosed entity be stored under
   the supplied Request-URI."  Since submission of an entity
   representing a collection would implicitly encode creation
   propertyupdate, set, and
   deletion remove XML elements of resources, the DAV schema.
   Execution of the directives in this specification intentionally does not
   define a transmission format for creating a collection using PUT.
   Instead, method is, of course, subject to
   access control constraints.  DAV compliant resources SHOULD support
   the MKCOL setting of arbitrary dead properties.

   The request message body of a PROPPATCH method is defined MUST contain at least
   one propertyupdate XML element. Instruction processing MUST occur in
   the order instructions are received (i.e., from top to create collections.  If bottom).
   Instructions MUST either all be executed or none executed. Thus if
   any error occurs during processing all executed instructions MUST be
   undone and a
   PUT proper error result returned. Instruction processing

   details can be found in the definition of the set and remove
   instructions in Section 11.13.

   If PROPPATCH is invoked on a collection resource it MUST fail.

   When the PUT operation creates a new non-collection null resource all
   ancestors MUST already exist.  If all ancestors do not exist, the
   method MUST fail with (e.g., a 409 Conflict status code.  For example, if deleted
   resource), an empty resource /a/b/c/d.html is to be created created, and /a/b/c/ does not exist,
   then the request must fail.

8.11. COPY Method PROPPATCH
   directives are performed on this new resource.

7.2.1     Status Codes

   200 OK - The COPY method creates command succeeded.  As there can be a duplicate mixture of the specified resource.  All
   DAV compliant resources MUST support the COPY method.

   Support sets
   and removes in a body, a 201 Created seems inappropriate.

   403 Forbidden - The client, for reasons the COPY method does server chooses not guarantee the ability to copy a
   resource. For example, separate programs may control resources on
   specify, cannot alter one of the same server.  As properties.

   409 Conflict - The client has provided a result, it may not even be possible value whose semantics are
   not appropriate for the property.  This includes trying to copy set read-
   only properties.

   413 Request Entity Too Long - If a
   resource particular property is too long
   to be recorded then a location that appears to composite XML error will be on returned
   indicating the same server.

8.11.1. The Request

   The COPY method creates a duplicate of offending property.

7.2.2     Example

   >>Request

   PROPPATCH /bar.html HTTP/1.1
   Host: www.foo.com
   Content-Type: text/xml
   Content-Length: xxxx

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.w3.com/standards/z39.50/" as="Z"?>
   <D:propertyupdate>
     <D:set>
          <D:prop>
               <Z:authors>
                    <Z:Author>Jim Whitehead</Z:Author>
                    <Z:Author>Roy Fielding</Z:Author>
               </Z:authors>
          </D:prop>
     </D:set>
     <D:remove>
          <D:prop><Z:Copyright-Owner/></D:prop>
     </D:remove>
   </D:propertyupdate>

   >>Response

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

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

   In this example, the source resource, given by client requests the Request-URI, in server to set the destination resource, given by value of
   the
   Destination header.  The Destination header MUST 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 present. removed, no
   property modifications occur.  The
   exact behavior of Method Failure status code for
   the COPY method depends on Authors property indicates this action would have succeeded if
   it were not for the type of conflict with removing the source
   resource.

8.11.1.1. COPY for HTTP/1.1 Copyright-Owner
   property.

7.3 MKCOL Method

   The MKCOL method is used to create a new collection. All DAV
   compliant resources

   When MUST support the source resource is not MKCOL method.

7.3.1     Request

   MKCOL creates a new collection the body of the
   destination resource MUST be octet-for-octet identical to at the body
   of location specified by
   the source resource.  Alterations to Request-URI.  If the destination resource do
   not modify the source resource.  Alterations to the source resource
   do not modify the destination resource.  Thus, all copies are
   performed _by-value_.

   All properties on the source resource MUST be duplicated on identified by the
   destination resource, subject to modifying headers, following Request-URI is
   non-null then the
   definition for copying properties.

8.11.1.2. COPY for Properties

   The following section defines how properties on a resource are
   handled during MKCOL must fail.  During MKCOL processing, a COPY operation.

   Live properties SHOULD be duplicated as identically behaving live
   properties at the destination resource.  Since they are live
   properties, the
   server determines MUST make the syntax and semantics Request-URI a member of these
   properties.  Properties named by its parent collection.
   If no such ancestor exists, the Enforce-Live-Properties header method MUST be live on fail.  When the destination MKCOL
   operation creates a new collection resource, all ancestors MUST
   already exist, or the method MUST fail.
   If fail with a property is not named by Enforce-Live-Properties and cannot be
   copied live, then its value MUST be duplicated, octet-for-octet, in
   an identically named, dead property on the destination resource.

   If 409 Conflict status
   code.  For example, if a property on the source already exists on the destination
   resource and the Overwrite header is set request to "T" then the property at
   the destination MUST be overwritten with the property from the
   source.  If the Overwrite header create collection /a/b/c/d/ is "F"
   made, and the previous situation neither /a/b/ nor /a/b/c/ exists, then the COPY request MUST fail with a 409 Conflict.

8.11.1.3. COPY for Collections

   The COPY method on fail.

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

   A MKCOL request message MAY contain a Depth header MUST act as
   if a Depth = infinity header was included.  A client MAY submit a
   Depth header on a COPY on a collection with a value of "0" or
   "infinity".  DAV compliant servers MUST support the "0" and
   "infinity" behaviors.

   A COPY message body.  The behavior of depth infinity instructs that the collection specified in
   the Request-URI,
   a MKCOL request when the records of its external member resources, and
   all its internal member resources, are to be copied body is present is limited to creating
   collections, members of a location
   relative to the Destination header.

   A COPY collection, bodies of depth "0" only instructs that members and
   properties on the collection, collections or members.  If the
   properties, and its external members, server receives a
   MKCOL request entity type it does not its internal members, are
   to be copied.

   Any headers included support or understand it MUST
   respond with a COPY are to be applied 415 Unsupported Media Type status code.  The exact
   behavior of MKCOL for various request media types is undefined in processing
   every resource to
   this document, and will be copied. specified in separate documents.

7.3.2     Response Codes

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

   201 Created - The exception to this rule is the Destination header. collection or structured resource was created in
   its entirety.

   403 Forbidden - This header
   only specifies the destination for indicates at least one of two conditions: 1)
   The server does not allow the Request-URI.  When applied to
   members creation of collections at the collection specified given
   location in the request-URI the value its namespace, and 2) The parent collection of
   Destination is to be modified to reflect the current location in the
   hierarchy.  So, if the request-URI is "a" and the destination is "b"
   then when a/c/d is processed it MUST use a destination of b/c/d.

   When the COPY method has completed processing it MUST have created a
   consistent namespace at the destination.  Thus if it is not possible
   to COPY a collection with internal members, the internal members may
   still be copied
   Request-URI exists but cannot accept members.

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

   409 Conflict - A collection will have to cannot be created made at the
   destination to contain them. Request-URI until
   one or more intermediate collections have been created.

   415 Unsupported Media Type- The response is a Multi-Status response that describes server does not support the result request
   type of the COPY body.

   423 Insufficient Space on each affected resource. Resource - The response is given for the resource that was to be copied, does not have
   sufficient space to record the resource that was created as
   a result state of the copy.  In other words, each entry indicates whether
   the copy on the resource specified in after the href succeeded or failed
   and why.

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

8.11.1.4. Type Interactions

   If the destination resource identifies method.

7.3.3     Example

   This example creates a collection and called /webdisc/xfiles/ on the
   Overwrite header
   server www.server.org.

   >>Request

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

   >>Response

   HTTP/1.1 201 Created

7.4 ADDREF Method

   The ADDREF method is _T_, prior used to performing the copy the server
   MUST perform a DELETE operation on the collection.

8.11.2. Response Codes

   200 OK - The source resource was successfully copied add external members to a pre-
   existing destination resource.

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

   412 Precondition Failed - This status code
   All DAV compliant collection resources MUST be returned if support the
   server was unable to maintain ADDREF
   method.  All other DAV compliant resources MAY support the liveness of ADDREF
   method as appropriate.

7.4.1     The Request

   The ADDREF method adds the properties listed URI specified in the Enforce-Live-Properties header, or if the Overwrite Collection-Member
   header is
   "F", and as an external member to the state of collection specified by the destination resource
   Request-URI.

   It is non-null.

   419 Insufficient Space on Resource - The destination resource does not have sufficient space to record an error if the state URI specified in the Collection-Member
   header already exists as an external member of the resource collection.
   However, after processing the execution ADDREF there MUST be only one instance
   of this method.

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

   500 Server Error - The resource was URI in such a state that it could
   not be copied.  This may occur if the Destination header specifies a
   resource that is outside the namespace collection.  If the resource is able to
   interact with.

8.11.3. Overwrite Example

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being copied to URI specified in the
   location http://www.ics.uci.edu/users/f/fielding/index.html.  The
   contents
   Collection-Member header already exists as an internal member of the destination resource were overwritten, if non-null.

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

   HTTP/1.1 200 OK

8.11.4. No Overwrite Example

   The following example shows
   collection, the same copy operation being performed,
   except ADDREF method MUST fail with the Overwrite header set to _F._  A response of 412
   Precondition Failed is returned because the destination resource has a non-null state.

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

   HTTP/1.1 412 Precondition
   Failed

8.11.5. Collection status code.

   More than one Collection-Member request header MUST NOT be used with
   the ADDREF method.

7.4.2     Example

   COPY /container/

   >>Request

   ADDREF /~ejw/dav/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Enforce-Live-Properties: *
   Depth: Infinity www.ics.uci.edu
   Collection-Member: http://www.iana.org/standards/dav/

   >>Response

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

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

   The Depth header is unnecessary as 204 No Content

   This example adds the default behavior of COPY on a
   collection is to act URI http://www.iana.org/standards/dav/ as if a "Depth: Infinity" header had been
   submitted.  In this example most an
   external member resource of the resources, along with the
   collection, were copied successfully. However the collection R2
   failed, most likely due to a problem with enforcing live properties.
   R2's member D2 was successfully copied.  As a result a collection
   was created at www.foo.bar/othercontainer/R2 to contain D2.

8.12. MOVE
   http://www.ics.uci.edu/~ejw/dav/.

7.5 DELREF Method

   The move operation on a resource DELREF method is the logical equivalent of a copy
   followed by used to remove external members from a delete, where the actions are performed atomically.
   resource.  All DAV compliant collection resources MUST support the MOVE
   DELREF method.

   However,  All other DAV compliant resources MUST support for the MOVE
   DELREF method does not guarantee only if they support the ability
   to move a resource to a particular destination. For example,
   separate programs may actually control different sets of resources
   on the same server.  Therefore, it may not even be possible to move
   a resource within a namespace that appears to belong to the same
   server.

8.12.1. ADDREF method.

7.5.1     The Request

   If a resource exists at the destination, the destination resource
   will be DELETEd as a side effect of the MOVE operation, subject to

   The DELREF method removes the restrictions of URI specified in the Overwrite header.

8.12.2. MOVE for Collections

   MOVE instructs that Collection-Member
   header from the collection specified in the Request-URI, by the
   records of its external member resources, and all its internal
   member resources, are to be moved to Request-URI.

   DELREFing a location relative to the
   Destination header.

   The MOVE method on URI which is not a member of the collection is not an
   error.  DELREFing an internal member MUST act as if fail with a Depth "infinity" 412
   Precondition Failed status code.

   More than one Collection-Member request header was used on it.  A client MUST NOT submit a Depth header on a
   MOVE on a collection with any value but "infinity".

   Any headers included be used with MOVE
   the DELREF method.

7.5.2     Example

   >>Request

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

   >>Response

   HTTP/1.1 204 No Content

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

7.6 GET, HEAD for Collections
   The semantics of GET are to be unchanged when applied in processing every
   resource to be moved.

   The exception to this rule a collection,
   since GET is defined as, "retrieve whatever information (in the Destination header.  The behavior form
   of this header an entity) is identified by the same as given for COPY on collections.

   When the MOVE method has completed processing it MUST have created a
   consistent namespace on both Request-URI" [Fielding et al.,
   1997].  GET when applied to a collection MAY return the source and destination, creating
   collections at contents of
   an "index.html" resource, a human-readable view of the source contents of
   the collection, or destination as necessary.

   As specified in something else altogether. Hence it is possible
   that the definition result of MOVE, a MOVE of GET on a collection over
   another collection causes the destination collection and all its
   members will bear no correlation to be deleted.

   The response
   the state of the collection.

   Similarly, since the definition of HEAD is a Multi-Status GET without a response that describes
   message body, the result semantics of HEAD are unmodified when applied to
   collection resources.

7.7 POST for Collections

   Since by definition the MOVE on each effected resource.  The response actual function performed by POST is given for
   determined by the
   resource that was server and often depends on the particular
   resource, the behavior of POST when applied to collections cannot be moved, not
   meaningfully modified because it is largely undefined.  Thus the resource that was created as
   a result
   semantics of POST are unmodified when applied to a collection.

7.8 DELETE

7.8.1     DELETE for Non-Collection Resources

   If the move.  In other words, each entry indicates whether DELETE method is issued to a non-collection resource which is
   an internal member of a collection, then during DELETE processing a
   server MUST remove the move on Request-URI from its parent collection.  A
   server MAY remove the URI of a deleted resource specified in from any collections
   of which the href succeeded or failed
   and why.

   The exception to this rule resource is an external member.

7.8.2     DELETE for errors that occurred Collections

   The DELETE method on the
   destination.  For example, if the destination was locked the
   response would indicate the destination URL and a 421 Destination
   Locked error.

8.12.3. Response Codes

   200 OK - The move operation was successful.

   409 Conflict _ The MOVE collection MUST act as if a Depth = infinity
   header was attempted used on it.  A client MUST NOT submit a Depth header on a
   DELETE on a collection with members.
   While any value but infinity.

   DELETE instructs that the COPY part of this operation could succeed collection specified in the DELETE could
   not.  Therefore request-URI,
   the MOVE MUST fail.

   412 Precondition Failed - This status code MUST records of its external member resources, and all its internal
   member resources, are to be returned if deleted.

   If any member cannot be deleted then all of the
   server was unable member's ancestors
   MUST NOT be deleted, so as to maintain the liveness of the properties listed namespace.

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

   When the Enforce-Live-Properties header, or if the Overwrite header is
   "F", and DELETE method has completed processing it MUST return a
   consistent namespace.

   The response SHOULD be a Multi-Status response that describes the state
   result of the destination resource DELETE on each affected resource.

7.8.2.1   Example

   >>Request

   DELETE  /container/ HTTP/1.1
   Host: www.foo.bar

   >>Response

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

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
   <d:multistatus>
     <d:response>
          <d:href>http://www.foo.bar/container/resource1</d:href>
          <d:href>http://www.foo.bar/container/resource2</d:href>
          <d:status>HTTP/1.1 200 OK</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/</d:href>
          <d:status>HTTP/1.1 424 Method Failure</d:status>
     </d:response>
     <d:response>
          <d:href>http://www.foo.bar/container/resource3</d:href>
          <d:status>HTTP/1.1 425 Locked</d:status>
     </d:response>
   </d:multistatus>

   In this example the attempt to delete
   http://www.foo.bar/container/resource3 failed because it is non-null.

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

   502 Bad Gateway - This may occur when the destination is

                                                           o
                                                            n another
   server and the destination server refuses to accept request. Consequently, the resource
8.12.4. Overwrite Example

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being moved
   attempt to the
   location http://www.ics.uci.edu/users/f/fielding/index.html.  The
   contents of the destination resource delete http://www.foo.bar/container/ also failed, but
   resource1 and resource2 were overwritten, if non-null.

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

   HTTP/1.1 200 OK

8.12.5. Collection Example

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

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

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

   In this example the client deleted. Even though a Depth header has submitted
   not been included, a number depth of lock tokens
   with infinity is assumed because the request.  A lock token will method
   is on a collection. As this example illustrates, DELETE processing
   need to not be submitted atomic.

7.9 PUT

7.9.1     PUT for every
   resource, both source and destination, anywhere in Non-Collection Resources

   A PUT performed on an existing resource replaces the scope GET response
   entity of the
   method, that is locked.  In this case resource.  Properties defined on the proper lock token was resource MAY be
   recomputed during PUT processing but are not
   submitted for otherwise effected.
   For example, if a server recognizes the destination http://www.foo.bar/othercontainer/C2.
   This means that content type of the resource continer/c2 could not request
   body, it may be moved,
   although its child container/C2/R2 able to automatically extract information that could
   be moved.

8.13. LOCK Method

   The following sections describe profitably exposed as properties.

   A PUT that would result in the LOCK method, which is used to
   take out a lock creation of any access type.  These sections on a resource without an
   appropriately scoped parent collection MUST fail with a 409
   Conflict.

7.9.2     PUT for Collections

   As defined in the LOCK HTTP/1.1 specification [Fielding et al., 1997],
   the "PUT method describe only those semantics requests that are specific to the LOCK
   method and are independent of enclosed entity be stored under
   the access type 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 lock being
   requested.  Once the general LOCK MKCOL method has been described,
   subsequent sections describe is defined to create collections.  If a
   PUT is invoked on a collection resource it MUST fail.

   When the semantics of PUT operation creates a new non-collection resource all
   ancestors MUST already exist.  If all ancestors do not exist, the "write" access
   type,
   method MUST fail with a 409 Conflict status code.  For example, if
   resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
   then the write lock.

8.13.1. Operation

   A LOCK request must fail.

7.10 COPY Method

   The COPY method invocation creates a duplicate of the lock specified source resource, given by
   the Request-URI, in the destination resource, given by the Lock-Info
   Destination header.  The Destination header MUST be present.  The
   exact behavior of the COPY method depends on the Request-URI.  Lock type of the source
   resource.

   Support for the COPY method requests SHOULD have does not guarantee the ability to copy a XML
   request body which contains an Owner XML element for this lock
   request. The LOCK request MAY have
   resource. For example, separate programs may control resources on
   the same server.  As a Timeout header.

   A successful response result, it may not even be possible to copy a lock invocation MUST include Lock-Token
   and Timeout headers.  Clients MUST assume
   resource to a location that locks may arbitrarily
   disappear at any time, regardless of the value given in the Timeout
   header.  The Timeout header only indicates appears to be on the behavior of same server.

7.10.1    COPY for HTTP/1.1 resources

   When the
   server if "extraordinary" circumstances do source resource is 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 collection the record body of the lock's
   existence. The response
   destination resource MUST also contain be octet-for-octet identical to the value body
   of the
   lockdiscovery property in a prop XML element.

8.13.2. The Effect of Locks on Properties and Collections

   By default source resource.  Subsequent alterations to the scope of a lock is destination
   resource will not modify the entire state of source resource.  Subsequent
   alterations to the resource,
   including its body and associated properties.  As a result, a lock source resource will not modify the destination
   resource.  Thus, all copies are performed "by-value".

   All properties on a the source resource also locks MUST be duplicated on the resource's properties,
   destination resource, subject to modifying headers and a lock XML elements,
   following the definition for copying properties.

7.10.2    COPY for Properties
   The following section defines how properties on a
   property may lock a property's resource or may restrict the ability
   to lock are
   handled during a COPY operation.

   Live properties SHOULD be duplicated as identically behaving live
   properties at the property's destination resource.  Only  If a single lock token MUST property cannot be
   used when a lock extends to cover both a resource and
   copied live, then its
   properties.  Note value MUST be duplicated, octet-for-octet, in
   an identically named, dead property on the destination resource.

   The propertybehavior XML element can specify that certain lock types MAY override this
   behavior.

   For collections, a lock also affects properties are
   copied on best effort, that all live properties MUST be successfully
   copied or the ability to add method MUST fail, or remove
   members.  The nature that a specified list of live
   properties MUST be successfully copied or the effect depends upon the type of access
   control involved.

8.13.3. Locking Replicated Resources

   Some servers automatically replicate resources across multiple URLs.
   In such method must fail. The
   propertybehavior XML element is defined in Section 11.12.

   If a circumstance property on the server MAY only accept a lock source already exists on one of the URLs if destination
   resource and the server can guarantee that Overwrite header is set to "T" then the lock will property at
   the destination MUST be honored
   across all overwritten with the URLs.

8.13.4. Locking Multiple Resources

   The LOCK method supports locking multiple resources simultaneously
   by allowing for property from the listing of several URIs in
   source.  If the LOCK request.
   These URIs, in addition to Overwrite header is "F" and the Request-URI, are previous situation
   exists, then to be locked as
   a result of the LOCK method's invocation.  When multiple resources
   are specified the LOCK COPY MUST fail with a 412 Precondition Failed.

7.10.3    COPY for Collections

   The COPY method only succeeds on a collection without a Depth header MUST act as
   if all specified
   resources are successfully locked.

   The Lock-Tree option of the lock request specifies that a Depth header with value "infinity" was included.  A client MAY
   submit a Depth header on a COPY on a collection with a value of "0"
   or "infinity".  DAV compliant servers MUST support the resource "0" and
   "infinity" behaviors.

   A COPY of depth infinity instructs that the collection specified in
   the Request-URI and the records of its external member resources is
   to be copied to the location specified in the Destination header,
   and all its internal children (including internal collections, member resources are to be copied to a
   location relative to it, recursively through all levels of the
   collection hierarchy.

   A COPY of depth "0" only instructs that the collection, the
   properties, and
   their the records of its external members, not its
   internal members) members, are to be locked.  This is another mechanism
   by which a request for copied.

   Any headers included with a lock on multiple resources can COPY are to be
   specified.

   Currently existing locks can not applied in processing
   every resource to be extended copied.

   The exception to cover more or less
   resources, and any request this rule is the Destination header. This header
   only specifies the destination for the Request-URI. When applied to expand or contract
   members of the number collection specified in the request-URI the value of
   resources
   Destination is to be modified to reflect the current location in a lock MUST fail with a 409 Conflict status code. the
   hierarchy.  So,
   for example, if resource A is exclusively write locked and then the
   same principal asks to exclusively write lock resources A, B, and C, the request will fail as A request-URI is already locked "a" and the lock can not be
   extended.

   A successful result will return a single lock token which represents
   all destination is "b"
   then when a/c/d is processed it MUST use a destination of b/c/d.

   When the resources that COPY method has completed processing it MUST have been locked.  If created a
   consistent namespace at the destination.  However, if an UNLOCK is executed
   on this token, error
   occurs while copying an internal member collection, all associated resources are unlocked.

   If members of
   this collection MUST NOT be copied. In this case, after detecting
   the lock cannot error, the COPY operation SHOULD try to finish as much of the
   original copy operation as possible.  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 granted made to all resources, copy /a/c/. Similarly,
   after encountering an error copying a 409 Conflict non-collection resource as
   part of an infinite depth copy, the server SHOULD try to finish as
   much of the original copy operation as possible.

   The response is a Multi-Status status code MUST be returned with a response an entity body containing
   a multistatus that
   describes the result of the COPY on each affected resource.  The
   href XML element describing which resource(s) prevented in the
   lock from being granted.

8.13.5. Interaction with other Methods

   The interaction of a LOCK with various methods is dependent upon response refers to the
   lock type.  However, independent of lock type, a successful DELETE
   of a resource MUST cause all of its locks that was to
   be removed.

8.13.6. Lock Compatibility Table

   The table below describes copied, not the behavior resource that occurs when was created as a lock
   request is made result of the
   copy.  In other words, each entry indicates whether the copy on a resource.

   Current lock state/      Shared Lock       Exclusive
   Lock request                               Lock
   None                     True              True
   Shared Lock              True              False
   Exclusive Lock           False             False*
   Legend: True = lock MAY be granted.  False = lock MUST NOT be
   granted.  *=if the principal requesting
   resource specified in the lock href XML element succeeded or failed and
   why.

   The exception to this rule is for errors that occurred on the owner of
   destination.  For example, if the
   lock, destination was locked the lock MAY be regranted.

   The current lock state of
   response would indicate the destination URL and a 425 Locked error.

7.10.4    Type Interactions

   If the destination resource identifies a collection and the
   Overwrite header is given in "T", prior to performing the leftmost
   column, and lock requests are listed in copy the first row.  The
   intersection of server
   MUST perform a row and column gives DELETE operation on the result collection.

7.10.5    Status Codes

   201 Created - The source resource was successfully copied.  The copy
   operation resulted in the creation of a lock request.
   For example, if a shared lock is held on new resource.

   204 No Content - The source resource was successfully copied to a resource, and an
   exclusive lock
   pre-existing destination resource.  Since there is requested, no entity body in
   the table entry response, 204 No Content is _false_, indicating
   the lock must not used instead of 200 OK.

   412 Precondition Failed - This status code MUST be granted.

   If an exclusive or shared lock is re-requested by returned if the principal who
   owns
   server was unable to maintain the lock, liveness of the lock MUST be regranted.  If properties listed
   in the lock propertybehavior XML element, or if the Overwrite header is
   regranted,
   "F", and the same lock token that was previously issued MUST be
   returned.

8.13.7. Owner XML Element

   Name:       owner
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Provide information about state of the principal taking out a
   lock.
   Parent:     Any
   Values:          XML Elements
   Descripton: destination resource is non-null.

   423 Insufficient Space on Resource - The Owner XML element provides information destination resource does
   not have sufficient
   for either directly contacting a principal (such as a telephone
   number or Email URI), or for discovering the principal (such as space to record the
   URL state of a homepage) who owns a lock.

8.13.8. Lock Response

   A successful lock response MUST contain a Lock-Token response
   header, a Timeout header and a prop XML element in the response body
   which contains resource after
   the value execution of the lockdiscovery property.

8.13.9. Response Codes

   409 Conflict this method.

   425 Locked - The destination resource is locked, so the method has been
   rejected.

   412 Precondition Failed - The included was locked and either a valid
   Lock-Token header was not
   enforceable on this resource submitted, or the Lock-Token header
   identifies a lock held by another principal.

   502 Bad Gateway - This may occur when the destination is on another
   server could not satisfy and the
   request in destination server refuses to accept the Lock-Info header.

8.13.10. resource.

7.10.6    Overwrite Example - Simple Lock Request

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

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

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

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

   This example shows the successful creation of an exclusive write
   lock on resource
   http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
   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 http://www.ics.uci.edu/~ejw/contact.html contains contact
   information for the owner of at the lock.
   destination was overwritten.

   >>Request

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

   >>Response

   HTTP/1.1 204 No Content

7.10.7    No Overwrite Example

   The server has an activity-

   based timeout policy in place on this resource, which causes following example shows the
   lock same copy operation being performed,
   except with the Overwrite header set to automatically be removed after 1 week (604800 seconds).  The "F."  A response of 412
   Precondition Failed is returned because the destination resource has
   a Lock-Token header that gives the lock token URL that
   uniquely identifies the lock created by this lock request.

8.13.11. non-null state.

   >>Request

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

   >>Response

   HTTP/1.1 412 Precondition Failed

7.10.8    Collection Example - Multi-Resource Lock Request

   LOCK /workspace/webdav/proposal.doc

   >>Request

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

   <?XML version="1.0"> www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Depth: infinity
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0"?>
   <?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
   <D:href>http://www.ics.uci.edu/~ejw/contact.html<D:href> href="http://www.iana.org/standards/dav/" as="d"?>
   <d:propertybehavior>
     <d:keepalive>*</d:keepalive>
   </d:propertybehavior>

   >>Response

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

   <?XML version="1.0">

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

   This example shows a request for an exclusive write lock on three
   resources, http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
   http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah.  In
   this request, href="http://www.iana.org/standards/dav/" as="d"?>
   <d:multistatus>
     <d:response>
       <d:href>http://www.foo.bar/othercontainer/resource1</d:href>
       <d:href>http://www.foo.bar/othercontainer/resource2</d:href>
       <d:href>http://www.foo.bar/othercontainer/</d:href>
     <d:status>HTTP/1.1 201 Created</d:status>
     </d:response>

     <d:response>
       <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
       <d:href>http://www.foo.bar/othercontainer/R2/D2</d:href>
       <d:status>HTTP/1.1 412 Precondition Failed</d:status>
     </d:response>
   </d:multistatus>

   The Depth header is unnecessary as the client has specified that it desires an infinite
   length lock, if available, otherwise a timeout default behavior of 4.1 billion
   seconds, COPY on a
   collection is to act as if available.  The Owner a "Depth: infinity" header field specifies had been
   submitted.  In this example most of the web
   address for contact information for resources, along with the principal taking out
   collection, were copied successfully. However the
   lock.

   This lock request has collection R2
   failed, because the server rejected the lock
   request for http://foo.bar/blah.  The 409 Conflict status code
   indicates that the server was unable most likely due to satisfy the request because
   there is a conflict between problem with maintaining the state liveness
   of the resources and the
   operation named in the request.  Within the multistatus, the 202
   Accepted status code indicates that the lock method was accepted properties (this is specified by the resources, and would have been completed if all resources named
   in the request were able to be locked.  The 403 Forbidden status
   code indicates that the server does propertybehavior XML
   element). Since an error occurred copying R2, R2's member D2 was not allow lock requests on this
   resource.

8.14. UNLOCK
   copied.

7.11 MOVE Method

   The UNLOCK method removes MOVE operation on a non-collection resource is the lock identified logical
   equivalent of a copy (COPY) followed by a delete, where the lock token in
   the Lock-Token header from the Request-URI, and all other resources
   included in the lock.

   Any actions
   are performed atomically.  All DAV compliant resource which supports the LOCK method resources MUST support
   the UNLOCK MOVE method.

8.14.1. Example

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

   HTTP/1.1 200 OK

   In this example, the lock identified by

   However, support for the lock token
   "opaquelocktoken:123AbcEfg1284h23h2" is successfully removed from MOVE method does not guarantee the ability
   to move a resource http://webdav.sb.aol.com/workspace/webdav/info.doc.  If
   this lock included more than just one resource, the lock was removed
   from those resources as well.

8.15. PATCH Method

   The PATCH method is used to modify parts a particular destination. For example,
   separate programs may actually control different sets of resources
   on the entity returned in
   the response same server.  Therefore, it may not even be possible to move
   a GET method.  DAV compliant resources MAY support
   the PATCH method.

8.15.1. The Request

   The request entity of the PATCH method contains resource within a list of
   differences between namespace that appears to belong to the same
   server.

   If a resource identified by exists at the Request-URI and destination, the desired content destination resource
   will be DELETEd as a side effect of the resource after MOVE operation, subject to
   the PATCH action has been
   applied.  The list restrictions of differences is in a format defined by the
   media type Overwrite header.

7.11.1    MOVE for Collections

   A MOVE of depth infinity instructs that the entity (e.g., "application/diff") and must include
   sufficient information to allow collection specified in
   the server to convert Request-URI, including the original
   version records of the resource its external member
   resources, is to be moved to the desired version.  Processing
   performed by PATCH is atomic.  Hence location specified in the
   Destination header, and all changes MUST its internal member resources are to be
   successfully executed or
   moved to locations relative to it, recursively through all levels of
   the collection hierarchy.

   The MOVE method fails.  PATCH on a collection MUST fail act as if
   executed a Depth "infinity"
   header was used on it.  A client MUST NOT submit a non-existent resource; i.e., PATCH does not create Depth header on a
   resource as
   MOVE on a side effect.

   If the request appears (at least initially) collection with any value but "infinity".

   Any headers included with MOVE are to be acceptable, the
   server MUST transmit an interim 100 response message after receiving
   the empty line terminating the request headers and continue applied in processing the request.  Since the semantics of PATCH are non-
   idempotent, responses every
   resource to be moved.

   The exception to this method are not cacheable.

   While server support for PATCH rule is optional, if a server does support
   PATCH, it MUST support at least the text/xml diff format defined
   below.  Support for the VTML difference format [VTML] Destination header.  The behavior
   of this header is
   recommended, but not required.

8.15.2. text/xml elements the same as given for PATCH

   The resourceupdate XML element contains COPY on collections.

   When the MOVE method has completed processing it MUST have created a set of XML sub-entities
   that describe modification operations.  The name
   consistent namespace on both the source and meaning of
   these XML elements are given below.  Processing destination. However, if
   an error occurs while moving an internal member collection, all
   members of these directives the failed collection MUST NOT be performed in the order encountered within moved. In this case,
   after detecting the XML document.
   A directive operates on error, the resource move operation SHOULD try to finish
   as modified by all previous
   directives (executed in sequential order).  The length much of the
   resource MAY be extended or reduced by a PATCH.

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

8.15.2.1. resourceupdate XML Element

   Name:       resourceupdate
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Contains original move as possible.  So, for example, if an ordered set of changes
   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,
   non-property resource.
   Parent:     None
   Value=      *(insert | delete | replace)

8.15.2.2. insert XML Element

   Name:       insert
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Insert non-collection resource as part of an
   infinite depth move, the XML element's contents starting at server SHOULD try to finish as much of the
   original move operation as possible.

   As specified octet.
   Parent:     resourceupdate
   Value:      The insert XML element MUST contain an octet-range XML
   attribute that specifies an octet position within in the body definition of MOVE, a
   resource.  A value of _end_ specifies the end of the resource.  The
   body MOVE of a collection over
   another collection causes the insert XML element contains the octets destination collection and all its
   members to be inserted.

   Please note deleted.

   The response is a Multi-Status response that in order to protect describes the white space contained in
   this result of
   the MOVE on each affected resource.  The href XML element in the following attribute/value MUST
   response refers to the resource that was to be included in moved, not the element: XML-SPACE = "PRESERVE". This attribute is defined in
   resource that was created as a result of the XML specification [Bray, Sperberg-McQueen, 1997].

8.15.2.3. delete XML Element

   Name:       delete
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Removes move.  In other words,
   each entry indicates whether the move on the resource specified range of octets.
   Parent:     resourceupdate
   Value:      The delete XML element MUST contain an octet-range XML
   attribute.

   Discussion: in
   the href succeeded or failed and why.

   The octets exception to this rule is for errors that are deleted are removed, which means occurred on the
   destination.  For example, if the destination was locked the
   response would indicate the destination URL and a 425 Locked error.

7.11.2    Status Codes
   201 Created - The source resource is collapsed was successfully moved, and a new
   resource was created at the length of destination.

   204 No Content - The move operation was successful, and the resource is decremented
   by
   at the size of destination was overwritten.

   412 Precondition Failed - This status code MUST be returned if the octet range.  It is not appropriate
   server was unable to replace
   deleted octets with zeroed-out octets, since zero is a valid octet
   value.

8.15.2.4. replace XML Element

   Name:       replace
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Replaces the specified range of octets with maintain the contents liveness of the XML element.  If the number of octets properties listed
   in the propertybehavior XML element element, or if the Overwrite header is
   different from
   "F", and the number state of octets specified, the update MUST be
   rejected.
   Parent:     resourceupdate
   Value:      The replace XML element MUST contain an octet-range XML
   attribute. destination resource is non-null.

   425 Locked - The contents of the entity are source or the replacement octets.

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

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

8.15.2.5. octet-range Attribute

   Name:       octet-range
   Namespace:  http://www.ietf.org/standards/dav/patch/
   Purpose:    Specifies destination resource was locked and
   either a range of octets that the enclosing property
   affects.
   Parent:     insert | delete | replace
   Value:      number [_-_ (number | _end_)]
               Number = 1*Digit

   Description: Octet numbering begins with 0.  If valid Lock-Token header was not submitted, or the octet contains Lock-
   Token header identifies a
   single number then lock held by another principal.

   502 Bad Gateway - This may occur when the operation destination is to begin at that octet on another
   server and to
   continue for a length specified by the operation.  In the case of a
   delete, this would mean to delete a single octet.  In the case of an
   insert this would mean destination server refuses to begin the insertion at accept the specified octet
   and resource.

7.11.3    Non-Collection Example

   This example shows resource
   http://www.ics.uci.edu/~fielding/index.html being moved to continue for the length
   location http://www.ics.uci.edu/users/f/fielding/index.html. The
   contents of the included value, extending the destination resource would have been overwritten if necessary.  In the case of replace,
   the replace begins destination resource had been non-null.  In this case, since
   there was nothing at the specified octet and overwrites all that follow to destination resource, the length response code is
   201 Created.

   >>Request

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

   >>Response

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

7.11.4    Collection Example

   >>Request

   MOVE /container/ HTTP/1.1
   Host: www.foo.bar
   Destination: http://www.foo.bar/othercontainer/
   Overwrite: F
   Lock-Token: <opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>,
      <opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>

   Content-Type: text/xml
   Content-Length: xyz
   Authorization: Digest username="rohit",
      realm="rohit@www.foo.bar", nonce="...",
      uri="/container/", response="...",
      opaque="..."

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
   <d:propertybehavior>
     <d:keepalive>*</d:keepalive>
   </d:propertybehavior>

   >>Response

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

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
   <d:multistatus>
     <d:response>
       <d:href>http://www.foo.bar/container/resource1</d:href>
       <d:href>http://www.foo.bar/container/resource2</d:href>
       <d:href>http://www.foo.bar/container/</d:href>
       <d:status>HTTP/1.1 204 No Content</d:status>
     </d:response>
     <d:response>
       <d:href>http://www.foo.bar/container/C2/R2</d:href>
       <d:status>HTTP/1.1 424 Method Failure</d:status>
     <d:response>
       <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
       <d:status>HTTP/1.1 425 Locked</d:status>
     </d:response>
   </d:multistatus>

   In this example the client has submitted a number of lock tokens
   with the included value.

8.15.3. Response Codes

   200 OK - The request entity body was processed without error,
   resulting in an update request.  A lock token will need to the state of the resource.

   409 Conflict - If the update information be submitted for every
   resource, both source and destination, anywhere in the request message body
   does not make sense given the current state scope of the resource (e.g.,
   an instruction to delete a non-existent line),
   method, that is locked.  In this status code MAY
   be returned.

   415 Unsupported Media Type - The server does not support the content
   type of the update instructions in the request message body.

   418 Unprocessable Entity - The entity body submitted with case the PATCH proper lock token was not understood by
   submitted for the destination http://www.foo.bar/othercontainer/C2/.
   This means that the resource.

   419 Insufficient Space on Resource - The resource does /container/C2/ could not have
   sufficient space to record be moved.  As
   the state of attempt to move /container/C2/ failed then the resource after the
   execution
   /container/C2/R2 MUST also fail since it is a child of this method.

8.15.4. HTML file modification Example
   /container/C2/.

7.12 LOCK Method

   The following example shows sections describe the LOCK method, which is used to
   take out a modification lock of any access type.  These sections on the title LOCK
   method describe only those semantics that are specific to the LOCK
   method and contents are independent of the HTML resource http://www.example.org/hello.html.

   Before:
   <HTML>
   <HEAD>
   <TITLE>Hello world HTML page</TITLE>
   </HEAD>
   <BODY>
   <P>Hello, world!</P>
   </BODY>
   </HTML>

   PATCH Request:                       Response:

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

                                        HTTP/1.1 100 Continue

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

                                        HTTP/1.1 200 OK

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

9. HTTP Headers for Distributed Authoring

9.1. Collection-Member Header

   CollectionMember = "Collection-Member" ":" URI   ; URI is defined in
   section 3.2.1 access type of [Fielding et al., 1997]

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

9.2. DAV Header

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

   This header indicates that the resource supports the DAV schema and
   protocol to lock being
   requested.

7.12.1    Operation

   A LOCK method invocation creates the level indicated.  All DAV compliant resources MUST
   return lock specified by the DAV header on all OPTIONS responses.

9.3. Depth Header

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

   The Depth header is used with methods executed lockinfo
   XML element on collections to
   indicate whether the Request-URI.  Lock method requests SHOULD have a
   XML request body which contains an owner XML element for this lock
   request, unless this is a refresh request. The LOCK request MAY have
   a Timeout header.

   A successful response to be applied only to the collection
   (Depth = 0), to the collection and its immediate children, (Depth =
   1), or the collection a lock invocation MUST include Lock-Token
   and all its progeny (Depth = infinity).  Note Timeout headers.  Clients MUST assume that Depth = 1 and Depth = infinity behavior only applies to
   internal member resources, and not to external member resources.

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

   The following rules are the default behavior for locks may arbitrarily
   disappear at any method that
   supports time, regardless of the depth header. A method MAY override these defaults by
   defining different behavior value given in its definition.

   Methods which support the depth Timeout
   header.  The Timeout header MAY choose not to support all
   of the header's values and MAY define, on a case by case basis, only indicates the behavior of the method on a collection
   server if a depth header is "extraordinary" circumstances do not
   present. occur.  For example, the MOVE method only supports Depth = infinity
   and if a depth header is not present will act as if
   an administrator may remove a Depth =
   infinity header had been applied.

   Clients MUST NOT rely upon methods executing on members of their
   hierarchies in lock at any particular order time or the execution being atomic.
   Note that methods MAY provide guarantees on ordering and atomicity.

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

   So, for example, an attempt to COPY a hierarchy system may result
   crash in some such a way that it loses the record of the members being copied and some not.

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

   If a resource, source or destination, within the prop XML element.

7.12.2    The Effect of Locks on Properties and Collections

   The scope of the method
   is locked in such a way as to prevent lock is the successful execution entire state of the method, then the resource, including
   its body and associated properties.  As a result, a lock token for that on a
   resource MUST be submitted
   with also locks the request in resource's properties.

   For collections, a lock also affects the Lock-Token request header.

9.4. Destination Header

   Destination = "Destination" ":" URI ability to add or remove
   members.  The Destination header specifies a destination resource for methods nature of the effect depends upon the type of access
   control involved.

7.12.3    Locking Replicated Resources

   Some servers automatically replicate resources across multiple URLs.
   In such as COPY and MOVE, which take two URIs as parameters.

9.5. Destroy Header

   DestroyHeader = "Destroy" ":" #Choices

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

   Extend = RFC-Reg | Coded-URL

   RFC-Req = Token ; This is a token value (defined in section 2.2 circumstance the server MAY only accept a lock on one of
   [Fielding et al., 1997])
   the URLs if the server can guarantee that has been published as an RFC.

   Coded-URL = "<" URI ">"

   When deleting a resource the client often wishes to specify exactly
   what sort of delete should lock will be performed. honored
   across all the URLs.

7.12.4    Depth and Locking

   The Destroy header, Depth header MAY be used with the Mandatory header, allows LOCK method.  Values other
   than 0 or infinity MUST NOT be used with the client Depth header.

   A Depth header of value 0 means to specify just lock the end
   result it desires.  The Destroy header is resource specified as follows:

   The Undelete token requests that, if possible,
   by the resource should
   be left in a state such that it can be undeleted.  The server request-URI.

   If the Depth header is not
   required set to honor this request.

   The NoUndelete token requests that infinity then the resource MUST NOT be left specified
   in
   a state such that it can be undeleted.

   The VersionDestroy token includes the functionality of request-URI along with all its internal members, all the
   NoUndelete token and extends it to include having way
   down the server remove
   all versioning references hierarchy, are to the resource that it has control over.

9.6. Enforce-Live-Properties Header

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

   Property-Name = Coded-URL

   The Enforce-Live-Properties header specifies properties that MUST be
   _live_ after they are copied (moved) to the destination resource of locked.  A successful result will
   return a copy (or move).  If the value _*_ is given for the header, then it
   designates single lock token which represents all live properties on the source resource. resources that
   have been locked.  If the value an UNLOCK is "Omit" then the server MUST NOT duplicate executed on the destination
   resource any properties that this token, all
   associated resources are defined on the source resource. unlocked.  If
   this header is not included then the server is expected lock cannot be granted to act as

   defined by the default property handling behavior of
   all resources, a 409 Conflict status code MUST be returned with a
   response entity body containing a multistatus XML element describing
   which resource(s) prevented the associated
   method.

9.7. If-None-State-Match

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

   The If-None-State-Match header lock from being granted.  Hence,
   partial success is intended to have similar
   functionality to the If-None-Match header defined in section 14.26
   of RFC 2068.  However not an option.  Either the if-none-state-match header entire hierarchy is intended for
   use
   locked or no resources are locked.

7.12.5    Interaction with any URI which represents state information about a
   resource, referred to as other Methods

   The interaction of a state token.  A typical example LOCK with various methods is a dependent upon the
   lock
   token.

   If any type.  However, independent of the state tokens identifies the current state lock type, a successful DELETE
   of the
   resource, the server a resource MUST NOT perform the requested method.
   Instead, if cause all of its locks to be removed.

7.12.6    Lock Compatibility Table

   The table below describes the behavior that occurs when a lock
   request method was GET, HEAD, INDEX, or PROPFIND,
   the server SHOULD respond with is made on a 304 Not Modified response,
   including the cache-related entity-header fields (particularly ETag)
   of the current state of the resource.  For all other

   Current lock state/      Shared Lock       Exclusive
   Lock request
   methods, the server                               Lock

   None                     True              True

   Shared Lock              True              False

   Exclusive Lock           False             False*

   Legend: True = lock MAY be granted.  False = lock MUST respond with a status of 412 Precondition
   Failed.

   If none of the state tokens identifies the current state of NOT be
   granted.  *=if the
   resource, principal requesting the server MAY perform lock is the requested method.

   If any owner of the tokens is not recognized then
   lock, the method lock MUST fail
   with be regranted.

   The current lock state of a 412 Precondition Failed.

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

9.8. If-State-Match

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

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

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

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

7.12.7    Lock Response

   A successful lock response MUST contain a Lock-Token response
   header, a Timeout header and any of a prop XML element in the state tokens
   identifies response body
   which contains the current state value of the resource, then the server MAY
   perform the requested method.  If the keyword requirement for the
   the keyword used is lockdiscovery property.

7.12.8    Status Codes
   412 Precondition Failed - The included Lock-Token was not met,
   enforceable on this resource or the server MUST NOT perform could not satisfy the
   requested method, and MUST return a 412 Precondition Failed
   response.

   If any of
   request in the tokens lockinfo XML element.

   425 Locked - The resource is not recognized then locked, so the method MUST fail
   with a 412 Precondition Failed.

9.9. Lock-Info has been
   rejected.

7.12.9    Example - Simple Lock Request Header

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

   The Lock-Info request header specifies

   >>Request

   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Content-Type: text/xml
   Content-Length: xyz
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <D:lockinfo>
     <D:locktype><D:write/></D:locktype>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:owner>
       <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
     </D:owner>
   </D:lockinfo>

   >>Response

   HTTP/1.1 200 OK
   Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
   Timeout: Second-604800
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:prop>
     <D:lockdiscovery>
       <D:activelock>
         <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:timeout>Second-604800</D:timeout>
         <D:locktoken>
           <D:href>
     opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
           </D:href>
         </D:locktoken>
       </D:activelock>
     </D:lockdiscovery>
   </D:prop>

   This example shows the scope and type successful creation of a an exclusive write
   lock
   for a LOCK method request.  The syntax specification below is
   extensible, allowing new type and scope identifiers to be added. on resource
   http://webdav.sb.aol.com/workspace/webdav/proposal.doc.  The LockType field specifies
   resource http://www.ics.uci.edu/~ejw/contact.html contains contact
   information for the access type owner of the lock.  At
   present, this specification only defines one lock type, the "Write"
   lock.  The LockScope field specifies whether the lock is server has an
   exclusive lock, or a shared lock.  The AddLocks field specifies
   additional URIs, beyond the Request-URI, to activity-
   based timeout policy in place on this resource, which causes the
   lock request
   applies.  The LockTree field is used to specify recursive locks.  If
   the LockTree field is "T", automatically be removed after 1 week (604800 seconds).  The
   response has a Lock-Token header that gives the lock request applies to the hierarchy
   traversal of the internal member resources of the Request-URI, and
   the AddLocks URIs, inclusive of token URL that
   uniquely identifies the Request-URI and lock created by this lock request.  Note
   that the AddLocks
   URIs.  It is not an error if LockTree is "T", nonce, response, and the Request-URI or
   the AddLocks URIs opaque fields have no internal member resources.  By default, not been calculated
   in the value of LockTree is "F", and this field MAY be omitted when its
   value is "F".

9.10. Lock-Token Request Header

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

   The Lock-Token Authorization request header, containing header.

7.12.10   Example - Refreshing a lock token owned by the
   requesting principal, is used by Write Lock

   >>Request

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

   >>Response

   HTTP/1.1 200 OK
   Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
   Timeout: Second-604800
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:prop>
     <D:lockdiscovery>
       <D:activelock>
         <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:timeout>Second-604800</D:timeout>
         <D:locktoken>
           <D:href>
     opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
           </D:href>
         </D:locktoken>
       </D:activelock>
     </D:lockdiscovery>
   </D:prop>

   This request would refresh the principal to indicate lock, resetting any time outs.
   Notice that the
   principal is aware of client asked for an infinite time out but the existence of server
   choose to ignore the lock specified by request. In this example, the
   lock token.

   If nonce, response,
   and opaque fields have not been calculated in the following conditions are met:

   1) The method is restricted by a lock type that requires the
   submission of Authorization
   request header.

7.12.11   Example - Multi-Resource Lock Request

   >>Request

   LOCK /webdav/ HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Depth: infinity
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <D:lockinfo>
     <D:locktype><D:write/></D:locktype>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:owner>
       <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
     </D:owner>
   </D:lockinfo>

   >>Response

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

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <D:multistatus>
     <D:response>
          <D:href>http://webdav.sb.aol.com/webdav/proposal.doc</D:href>
          <D:href>http://webdav.sb.aol.com/webdav/</D:href>
          <D:status>HTTP/1.1 424 Method Failure</D:status>
     </D:response>
     <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:multistatus>

   This example shows a request for an exclusive write lock token, such as on a write lock,
   2) The user-agent
   collection and all its children.  In this request, the client has authenticated itself as
   specified that it desires an infinite length lock, if available,
   otherwise a principal,
   3) timeout of 4.1 billion seconds, if available. The user-agent is submitting a method
   request to a resource on
   which entity body contains the contact information for the
   principal owns a write taking out the lock,

   Then:

   1) The method request MUST include in this case a Lock-Token header with the lock
      token, or,
   2) web page URL.

   The method MUST fail with 424 Method Failure indicates that a 409 Conflict status code.

   If multiple lock was not taken out on
   these resources are involved with due to an error elsewhere.  Note that this does not
   mean that a method, such as lock would have succeeded on these resources had the
   other error not occurred.  It only means that another error has
   occurred and so the entire method has been aborted.  The error is a COPY or
   MOVE method, then
   403 Forbidden response on the lock tokens, if any, for all involved
   resources, MUST resource
   http://webdav.sb.aol.com/webdav/secret.  Because this resource could
   not be included locked, none of the resources were locked.

   In this example, the nonce, response, and opaque fields have not
   been calculated in the Lock-Token Authorization request header.

   For example, Program A, used by user A, takes out a write

7.13 UNLOCK Method

   The UNLOCK method removes the lock on a
   resource.  Program A then makes a number of PUT requests on identified by the
   locked resource.  All lock token in
   the requests contain a Lock-Token request header that includes from the write lock state token.  Program B, also
   run by User A, then proceeds to perform a PUT to Request-URI, and all other resources
   included in the locked
   resource.  However, program B was not aware of lock.

   Any DAV compliant resource which supports the existence of LOCK method MUST
   support the UNLOCK method.

7.13.1    Example

   >>Request

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

   >>Response

   HTTP/1.1 204 No Content
   In this example, the lock and so does not include identified by the appropriate Lock-Token request
   header.  The method is rejected even though principal A lock token
   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
   authorized to perform
   successfully removed from the PUT.  Program B can, if it so chooses, now
   perform resource
   http://webdav.sb.aol.com/workspace/webdav/info.doc.  If this lock discovery and obtain
   included more than just one resource, the lock token.  Note that
   programs A and B can perform GETs without using the Lock-Token
   header because the ability to perform a GET is not affected by a
   write removed from all
   resources included in the lock.

   Having a lock token provides no special access rights.  Anyone can
   find out anyone else's lock token by performing lock discovery.
   Locks are to be enforced based upon whatever authentication
   mechanism  The 204 status code is used by instead
   of 200 OK because there is no response entity body.

   In this example, the server, nonce, response, and opaque fields have not based on the secrecy of
   been calculated in the
   token values.

9.11. Lock-Token Response Authorization request header.

8  HTTP Headers for Distributed Authoring

8.1 Collection-Member Header
   Lock-Token

   CollectionMember = "Lock-Token" "Collection-Member" ":" Coded-URL

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

9.12. Overwrite Header

   Overwrite = "Overwrite" ":" ("T" | "F") defined in section 3.2.1 of [Fielding et al., 1997]

   The Overwrite Collection-Member header specifies whether the server should overwrite the state URI of a non-null destination an external
   resource during to be added/deleted to/from a COPY or MOVE.
   A value of _F_ states collection.

8.2 DAV Header

   DAV = "DAV" ":" ["1"] [",2"] ["," 1#extend]

   This header indicates that the server MUST NOT perform the COPY or
   MOVE operation if the state of the destination resource is non-null.
   By default, supports the value of Overwrite is _T,_ DAV schema and a client MAY omit
   this
   protocol as specified. All DAV compliant resources MUST return the
   DAV header from a request when its on all OPTIONS responses.

   The value is _T._ While the
   Overwrite header appears to duplicate the functionality of the If-
   Match: * header a list of HTTP/1.1, If-Match applies only to all compliance classes that the Request-
   URI, and not resource
   supports. Note that above a comma has already been added to the Destination of a COPY or MOVE.

   If a COPY or MOVE 2.
   This is because a resource can not performed due be level 2 compliant unless it is
   also level 1 compliant. Please refer to the value of the Overwrite
   header, the method MUST fail with a 409 Conflict status code.

9.13. Propfind Request Section 13 for more details.
   In general, however, support for one compliance class does not
   entail support for any other.

8.3 Depth Header

   Propfind

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

   The Propfind Depth header is used to specify which properties are to be
   returned in a PROPFIND method.  The properties are identified by
   their URIs.  Two special tokens are defined for use with the
   Propfind header, allprop and propname.  The allprop token specifies
   that all property names and values methods executed on resources which
   could potentially have internal members to indicate whether the resource are
   method is to be
   returned.  The propname token specifies that applied only a list of property
   names on the resource are to be returned.

9.14. Status-URI Response Header

   The Status-URI response header MAY be used with the 102 Processing
   response code resource (Depth = 0), to inform the client as to
   resource and its immediate children, (Depth = 1), or the status of a method.

   Status-URI resource
   and all its progeny (Depth = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status-
   Code infinity).

   The Depth header is defined in 6.1.1 of [Fielding et al., 1997] only supported if a method's definition
   explicitly provides for such support.

   The URIs listed following rules are the default behavior for any method that
   supports the Depth header. A method MAY override these defaults by
   defining different behavior in its definition.

   Methods which support the Depth header are source resources which have been
   affected by MAY choose not to support all
   of the outstanding method.  The status code indicates header's values and MAY define, on a case by case basis, the
   resolution
   behavior of the method on the identified resource.  So, for
   example, if a Depth header is not present. For
   example, the MOVE method on a collection is outstanding only supports Depth = infinity and if a 102
   "Processing" response with a Status-URI response
   Depth header is returned,
   the included URIs not present will indicate resources that have had move
   attempted on them and what the result was.

9.15. Timeout Header
   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other act as if a Depth = Extend field-value   ; See section 4.2 of RFC 2068

   Clients MAY include Timeout headers in their LOCK requests.
   However, the server is not required to honor or even consider these
   requests. infinity header
   had been applied.

   Clients MUST NOT submit a Timeout request header with rely upon methods executing on members of their
   hierarchies in any particular order or on the execution being
   atomic. Note that methods MAY provide guarantees on ordering and
   atomicity.

   Upon execution, a method other than with a LOCK method.

   A Timeout request Depth header MUST contain at least one TimeType and MAY
   contain multiple TimeType entries. The purpose will perform as much of listing multiple
   TimeType entries is
   its assigned task as possible and then return a response specifying
   what it was able to indicate multiple different values accomplish and value
   types that are acceptable what it failed to the client.  The client lists the
   TimeType entries do.

   So, for example, an attempt to COPY a hierarchy may result in order some
   of preference.

   The Timeout response header MUST use a Second value, Infinite, or a
   TimeType the client has indicated familiarity with.  The server MAY
   assume members being copied and some not.

   Any headers on a client is familiar method with any TimeType submitted in a Timeout
   header.

   The _Second_ TimeType specifies the number of seconds that Depth header MUST
   elapse between granting of be applied to all
   resources in the lock at scope of the server, and the automatic
   removal of the lock.  A server MUST not generate a timeout value for
   _Second_ greater than 2^32-1.

   The timeout counter is restarted any time method. For example, an owner of the lock sends
   a method to any member of If-Match
   header will have its value applied against every resource in the lock, including unsupported methods,
   or methods which are unsuccessful.  It is recommended that
   method's scope and will cause the HEAD method be used when the goal is simply to restart fail if the timeout
   counter. header fails
   to match.

   If a resource, source or destination, within the timeout expires then scope of the lock method
   is lost.  Specifically the
   server SHOULD act locked in such a way as if an UNLOCK method was executed by to prevent the server
   on successful execution of
   the resource using method, then the lock token of the timed-out lock,
   performed with its override authority. Thus logs should for that resource MUST be updated submitted
   with the disposition of the lock, notifications should be sent,
   etc., just as they would be for an UNLOCK request.

   Servers are advised to pay close attention to request in the values submitted
   by clients, as they will be indicative of Lock-Token request header.

   The Depth header only specifies the type behavior of activity the
   client intends method with
   regards to perform.  For example, an applet running in internal children.  If a
   browser may need resource does not have internal
   children then the Depth header is ignored.

   Please note, however, that it is always an error to lock submit a resource, but because of the instability
   of the environment within which value
   for the applet Depth header that is running, not allowed by the applet
   may be turned off without warning.  As method's definition.
   Thus submitting a result, the applet is
   likely to ask for "Depth: 1" on a relatively small timeout value so that COPY, even if the
   applet dies, resource does
   not have internal members, MUST result in a 400 Bad Request. The
   method should fail not because the lock can be quickly harvested.  However, resource doesn't have internal
   members, but because of the illegal value in the header.

8.4 Destination Header

   Destination = "Destination" ":" URI

   The Destination header specifies a document
   management system is likely to ask destination resource for an extremely long timeout
   because its user may be planning on going off-line.

10. Response Code Extensions to HTTP/1.1 methods
   such as COPY and MOVE, which take two URIs as parameters.

8.5 If-None-State-Match

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

   The following response codes are added If-None-State-Match header is intended to those have similar
   functionality to the If-None-Match header defined in HTTP/1.1 section 14.26
   of [Fielding et al., 1997].

10.1. 102 Processing

   Methods can potentially take  However the If-None-State-Match header
   is intended for use with any URI which represents state information
   about a long period of time resource, referred to process,
   especially methods that support as a state token.  A typical example
   is a lock token.

   If any of the Depth header.  In such cases state tokens identifies the
   client may time-out current state of the connection while waiting for a response.  To
   prevent this
   resource, the server MAY return a 102 response code to indicate
   to MUST NOT perform the client that requested method.
   Instead, if the server is still processing request method was GET, HEAD, or PROPFIND, the method.

   If
   server SHOULD respond with a method is taking longer than 20 seconds (a reasonable, but
   arbitrary value) to process 304 Not Modified response, including
   the server SHOULD return a 102
   "Processing" response.

10.2. 207 Multi-Status

   The response requires providing status for multiple independent
   operations.

10.3. 418 Unprocessable Entity

   The server understands cache-related entity-header fields (particularly ETag) of the content type
   current state of the resource.  For all other request entity, but
   was unable to process methods, the contained instructions.

10.4. 419 Insufficient Space on Resource

   The resource does not have sufficient space to record
   server MUST respond with a status of 412 Precondition Failed.

   If none of the state tokens identifies the current state of the resource after
   resource, the execution of this server MAY perform the requested method.

10.5. 420 Method Failure

   The method was not executed on a particular resource within its
   scope because some part

   If any of the method's execution failed causing the
   entire method to be aborted.  For example, if a resource could tokens is not
   be moved as part of a MOVE method, all recognized, the other resources would method MUST fail with a 420 Method Failure.

10.6. 421 Destination Locked

   The destination resource of a method is locked,
   412 Precondition Failed.

   Note that the "AND" and either "OR" keywords specified with the
   request did If-State-
   Match header are intentionally not contain a valid Lock-Info header, or defined for If-None-State-Match,
   because this functionality is not required.

8.6 If-State-Match

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

   The If-State-Match header is intended to have similar functionality
   to the Lock-Info If-Match header identifies defined in section 14.25 of [Fielding et al.,
   1997].  However the If-State-Match header is intended for use with
   any URI which represents state information about a resource.  A
   typical example is a lock held by another principal.

11. Multi-Status Response

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

11.1. multistatus XML Element

   Name:       multistatus
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains multiple response messages.
   Parent:     Any
   Value:      1*response [responsedescription]
   Description: The responsedescription at token.

   If the top level AND keyword is used to
   provide a general message describing and all of the overarching nature state tokens identify the
   state of the
   response. resource, then the server MAY perform the requested
   method.  If this value the OR keyword is available an application MAY use it
   instead used and any of presenting the individual response descriptions contained
   within the responses.

11.2. response XML Element

   Name:       response
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Holds a single response
   Parent:     multistatus
   Value:      href [prop] status [responsedescription]
   Description: Prop MUST contain one or more empty XML elements
   representing state tokens
   identifies the names current state of properties.  Multiple properties may be
   included if the same response applies to them all. resource, then the server MAY
   perform the requested method.  If href is the keyword requirement for the
   keyword used
   then is not met, the response refers to server MUST NOT perform the requested
   method, and MUST return a problem with 412 Precondition Failed response.

   If any of the referenced resource, tokens is not recognized, the method MUST fail with a property.

11.3. status XML Element

   Name:       status
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Holds
   412 Precondition Failed.

8.7 Lock-Token Request Header
   Lock-Token = "Lock-Token" ":" 1#Coded-URL

   The Lock-Token request header, containing a single HTTP status-line
   Parent:     response
   Value:      status-line   ;status-line defined in [Fielding et al.,
   1997]

11.4. responsedescription XML Element

   Name:       responsedescription
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains a message that can be displayed to the user
   explaining lock token owned by the nature of
   requesting principal, is used by the response.
   Parent:     multistatus | response
   Value:      Any
   Description: This XML element provides information suitable to be
   presented principal to a user.

12. Generic DAV XML Elements
12.1. href XML Element

   Name:       href
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To identify indicate that the content
   principal is aware of the element existence of the lock specified by the
   lock token.

   If the following conditions are met:

   1) The method is restricted by a URI.
   Parent:     Any
   Value:      URI ; See section 3.2.1 lock type that requires the
   submission of [Fielding et al., 1997]

12.2. link XML Element

   Name:       link
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To identify a property lock token, such as a link and to contain the
   source and destination of that link.
   Values=     1*src 1*dst
   Description: Link write lock,
   2) The user-agent has authenticated itself as a given principal,
   3) The user-agent is used submitting a method request to provide a resource on
   which the sources and destinations of principal owns a link. write lock,

   Then:

   1) The type of the property containing the link XML element
   provides the type of method request MUST include a Lock-Token header with the link.  Link is lock
      token, or,
   2) The method MUST fail with a multi-valued element, so
   multiple Links may be used together to indicate 409 Conflict status code.

   If multiple links resources are involved with a method, such as the same type.

12.2.1. src XML Element

   Name:       src
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To indicate MOVE
   method, then the source of a link.
   Parent:     link
   Values=     URI

12.2.2. dst XML Element

   Name:       dst
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To indicate lock tokens, if any, for all affected resources,
   MUST be included in the destination of Lock-Token request header.

   For example, Program A, used by user A, takes out a link
   Parent:     link
   Values=     URI

12.2.3. Example

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

   In this example write lock on a
   resource.  Program A then makes a number of PUT requests on the resource http://foo.bar/program has
   locked resource.  All the requests contain a source
   property Lock-Token request
   header that contains three links.  Each link contains three
   elements, two of which, src and dst, are part of includes the DAV schema
   defined in this document, and one which is defined write lock token.  Program B, also run by
   User A, then proceeds to perform a PUT to the schema
   http://www.foocorp.com/project/ (Source, Library, and Makefile).  A
   client which only implements locked resource.
   However, program B was not aware of the elements in existence of the DAV spec will lock and so
   does not
   understand include the foocorp elements and will ignore them, thus seeing appropriate Lock-Token request header.  The
   method is rejected even though principal A is authorized to perform
   the expected source PUT.  Program B can, if it so chooses, now perform lock
   discovery and destination links.  An enhanced client may
   know about obtain the foocorp elements lock token.  Note that programs A and be able to present B can
   perform GETs without using the user with
   additional information about Lock-Token header because the links.  This example demonstrates
   the power of XML markup that allows for element values to be
   enhanced without breaking older clients.

12.3. prop XML element

   Name:       prop
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains properties related ability
   to perform a resource.
   Parent:     Any
   Values:     XML Elements
   Description: The prop XML element GET is not affected by a generic container for
   properties defined on resources.  All elements inside prop MUST
   define properties related write lock.

   Having a lock token provides no special access rights.  Anyone can
   find out anyone else's lock token by performing lock discovery.
   Locks are to the resource.  No other elements may be enforced based upon whatever authentication
   mechanism is used inside of a prop element.

13. DAV Properties

13.1. creationdate Property

   Name:       creationdate
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    The time and date by the resource was created.
   Value:      The time and date MUST be given in ISO 8601 format
   [ISO8601]
   Description: This property SHOULD be defined server, not based 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).

13.2. displayname Property
   Name:       displayname
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    A name for secrecy of the
   token values.

8.8 Lock-Token Response Header

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

   If a resource that is suitable for
   presentation to successfully locked then a user.
   Value:      Any valid XML character data (as defined in [Bray,
   Sperberg-McQueen, 1997])
   Description:This property SHOULD Lock-Token header will
   be defined on all DAV compliant
   resources. returned containing the lock token that represents the lock.

   If present, multiple lock-tokens are returned then they MUST all refer to the property contains a description of
   same lock.  As the
   resource that is suitable for presentation lock tokens all refer to the same lock a user.

13.3. get-content-language Property

   Name:       get-content-language
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Language client
   need only record one of them.

8.9 Overwrite Header

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

   The Overwrite header returned by specifies whether the server should overwrite
   the state of a GET
   without accept headers.  If no Content-Language header is available,
   this property non-null destination resource during a COPY or MOVE.
   A value of "F" states that the server MUST NOT exist.
   Value:      language-tag   ;language-tag is defined in section 14.13 perform the COPY or
   MOVE operation if the state of RFC 2068

13.4. get-content-length Property

   Name:       get-content-length
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Length header returned by destination resource is non-null.
   By default, the value of Overwrite is "T" and a GET
   without accept headers.  If no Content-Length client MAY omit this
   header from a request when its value is available,
   this property MUST NOT exist.
   Value:      content-length ; see section 14.14 "T". While the Overwrite
   header appears to duplicate the functionality of RFC 2068

13.5. get-content-type Property

   Name:       get-content-type
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Type If-Match: *
   header returned by of HTTP/1.1, If-Match applies only to the Request-URI, and
   not to the Destination of a GET
   without accept headers. COPY or MOVE.

   If no Content-Type header a COPY or MOVE is available,
   this property not performed due to the value of the Overwrite
   header, the method MUST NOT exist.
   Value:      media-type fail with a 409 Conflict status code.

8.10 Status-URI Response Header

   The Status-URI response header MAY be used with the 102 Processing
   status code to inform the client as to the status of a method.

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

13.6. get-etag Property

   Name:       get-etag
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the ETag header returned by a GET without
   accept headers.  If no ETag header is available, this property MUST
   NOT exist.
   Value:      entity-tag  ; defined in Section 3.11 of [Fielding et
   al., 1997]
   Description:Note that the ETag on some resource may reflect changes

   The URIs listed in any part of the state of the resource, not necessarily just a
   change to the response to header are source resources which have been
   affected by the GET outstanding method.  For example, a change in  The status code indicates the ACL may cause
   resolution of the ETag to change.

13.7. get-last-modified Property

   Name:       get-last-modified
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains method on the Last-Modified header returned by identified resource.  So, for
   example, if a GET MOVE method without accept headers.  If no Last-Modified on a collection is outstanding and a 102
   "Processing" response with a Status-URI response header is
   available, this property MUST NOT exist.
   Value:      HTTP-date returned,
   the included URIs will indicate resources that have had move
   attempted on them and what the result was.

8.11 Timeout Header

   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other = Extend field-value   ; defined in Section 3.3.1 See section 4.2 of [Fielding et al.,
   1997]
   Description:Note that the last-modified date on some resource may
   reflect changes

   Clients MAY include Timeout headers in any part of the state of their LOCK requests.
   However, the resource, server is not
   necessarily just a change to the response required to the GET method.  For
   example, a change in honor or even consider these
   requests.  Clients MUST NOT submit a property may cause the last-modified date to
   change.

13.8. index-content-language Property

   Name:       index-content-language
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Language Timeout request header returned by an
   INDEX without accept headers.  If no Content-Language with any
   method other than a LOCK method.

   A Timeout request header is
   available, this property MUST NOT exist.
   Value:      language-tag   ;language-tag contain at least one TimeType and MAY
   contain multiple TimeType entries. The purpose of listing multiple
   TimeType entries is defined to indicate multiple different values and value
   types that are acceptable to the client.  The client lists the
   TimeType entries in section 14.13 order of RFC 2068

13.9. index-content-length Property

   Name:       index-content-length
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains the Content-Length header returned by an INDEX
   without accept headers.  If no Content-Length preference.

   The Timeout response header is available,
   this property MUST NOT exist.
   Value:      content-length ; see section 14.14 of RFC 2068

13.10. index-content-type Property

   Name:       index-content-type
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains use a Second value, Infinite, or a
   TimeType the Content-Type header returned by an INDEX
   without accept headers.  If no Content-Type header client has indicated familiarity with.  The server MAY
   assume a client is available,
   this property MUST NOT exist.
   Value:      media-type   ; defined familiar with any TimeType submitted in Section 3.7 of [Fielding et
   al., 1997]

13.11. index-etag Property

   Name:       index-etag
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains a Timeout
   header.

   The "Second" TimeType specifies the ETag header returned by an INDEX without
   accept headers.  If no ETag header is available, this property MUST
   NOT exist.

   Value:      entity-tag  ; defined in Section 3.11 number of [Fielding et
   al., 1997]
   Description:Note seconds that the ETag on some resource may reflect changes
   in any part MUST
   elapse between granting of the state of lock at the resource, not necessarily just a
   change to server, and the response to automatic
   removal of the INDEX method.  For example, lock.  A server MUST not generate a change
   in the ACL may cause timeout value for
   "Second" greater than 2^32-1.

   The timeout counter SHOULD be restarted any time an owner of the ETag
   lock sends a method to change.

13.12. index-last-modified Property

   Name:       index-last-modified
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Contains any member of the Last-Modified header returned by an INDEX lock, including unsupported
   methods, or methods which are unsuccessful.  However the lock MUST
   be refreshed if a refresh LOCK method without accept headers. is successfully received.

   If no Last-Modified header the timeout expires then the lock is
   available, this property MUST NOT exist.
   Value:      HTTP-date  ; defined in Section 3.3.1 of [Fielding et
   al., 1997]
   Description:Note that lost.  Specifically the last-modified date
   server SHOULD act as if an UNLOCK method was executed by the server
   on some the resource may
   reflect changes in any part using the lock token of the state timed-out lock,
   performed with its override authority. Thus logs should be updated
   with the disposition of the resource, not
   necessarily lock, notifications should be sent,
   etc., just a change as they would be for an UNLOCK request.

   Servers are advised to the response pay close attention to the INDEX method. values submitted
   by clients, as they will be indicative of the type of activity the
   client intends to perform.  For example, a change an applet running in a property
   browser may cause the last-modified date need to
   change.

13.13. lockdiscovery Property

   Name:       lockdiscovery
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    To discover what locks are active on a resource
   Values=     *activelock
   Description:The lockdiscovery property returns lock a listing resource, but because of who has
   a lock, what type the instability
   of lock he have, the timeout type and environment within which the time
   remaining on applet is running, the timeout, and applet
   may be turned off without warning.  As a result, the associated lock token.  The server applet is free
   likely to withhold any or all 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.

9  Status Code Extensions to HTTP/1.1

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

9.1 102 Processing

   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 information if the requesting
   principal server MAY return a 102 status code to indicate to
   the client that the server is still processing the method.

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

9.2 207 Multi-Status

   The response provides status for multiple independent operations.

9.3 422 Unprocessable Entity

   The server understands the content type of the request entity, but
   was unable to process the contained instructions.

9.4 423 Insufficient Space on Resource

   The resource does not have sufficient access rights space to see record the
   requested data.  A server which supports locks MUST provide state of
   the
   lockdiscovery property on any resource with locks after the execution of this method.

9.5 424 Method Failure

   The method was not executed on it.

13.13.1. activelock XML Element

   Name:       activelock
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    A multivalued XML element that describes a particular
   active lock on a resource
   Parent:     lockdiscovery
   Values=     locktype lockscope [addlocks] owner timeout locktoken

13.13.2. owner XML Element

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

   Name:       timeout
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Returns information about within its
   scope because some part of the timeout associated with method's execution failed causing the lock
   Parent:     activelock
   Values=     TimeType

13.13.4. addlocks XML Element

   Name:       addlocks
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Lists additional
   entire method to be aborted.  For example, if a resource could not
   be moved as part of a MOVE method, all the other resources associated would
   fail with this lock, if
   any.
   Parent:     activelock
   Values=     1*href

13.13.5. locktoken XML Element

   Name:       locktoken
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    Returns a 424 Method Failure.

9.6 425 Locked

   The source or destination resource of a method is locked, and either
   the request did not contain a valid Lock-Token header, or the lock
   token
   Parent:     activelock
   Values=     href
   Description:The href contains in the Lock-Token header identifies a Lock-Token-URL.

13.13.6. Example

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

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

   HTTP/1.1 lock held by another
   principal.

10 Multi-Status Response

   The default 207 Multi-Status
   Content-Type: response body is a text/xml
   Content-Length: xxxxx

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

   This resource has HTTP entity
   that contains a single exclusive write lock on it, with an
   infinite timeout.  This same lock also covers the resource
   http://foo.com/doc/.

13.14. resourcetype Property

   Name:       resourcetype
   Namespace:  http://www.ietf.org/standards/dav/
   Purpose:    This property XML element called multistatus, which
   contains a series set of XML elements that
   specify information regarding the nature of called response, one for each 200,
   300, 400, and 500 series status code generated during the resource.  This
   specification only defines a single value, collection.
   Value:      XML elements
   Description:This property method
   invocation.  100 series status codes MUST NOT be recorded in a
   response XML element.

11 XML Element Definitions

   In the section below, the final line of each section gives the
   element type declaration using the format defined in [Bray, Paoli,
   Sperberg-McQueen, 1998]. The "Value" field, where present, specifies
   futher restrictions on all DAV compliant
   resources. the allowable contents of the XML element
   using BNF (i.e., to further restrict the values of a PCDATA
   element).

11.1 activelock XML Element

   Name:       activelock
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Describes a lock on a resource.

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

11.1.1    depth XML Element

   Name:       depth
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    The default value of the depth header used to create a lock.
   Description: If this element is empty.

13.14.1. not included in a lockinfo element
   then the client MUST assume that the lock is of depth 0.
   Value:      "0" | "infinity"

   <!ELEMENT depth (#PCDATA) >

11.1.2    locktoken XML Element

   Name:       locktoken
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    The lock token associated with a lock.
   Description: The href contains an opaque lock token URI (i.e., the
   OpaqueLockToken-URI production in Section 4.4).

   <!ELEMENT locktoken (href) >

11.1.3    timeout XML Element

   Name:       timeout
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    The timeout associated with a lock
   Value:      TimeType

   <!ELEMENT timeout (#PCDATA) >

11.2 collection XML Element

   Name:       collection
   Namespace:  http://www.ietf.org/standards/dav/  http://www.iana.org/standards/dav/
   Purpose:    Identifies the associated resource as a collection.
   Collection resources The
   resourcetype property of a collection resource MUST define have this value with the resourcetype
   property.
   Parent:     resourcetype
   Values:          None

13.15. Source Link Property Type value.

   <!ELEMENT collection EMPTY >

11.3 href XML Element

   Name:       source       href
   Namespace:  http://www.ietf.org/standards/dav/link/  http://www.iana.org/standards/dav/
   Purpose:    The destination    Identifies the content of the source element as a URI.
   Value:      URI ; See section 3.2.1 of [Fielding et al., 1997]

   <!ELEMENT href (#PCDATA)>

11.4 link identifies XML Element

   Name:       link
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Identifies the
   resource that property as a link and contains the unprocessed
   source and destination of the link's source.
   Parent:     None
   Value:      An XML document with zero or more link XML elements.

   Discussion: that link.
   Description: The source of the link (src) XML element is typically used to provide the URI sources and
   destinations of the
   output resource on which the link is defined, and there is typically
   only one destination (dst) a link.  The name of the link, which is property containing the URI where
   link XML element provides the
   unprocessed source type of the resource link.  Link is a multi-
   valued element, so multiple links may be accessed.  When more than

   one used together to indicate
   multiple links with the same type.

   <!ELEMENT link destination exists, this specification asserts no policy on
   ordering.

13.16. supportedlock Property (src+, dst+) >

11.4.1    dst XML Element

   Name:       supportedlock       dst
   Namespace:  http://www.ietf.org/standards/dav/  http://www.iana.org/standards/dav/
   Purpose:    To provide a listing of    Indicates the lock capabilities supported
   by the resource.
   Values:     An XML document containing zero or more LockEntry XML
   elements.
   Description:The supportedlock property destination of a resource returns a
   listing of link
   Value:      URI

   <!ELEMENT dst (#PCDATA) >

11.4.2    src XML Element

   Name:       src
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Indicates the combinations source 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.  If supportedlock is available on _*_ then it MUST define the
   set of locks allowed on all resources on that server.

13.16.1. link.
   Value:      URI

   <!ELEMENT src (#PCDATA) >

11.5 lockentry XML Element

   Name:       lockentry
   Namespace:  http://www.ietf.org/standards/dav/  http://www.iana.org/standards/dav/
   Purpose:    Defines a DAVLockType/LockScope pair the types of locks that may can be legally used with a LOCK on the specified
   resource.
   Parent:     supportedlock
   Values=     locktype lockscope

13.16.2. locktype

   <!ELEMENT lockentry (lockscope, locktype) >

11.6 lockinfo XML Element

   Name:       locktype       lockinfo
   Namespace:  http://www.ietf.org/standards/dav/  http://www.iana.org/standards/dav/
   Purpose:    Lists    The lockinfo XML element is used with a DAVLockType
   Parent:     lockentry
   Values=     DAVLockTypeValue

13.16.3. LOCK method to
   specify the type of lock the client wishes to have created.

   <!ELEMENT lockinfo (lockscope, locktype, owner?) >

11.7 lockscope XML Element

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

   Values:     DAVLockScopeValue

13.16.4. Example

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

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

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

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

14. DAV Compliance Levels

   A DAV compliant resource can choose from two levels lock is an exclusive lock, or a
   shared lock.

   <!ELEMENT lockscope (exclusive | shared) >

11.7.1    exclusive XML Element

   Name:       exclusive
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies an exclusive lock

   <!ELEMENT exclusive EMPTY >

11.7.2    shared XML Element

   Name:       shared
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies a shared lock

   <!ELEMENT shared EMPTY >

11.8 locktype XML Element

   Name:       locktype
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies the access type of compliance.
   A client can discover which level a resource supports by executing
   OPTIONS on lock.  At present, this
   specification only defines one lock type, the resource, and examining write lock.

   <!ELEMENT locktype (write) >

11.8.1    write XML Element

   Name:       write
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies a write lock.

   <!ELEMENT write EMPTY >

11.9 multistatus XML Element

   Name:       multistatus
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains multiple response messages.

   Description: The responsedescription at the "DAV" header which top level is
   returned.

   Since this document describes extensions used to
   provide a general message describing the HTTP/1.1 protocol,
   minimally all DAV compliant resources, clients, and proxies MUST be
   compliant with RFC 2068 [Fielding et al., 1997].

14.1. Level 1

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

14.2. Level 2
   A level 2 compliant resource MUST meet all level 1 requirements and
   support the supportedlock property as well as the LOCK method.

15. Internationalization Considerations

   In the realm of internationalization issues,
   response.  If this specification value is
   substantively in compliance with available an application MAY use it
   instead of presenting the IETF Character Set Policy
   [Alvestrand, 1997]. In this specification, human-readable fields can
   be found in either individual response descriptions contained
   within the value of a property, or in an error message
   returned in a responses.

   <!ELEMENT multistatus (response+, responsedescription?) >

11.9.1    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 by default that
   XML processors read XML elements encoded using Element

   Name:       response
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Holds a single response describing the UTF-8 and UCS-2
   encodings effect of a
   method on resource and/or its properties.
   Description: A particular href MUST NOT appear more than once as the ISO 10646 basic multilingual plane.  Furthermore,
   XML contains provisions for encoding XML elements using other
   encoding schemes, notable among them UCS-4, which permits encoding
   child of characters from any ISO 10646 character plane.

   The default character set encoding for a response XML data element under a multistatus XML element.
   This requirement is necessary in order to keep processing costs for
   a response to linear time.  Essentially, this
   specification, and prevents having to
   search in general, is UTF-8.  WebDAV compliant
   applications MUST support order to group together all the UTF-8 and UCS-2 character set
   encodings for responses by href.  There
   are, however, no requirements regarding ordering based on href
   values.

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription?) >

11.9.1.1  propstat XML elements, Element

   Name:       propstat
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Groups together a prop and SHOULD support the UCS-4 encoding.
   The XML character set encoding declaration for each supported
   character set MUST also be supported, since it is by using this
   encoding declaration status element that an XML processor determines the encoding
   of an is
   associated with a particular href element.
   Description: Prop MUST contain one or more empty XML also provides language tagging capability which provides the
   ability to specify elements
   representing the language names of properties.  Multiple properties may be
   included if the contents of same response applies to them all.

   <!ELEMENT propstat (prop, status) >

11.9.1.2  status XML Element

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

   <!ELEMENT status (#PCDATA) >

11.9.2    responsedescription XML
   element.  Although XML, and hence WebDAV, does not use RFC 1766
   language tags for its language names, Element

   Name:       responsedescription
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains a message that can be displayed to the benefit of using standard
   XML in this context outweighs user
   explaining the advantage of using RFC 1766
   language tags.

   Names used within this specification fall into two categories: names
   specific to protocol elements such as methods and headers, names of
   XML elements, and names of properties.  Naming nature 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 response.
   Description: This XML element provides information suitable to users, and are in fact simply long token identifiers,
   they do not need be
   presented to support encoding in multiple character sets.
   Similarly, though the names of a user.

   <!ELEMENT responsedescription (#PCDATA) >

11.10     owner XML elements used in this
   specification are English names encoded in UTF-8, these names are
   not visible to Element

   Name:       owner
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Provides information about the user, and hence do not need to support multiple
   character set encodings. principal taking out a
   lock.
   Description: The name of owner XML element provides information sufficient
   for either directly contacting a property defined on principal (such as a resource is telephone
   number or Email URI), or for discovering the principal (such as the
   URL of a URI.  Although
   some applications (e.g., homepage) who owns a generic property viewer) will display
   property URIs directly to their users, it lock.

   <!ELEMENT owner (#PCDATA, ANY)* >

11.11     prop XML element

   Name:       prop
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains properties related to a resource.
   Description: The prop XML element is expected that the
   typical application will use a fixed set generic container for
   properties defined on resources.  All elements inside prop MUST
   define properties related to the resource.  No other elements may be
   used inside of properties, and will
   provide a mapping from the property name URI to prop element.

   <!ELEMENT prop ANY>

11.12     propertybehavior XML element

   Name:       propertybehavior
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies how properties are handled during a human-readable
   field when displaying the property name to COPY or
   MOVE.
   Description: The propertybehavior XML element specifies how
   properties are handled during a user.  It COPY or MOVE.  If this XML element
   is only not included in the case where request body then the set of properties server is not known ahead of time that
   an application need display a property name URI expected to a user. We
   recommend that applications provide human-readable
   act as defined by the default property names
   wherever feasible.

   For error reporting, we follow handling behavior of the convention
   associated method.

   <!ELEMENT propertybehavior (omit | keepalive) >

11.12.1   keepalive XML element

   Name:       keepalive
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies requirements for the copying/moving of HTTP/1.1 status
   codes, including with each status code live
   properties.

   Description: If a short, English description list of URIs is included as the code (e.g., 421 Destination Locked).  While value of keepalive
   then the possibility
   exists that a poorly crafted user agent would display this message named properties MUST be "live" after they are copied
   (moved) to a user, internationalized applications will ignore this message,
   and display an appropriate message in the user's language and
   character set.

   Since interoperation destination resource of clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of this information.

16. Security Considerations
   [TBD]

17. Terminology

   Collection - A resource that contains member resources.

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

   Internal Member Resource _ A member resource of a collection whose
   URI COPY (or MOVE).  If the
   value "*" is relative to given for the URI of keepalive XML element, this designates
   that all live properties on the collection.

   External Member Resource - A member source resource of a collection with an
   absolute URI MUST be live on the
   destination.
   Value:      "*" ; #PCDATA value can only be "*"

   <!ELEMENT keepalive (#PCDATA | href+) >

11.12.2   omit XML element

   Name:       omit
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Indicates that the associated method MAY succeed even if
   the server is not relative able to its parent's URI.

   Property - A name/value pair that contains descriptive information
   about a resource.

   Live Property _ A copy/move every property whose semantics and syntax are enforced
   by on the server.  For example, source
   resource, even in a live "content-length" property would
   have its value, the length of the entity returned by dead form.
   Description: The default behavior for a GET request,
   automatically calculated by the server.

   Dead Property _ A property whose semantics and syntax are not
   enforced by COPY or MOVE is to copy/move
   all properties or fail the server.  The method.  In certain circumstances, such
   as when a server only records the value of copies a dead
   property; the client is responsible for maintaining resource over another protocol such as
   FTP, it may not be possible to copy/move the consistency
   of properties associated
   with the syntax and semantics of a dead property.

18. Copyright
   The following copyright notice is copied from RFC 2026 chapter 10.4,
   and describes 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. The omit XML element instructs the applicable copyright server that
   it should use best effort to copy properties but a failure to copy a
   property should not cause the method to fail.

   <!ELEMENT omit EMPTY >

11.13     propertyupdate XML element

   Name:       propertyupdate
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains a request to alter the properties on a
   resource.
   Description: This XML element is a container for this document

   Copyright (C) The Internet Society November 19, 1997. All Rights
   Reserved. the information
   required to modify the properties on the resource.  This document and translations of it may be copied and furnished XML element
   is multi-valued.

   <!ELEMENT propertyupdate (remove | set)+ >

11.13.1   remove XML element

   Name:       remove
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Lists the DAV properties to
   others, and derivative works be removed from a resource.
   Description: Remove instructs that comment on or otherwise explain it
   or assist the properties specified in its implementation may prop
   should be prepared, copied, published
   and distributed, in whole or in part, without restriction removed.  Specifying the removal of any
   kind, provided a property that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may does
   not be modified exist is not an error.  All the XML elements in any way, such prop MUST be
   empty, as by removing only the copyright notice or references names of properties to be removed are required.

   <!ELEMENT remove (prop) >

11.13.2   set XML element

   Name:       set
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Lists the Internet Society or other
   Internet organizations, except as needed DAV property values to be set for a resource.
   Value:      prop
   Description: This XML element MUST contain only a prop XML element.
   The elements contained by prop specify the purpose name and value of
   developing Internet standards in which case
   properties that are set on the procedures for
   copyrights defined in Request-URI.  If a property already
   exists then its value is replaced.

   <!ELEMENT set (prop) >

11.14     propfind XML Element

   Name:       propfind
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies the Internet Standards process must be
   followed, or as required properties to translate it into languages other than
   English.

   The limited permissions granted above be returned from a PROPFIND
   method.  Two special elements are perpetual specified for use with propfind,
   allprop and will not propname.

   <!ELEMENT propfind (allprop | propname | href+) >

11.14.1   allprop XML Element

   Name:       allprop
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    The allprop XML element specifies that all property
   names and values on the resource are to be
   revoked by returned.

   <!ELEMENT allprop EMPTY >

11.14.2   propname XML Element

   Name:       propname
   Namespace:  http://www.iana.org/standards/dav/
   Purpose: the Internet Society or its successors or assignees.

   This document and propname XML element specifies that only a list of
   property names on the information contained herein resource 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.

19. Acknowledgements

   A specification such as this thrives on piercing critical review and
   withers from apathetic neglect.  The authors gratefully acknowledge to be returned.

   <!ELEMENT propname EMPTY >

12 DAV Properties

   For DAV properties, the contributions name of the following people, whose insights were so
   valuable at every stage property is also the same as the
   name of our work.

   Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell, Bernard
   Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel,
   Jr., Jim Davis, Keith Dawson, Mark Day, Martin Duerst, David Durand,
   Lee Farrell, Chuck Fay, Roy Fielding, Mark Fisher, Alan Freier,
   George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton,
   Steve Henning, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul
   Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter,
   Michael Mealling, Keith Moore, Henrik Nielsen, Kenji Ota, Bob
   Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders,
   Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud,
   Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John
   Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and
   Lauren Wood.

   One from this list deserves special mention.  The contributions by
   Larry Masinter have been invaluable, both in helping the formation XML element which contains its value. In the section
   below, the final line of each section gives the working group and element type
   declaration using the format defined in patiently coaching [Bray, Paoli, Sperberg-
   McQueen, 1998]. The "Value" field, where present, specifies futher
   restrictions on the authors along allowable contents of the
   way.  In so many ways he has set high standards we have toiled XML element using BNF
   (i.e., to
   meet.

20. References

   [Alvestrand, 1997] H. T. Alvestrand, "IETF Policy on Character Sets further restrict the values of a PCDATA element).

12.1 creationdate Property

   Name:       creationdate
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Records the time and Languages."  Internet-draft, work-in-progress.
   ftp://ds.internic.net/internet-drafts/draft-alvestrand-charset-
   policy-02.txt

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

   [Bradner, 1997] S. Bradner, "Key words for use date the resource was created.
   Value:      ;The time and date MUST be given in RFCs to Indicate
   Requirement Levels."  RFC 2119, BCP 14. Harvard University.  March,
   1997.

   [Bray, Sperberg-McQueen, 1997] T. Bray, C. M. Sperberg-McQueen,
   "Extensible Markup Language (XML): Part I. Syntax", WD-xml-
   lang.html, http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.

   [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
   Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
   RFC 2068. U.C. Irvine, DEC, MIT/LCS.  January, 1997.
   ftp://ds.internic.net/rfc/rfc2068.txt

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

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

   [Maloney, 1996] M. Maloney, "Hypertext Links ISO 8601 format
   defined in HTML." Internet
   draft (expired), work-in-progress, January, 1996.

   [MARC, 1994] Network Development and MARC Standards, Office, ed.
   1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC:
   Cataloging Distribution Service, Library Appendix 2
   Description: This property SHOULD be defined on all DAV compliant
   resources.  If present, it contains a timestamp of Congress.

   [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
   Treese, "PICS Label Distribution Label Syntax and Communication
   Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-961031.
   http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.

   [Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead, Jr.,
   D. Durand, "Requirements the moment when
   the resource was created (i.e., the moment it had non-null state).

   <!ELEMENT creationdate (#PCDATA) >

12.2 displayname Property

   Name:       displayname
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Provies a name for Distributed Authoring and Versioning
   Protocol the resource that is suitable for
   presentation to a user.
   Description: This property SHOULD be defined on all DAV compliant
   resources.  If present, the World Wide Web." RFC XXXX. Xerox, Univ. property contains a description of Bologna,
   U.C. Irvine, Boston Univ. YYY, 1997.
   ftp://ds.internic.net/rfc/rfcXXXX.txt

   [WebDAV, 1997] WEBDAV Design Team. "A Proposal the
   resource that is suitable for Web Metadata
   Operations." Unpublished manuscript.
   http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html

   [Weibel presentation to a user.

   <!ELEMENT displayname (#PCDATA) >

12.3 externalmembers Property

   Name:       externalmembers
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Provides the list of external members defined on the
   resource.
   Description: This property MUST be defined on any DAV compliant
   resource with external members.  If defined it MUST contain the full
   list of external members.  Resources MAY make this property read-
   only, thus only allowing its value to be altered using the
   ADDREF/DELREF methods.

   <!ELEMENT externalmembers (href*) >

12.4 getcontentlanguage Property

   Name:       getcontentlanguage
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains the Content-Language header returned by a GET
   without accept headers
   Description: This property MUST be defined on any DAV compliant
   resource which supports GET, with the exception that if no Content-
   Language header is available, this property MUST NOT exist.
   Value:      language-tag   ;language-tag is defined in section 14.13
   of [Fielding et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
   "OCLC/NCSA Metadata Workshop Report."
   http://purl.oclc.org/metadata/dublin_core_report.

   [Yergeau, 1997] F. Yergeau, "UTF-8,
   <!ELEMENT getcontentlanguage (#PCDATA) >

12.5 getcontentlength Property

   Name:       getcontentlength
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains the Content-Length header returned by a transformation format of
   Unicode and ISO 10646", Internet Draft, work-in-progress, draft-
   yergeau-utf8-rev-00.txt, http://www.internic.net/internet-
   drafts/draft-yergeau-utf8-rev-00.txt.

21. Authors' Addresses

   Y. Y. Goland
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Email: yarong@microsoft.com

   E. J. Whitehead, Jr.
   Dept. Of Information and Computer Science
   University GET
   without accept headers.  If no Content-Length header is available,
   this property MUST NOT exist.
   Description: This property MUST be defined on any DAV compliant
   resource which returns the Content-Length header in response to a
   GET.
   Value:      content-length ; see section 14.14 of California, Irvine
   Irvine, CA 92697-3425
   Email: ejw@ics.uci.edu

   A. Faizi
   Netscape
   685 East Middlefield Road
   Mountain View, CA 94043
   Email: asad@netscape.com

   S. R. Carter
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399
   Email: srcarter@novell.com

   D. Jensen
   Novell
   1555 [Fielding et al.,
   1997]

   <!ELEMENT getcontentlength (#PCDATA) >

12.6 getcontenttype Property

   Name:       getcontenttype
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains the Content-Type header returned by a GET
   without accept headers.  If no Content-Type header is available,
   this property MUST NOT exist.
   Description: This property MUST be defined on any DAV compliant
   resource which returns the Content-Type header in response to a GET.
   Value:      media-type   ; defined in Section 3.7 of [Fielding et
   al., 1997]

   <!ELEMENT getcontenttype (#PCDATA) >

12.7 getetag Property

   Name:       getetag
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains the ETag header returned by a GET without
   accept headers.
   Description: Note that the ETag 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 to a
   resource's access permissions may cause the ETag to change. This
   property MUST be defined on any DAV compliant resource which returns
   the Etag header in response to a GET, except for the case if no ETag
   header is returned, this property MUST NOT exist.
   Value:      entity-tag  ; defined in Section 3.11 of [Fielding et
   al., 1997]

   <!ELEMENT getetag (#PCDATA) >

12.8 getlastmodified Property

   Name:       getlastmodified
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Contains the Last-Modified header returned by a GET
   method without accept headers.
   Description: Note that the last-modified date on a resource may
   reflect changes in any part of the state of the resource, not
   necessarily just a change to the response to the GET method.  For
   example, a change in a property may cause the last-modified date to
   change. This property MUST be defined on any DAV compliant resource
   which returns the Last-Modified header in response to a GET, except
   for the case if no Last-Modified header is returned, this property
   MUST NOT exist.
   Value:      HTTP-date  ; defined in Section 3.3.1 of [Fielding et
   al., 1997]

   <!ELEMENT getlastmodified (#PCDATA) >

12.9 lockdiscovery Property

   Name:       lockdiscovery
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Describes the active locks on a resource
   Description: The lockdiscovery property returns a listing of who has
   a lock, what type of lock he has, the timeout type and the time
   remaining on the timeout, and the associated lock token.  The server
   is free to withhold any or all of this information if the requesting
   principal does not have sufficient access rights to see the
   requested data.  A server which supports locks MUST provide the
   lockdiscovery property on any resource with locks on it.

   <!ELEMENT lockdiscovery (activelock)* >

12.9.1    Example

   >>Request

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

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:prop><lockdiscovery/></D:prop>

   </D:propfind>

   >>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx
   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:multistatus>
     <D:response>
       <D:propstat>
          <D:prop>
            <D:lockdiscovery>
              <D:activelock>
                <D:locktype>write</D:locktype>
                <D:lockscope>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>

   This resource has a single exclusive write lock on it, with an
   infinite timeout.  Note that the Depth element could have been
   omitted as 0 is the default value of Depth.

12.10     resourcetype Property

   Name:       resourcetype
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    Specifies the nature of the resource.
   Description: This property MUST be defined on all DAV compliant
   resources.  The default value is empty.

   <!ELEMENT resourcetype ANY >

12.11     source Property

   Name:       source
   Namespace:  http://www.iana.org/standards/dav/link/
   Purpose:    The destination of the source link identifies the
   resource that contains the unprocessed source of the link's source.
   Description: The source of the link (src) is typically the URI of
   the output resource on which the link is defined, and there is
   typically only one destination (dst) of the link, which is the URI
   where the unprocessed source of the resource may be accessed.  When
   more than one link destination exists, this specification asserts no
   policy on ordering.

   <!ELEMENT source (link)* >

12.11.1   Example

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

   In this 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.

12.12     supportedlock Property

   Name:       supportedlock
   Namespace:  http://www.iana.org/standards/dav/
   Purpose:    To provide a listing of the lock capabilities supported
   by the resource.
   Description: The supportedlock property of a resource returns a
   listing of the combinations of scope and access types which may be
   specified in a lock request on the resource.  Note that the actual
   contents are themselves controlled by access controls so a server is
   not required to provide information the client is not authorized to
   see.  If supportedlock is available on "*" then it MUST define the
   set of locks allowed on all resources on that server.

   <!ELEMENT supportedlock (lockentry)* >

12.12.1   Example

   >>Request

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

   <?xml version="1.0"?>
   <?namespace href="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:prop><supportedlock/></D:prop>
   </D:propfind>

   >>Response

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

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

13 DAV Compliance Classes
   A DAV compliant resource can choose from two classes of compliance.
   A client can discover the compliance classes of a resource by
   executing OPTIONS on the resource, and examining the "DAV" header
   which is returned.

   Since this document describes extensions to the HTTP/1.1 protocol,
   minimally all DAV compliant resources, clients, and proxies MUST be
   compliant with [Fielding et al., 1997].

   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.

13.1 Class 1

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

   Class 1 compliant resources MUST return, at minimum, the value "1"
   in the DAV header on all responses to the OPTIONS method.

13.2 Class 2

   A class 2 compliant resource MUST meet all class 1 requirements and
   support the supportedlock property as well as the LOCK method. It
   MUST also support the lockdiscovery property, since Section 12.9
   specifies that the LOCK method MUST also support the lockdiscovery
   property.

   Class 2 compliant resources MUST return, at minimum, the value "2"
   in the DAV header on all responses to the OPTIONS method.

14 Internationalization Considerations

   In the realm of internationalization, this specification complies
   with the IETF Character Set Policy [Alvestrand, 1998]. 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 using the UTF-8 and UCS-2 encodings of the ISO 10646 basic
   multilingual plane.  Furthermore, XML contains provisions for
   encoding XML elements using other encoding schemes, notable among
   them UCS-4, which permits encoding of characters from any ISO 10646
   character plane.

   The default character set encoding for XML data in this
   specification, and in general, is UTF-8.  WebDAV compliant
   applications MUST support the UTF-8 and UCS-2 character set
   encodings for XML elements, and SHOULD support the UCS-4 encoding.
   The XML character set encoding declaration for each supported
   character set MUST also be supported, since it is by using this
   encoding declaration that an XML processor determines the encoding
   of an element.

   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 RFC 1766, [Alvestrand,
   1995]) or ISO 639 language tags [ISO-639] in the "xml:lang"
   attribute of an XML element to identify the language its content and
   attributes.

   Names used within this specification fall into three categories:
   names of protocol elements such as methods and headers, names of XML
   elements, and names of properties.  Naming of protocol elements
   follows the precedent of HTTP, using English names encoded in
   USASCII for methods and headers.  Since these protocol elements are
   not visible to users, and are in fact simply long token identifiers,
   they do not need to support encoding in multiple character sets.
   Similarly, though the names of XML elements used in this
   specification are English names encoded in UTF-8, these names are
   not visible to the user, and hence do not need to support multiple
   character set encodings.

   The name of a property defined on a resource is a URI.  Although
   some applications (e.g., a generic property viewer) will display
   property URIs directly to their users, it is expected that the
   typical application will use a fixed set of properties, and will
   provide a mapping from the property name URI to a human-readable
   field when displaying the property name to a user.  It is only in
   the case where the set of properties is not known ahead of time that
   an application need display a property name URI to a user. We
   recommend that applications provide human-readable property names
   wherever feasible.

   For error reporting, we follow the convention of HTTP/1.1 status
   codes, including with each status code a short, English description
   of the code (e.g., 425 Locked).  While the possibility exists that a
   poorly crafted user agent would display this message to a user,
   internationalized applications will ignore this message, and display
   an appropriate message in the user's language and character set.

   Since interoperation of clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of this information.

15 Security Considerations

   This section is provided to detail issues concerning security
   implications of which WebDAV applications need to be aware.

   All of the security considerations of HTTP/1.1 also apply to WebDAV.
   In addition, the security risks inherent in remote authoring require
   stronger authentication technology, and introduce several new
   privacy concerns, and may increase the hazards from poor server
   design. These issues are detailed below.

15.1 Authentication of Clients

   Due to their emphasis on authoring, WebDAV servers need to use
   authentication technology to protect not just access to a network
   resource, but the integrity of the resource as well.  Furthermore,
   the introduction of locking functionality requires support for
   authentication.

   A password sent in the clear over an insecure channel is an
   inadequate means for protecting the accessibility and integrity of a
   resource as the password may be intercepted.  Since Basic
   authentication for HTTP/1.1 performs essentially clear text
   transmission of a password, Basic authentication MUST NOT be used to
   authenticate a WebDAV client to a server unless the connection is
   secure. Furthermore, a WebDAV server MUST NOT send Basic
   authentication credentials in a WWW-Authenticate header unless the
   connection is secure.  Examples of secure connections include a
   Transport Layer Security (TLS) connection, or a connection over a
   network which is physically secure, for example, an isolated network
   in a building with restricted access.

   WebDAV applications MUST support the Digest authentication scheme
   [Franks, et al., 1997]. 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.

15.2 Denial of Service

   Denial of service attacks are of special concern to WebDAV servers.
   WebDAV plus HTTP enables denial of service attacks on every part of
   a system's resources.

   The underlying storage can be attacked by PUTting extremely large
   files.

   Asking for recursive operations on large collections can attack
   processing time.

   Making multiple pipelined requests on multiple connections can
   attack network connections.

   WebDAV servers need to be aware of the possibility of a denial of
   service attack at all levels.

15.3 Security through Obscurity

   WebDAV provides, through the PROPFIND method, a mechanism for
   listing the member resources of a collection.  This greatly
   diminishes the effectiveness of security or privacy techniques which
   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.

15.4 Privacy Issues Connected to Locks

   When submitting a lock request a user agent may also submit an owner
   XML field giving contact information for the person taking out the
   lock (for those cases where a person, rather than a robot, is taking
   out the lock). This contact information is stored in a lockdiscovery
   property on the resource, and can be used by other collaborators to
   begin negotiation over access to the resource.  However, in many
   cases this contact information can be very private, and should not
   be widely disseminated.  Servers SHOULD limit read access to the
   lockdiscovery property as appropriate.  Furthermore, user agents
   SHOULD provide control over whether contact information is sent at
   all, and if contact information is sent, control over exactly what
   information is sent.

15.5 Privacy Issues Connected to Properties

   Since property values are typically used to hold information such as
   the author of a document, there is the possibility that privacy
   concerns could arise stemming from widespread access to a resource's
   property data.  To reduce the risk of inadvertent release of private
   information via properties, servers are encouraged to develop access
   control mechanisms that separate read access to the resource body
   and read access to the resource's properties.  This allows a user to
   control the dissemination of their property data without overly
   restricting access to the resource's contents.

15.6 Reduction of Security due to Source Link

   HTTP/1.1 warns against providing read access to script code because
   it may contain sensitive information.  Yet WebDAV, via its source
   link facility, can potentially provide a URL 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.

16 IANA Considerations

   This document defines two namespaces, the namespace of property
   names, and the namespace of WebDAV-specific XML elements used within
   property values.

   URLs are used for both names, for several reasons. Assignment of a
   URL 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.  URLs also provide a
   unique address space, ensuring that the distributed users of WebDAV
   will not have collisions among the property names and XML elements
   they create.

   This specification defines a distinguished set of property names and
   XML elements which are understood by all WebDAV applications.  The
   property names and XML elements in this specification are all
   derived from the base URL: http://www.iana.org/standards/dav/ by
   adding a suffix to this URL, for example,
   http://www.iana.org/standards/dav/creationdate for the
   "creationdate" property.

   To ensure correct interoperation of this specification, IANA MUST
   reserve the URL namespace starting with
   http://www.iana.org/standards/dav/ for use by this specification,
   its revisions, and related WebDAV specifications.

17 Terminology

   Collection - A resource that contains member resources.

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

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

   External Member Resource - A member resource of a collection with an
   absolute URI that is not relative to its parent's URI.

   Property - A name/value pair that contains descriptive information
   about a resource.

   Live Property - A property whose semantics and syntax are enforced
   by the server.  For example, a live "content-length" property would
   have its value, the length of the entity returned by a GET request,
   automatically calculated by the server.

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

18 Copyright

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this
   document.

   Copyright (C) The Internet Society January 18, 1998. All Rights
   Reserved.

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

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

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

19 Intellectual Property

   The following notice is copied from RFC 2026 [Bradner, 1996],
   Section 10.4, and describes the position of the IETF concerning
   intellectual property claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

20 Acknowledgements

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

   Terry Allen, Harald Alvestrand, Alan Babich, 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, Roy Fielding, Mark Fisher,
   Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker,
   Dennis Hamilton, Steve Henning, Alex Hopmann, Andre van der Hoek,
   Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin,
   Larry Masinter, Michael Mealling, Keith Moore, Henrik Nielsen, Kenji
   Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry
   Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar
   Stefferud, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert
   Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory
   Woodhouse, and Lauren Wood.

   Two from this list deserve special mention.  The contributions by
   Larry Masinter have been invaluable, both in helping the formation
   of the working group and in patiently coaching the authors along the
   way.  In so many ways he has set high standards we have toiled to
   meet. The contributions of Judith Slein in clarifying the
   requirements, and in patiently reviewing draft after draft, both
   improved this specification and expanded our minds on document
   management.

   We would also like to thank John Turner for developing the XML DTD.

21 References

   [Alvestrand, 1995] H. T. Alvestrand, "Tags for the Identification of
   Languages." RFC 1766. Uninett. March, 1995.

   [Alvestrand, 1998] H. T. Alvestrand, "IETF Policy on Character Sets
   and Languages." RFC XXXX, BCP YY. Maxware. January, 1998.

   [Bradner, 1996] S. Bradner, "The Internet Standards Process -
   Revision 3."  RFC 2026, BCP 9. Harvard University. October, 1996.

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

   [Bray, Paoli, Sperberg-McQueen, 1998] T. Bray, J. Paoli, C. M.
   Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web
   Consortium Recommendation REC-XML-ZZZZ. http://www.w3.org/TR/PR-xml-
   971208.

   [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
   Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
   RFC 2068. U.C. Irvine, DEC, MIT/LCS.  January, 1997.

   [ISO-639] ISO (International Organization for Standardization). ISO
   639:1988. "Code for the representation of names of languages."

   [ISO-8601] ISO (International Organization for Standardization). ISO
   8601:1988. "Data elements and interchange formats - Information
   interchange - Representation of dates and times."

   [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
   Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.

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

   [MARC, 1994] Network Development and MARC Standards, Office, ed.
   1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC:
   Cataloging Distribution Service, Library of Congress.

   [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
   Treese, "PICS Label Distribution Label Syntax and Communication
   Protocols" Version 1.1, World Wide Web Consortium Recommendation
   REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS-
   labels-961031.html.

   [Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead, Jr.,
   D. Durand, "Requirements for Distributed Authoring and Versioning
   Protocol for the World Wide Web." RFC XXXX. Xerox, Univ. of Bologna,
   U.C. Irvine, Boston Univ. YYY, 1997.

   [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
   "OCLC/NCSA Metadata Workshop Report."
   http://purl.oclc.org/metadata/dublin_core_report.

   [Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of
   Unicode and ISO 10646." RFC 2044. Alis Technologies. October, 1996.

22 Authors' Addresses

   Y. Y. Goland
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Email: yarong@microsoft.com

   E. J. Whitehead, Jr.
   Dept. Of Information and Computer Science
   University of California, Irvine
   Irvine, CA 92697-3425
   Email: ejw@ics.uci.edu

   A. Faizi
   Netscape
   685 East Middlefield Road
   Mountain View, CA 94043
   Email: asad@netscape.com

   S. R. Carter
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399
   Email: srcarter@novell.com

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

23 Appendices

23.1 Appendix 1 - WebDAV Document Type Definition

   This section provides a document type definition, following the
   rules in [Bray, Paoli, Sperberg-McQueen, 1998], for the XML elements
   used in the protocol stream and in the values of properties. It
   collects the element definitions given in Sections 11 and 12.

   <!DOCTYPE webdav-1.0 [

   <!--============ XML Elements from Section 11 ==================-->

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

   <!ELEMENT lockentry (lockscope, locktype) >
   <!ELEMENT lockinfo (lockscope, locktype, owner?) >

   <!ELEMENT locktype (write) >
   <!ELEMENT write EMPTY >

   <!ELEMENT lockscope (exclusive | shared) >
   <!ELEMENT exclusive EMPTY >
   <!ELEMENT shared EMPTY >

   <!ELEMENT depth (#PCDATA) >

   <!ELEMENT owner (#PCDATA, ANY)* >

   <!ELEMENT timeout (#PCDATA) >

   <!ELEMENT locktoken (href) >

   <!ELEMENT href (#PCDATA) >

   <!ELEMENT link (src+, dst+) >
   <!ELEMENT dst (#PCDATA) >
   <!ELEMENT src (#PCDATA) >

   <!ELEMENT multistatus (response+, responsedescription?) >

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription?) >
   <!ELEMENT status (#PCDATA) >
   <!ELEMENT propstat (prop status) >
   <!ELEMENT responsedescription (#PCDATA) >

   <!ELEMENT prop ANY >

   <!ELEMENT propertybehavior (omit | keepalive) >
   <!ELEMENT omit EMPTY >
   <!ELEMENT keepalive (#PCDATA | href+) >

   <!ELEMENT propertyupdate (remove | set)+ >
   <!ELEMENT remove (prop) >
   <!ELEMENT set (prop) >

   <!ELEMENT propfind (allprop | propname | href+) >
   <!ELEMENT allprop EMPTY >
   <!ELEMENT propname EMPTY >

   <!ELEMENT collection EMPTY >

   <!--=========== Property Elements from Section 12 ===============-->

   <!ELEMENT creationdate (#PCDATA) >
   <!ELEMENT displayname (#PCDATA) >
   <!ELEMENT externalmembers (href*) >
   <!ELEMENT getcontentlanguage (#PCDATA) >
   <!ELEMENT getcontentlength (#PCDATA) >
   <!ELEMENT getcontenttype (#PCDATA) >
   <!ELEMENT getetag (#PCDATA) >
   <!ELEMENT getlastmodified (#PCDATA) >
   <!ELEMENT lockdiscovery (activelock)* >
   <!ELEMENT resourcetype ANY >
   <!ELEMENT source (link)* >
   <!ELEMENT supportedlock (lockentry)* >

   ]>

23.2 Appendix 2 - ISO 8601 Date and Time Profile

   The creationdate property specifies the use of the ISO 8601 date
   format.  This section defines a profile of the ISO 8601 date format
   for use with this specification.  This profile is quoted verbatim
   from draft-newman-datetime-01.txt (expired).

   date-time       = full-date "T" full-time

   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
   month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset
   partial-time    = time-hour ":" time-minute ":" time-second
                    [time-secfrac]

   Numeric offsets are calculated as local time minus UTC (Coordinated
   Universal Time).  So the equivalent time in UTC can be determined by
   subtracting the offset from the local time.  For example, 18:50:00-
   04:00 is the same time as 22:58:00Z.

   If the time in UTC is known, but the offset to local time is
   unknown, this can be represented with an offset of "-00:00".  This
   differs from an offset of "Z" which implies that UTC is the
   preferred reference point for the specified time.

23.3 Appendix 3 - Notes on Processing XML Elements

   XML is a flexible data format that makes it easy to submit data that
   appears legal but in fact is not.  The philosophy of "Be flexible in
   what you accept and strict in what you send" still applies, but it
   must not be applied inappropriately.  XML is extremely flexible in
   dealing with issues of white space, element ordering, inserting new
   elements, etc.  This flexibility does not require extension,
   especially not in the area of the meaning of elements.

   There is no kindness in accepting illegal combinations of XML
   elements.  At best it will cause an unwanted result and at worst it
   can cause real damage.

23.3.1    XML Syntax Error Example

   The following request body for a PROPFIND method is illegal.

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <D:propfind>
     <D:allprop/>
     <D:propname/>
   </D:propfind>

   The definition of the propfind element only allows for the allprop
   or the propname element, not both.  Thus the above is an error and
   MUST be responded to with a 400 Bad Request.

   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.

23.3.2    Unknown XML Element Example
   The previous example was illegal because it contained two elements
   that were explicitly banned from appearing together in the propfind
   element.  However, XML is an extensible language, so one can imagine
   new elements being defined for use with propfind.  Below is the
   request body of a PROPFIND and, like the previous example, MUST be
   rejected with a 400 Bad Request by a server that does not understand
   the expired-props element.

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.foo.bar/standards/props/" as="E"?>
   <D:propfind>
     <E:expired-props/>
   </D:propfind>

   To understand why a 400 Bad Request is returned let us look at the
   request body as the server unfamiliar with expired-props sees it.

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.foo.bar/standards/props/" as="E"?>
   <D:propfind>
   </D:propfind>

   As the server does not understand the expired-props element, by the
   rules of XML, it MUST ignore it.  Thus the server sees an empty
   propfind, which by the definition of the propfind element is
   illegal.

   Please note that had the extension been additive it would not
   necessarily have resulted in a 400 Bad Request.  For example,
   imagine the following request body for a PROPFIND:

   <?xml version="1.0"?>
   <?namespace href ="http://www.iana.org/standards/dav/" as="D"?>
   <?namespace href="http://www.foo.bar/standards/props/" as="E"?>
   <D:propfind>
     <D:propname/>
     <E:leave-out>*boss*</E:leave-out>
   </D:propfind>

   The previous example contains the fictitious element leave-out. Its
   purpose is to prevent the return of any property whose name matches
   the submitted pattern.  If the previous example were submitted to a
   server unfamiliar with leave-out, the only result would be that the
   leave-out element would be ignored and a propname would be executed.
X-Generator: pyht 0.35