idnits 2.17.1 draft-ietf-webdav-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 36) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 23 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The _Second_ TimeType specifies the number of seconds that MUST elapse between granting of the lock at 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 1997) is 9655 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Lagoze' is mentioned on line 432, but not defined == Missing Reference: 'Extension' is mentioned on line 753, but not defined == Missing Reference: 'VTML' is mentioned on line 2128, but not defined == Missing Reference: 'ISO8601' is mentioned on line 2841, but not defined == Missing Reference: 'TBD' is mentioned on line 3280, but not defined == Unused Reference: 'WebDAV' is defined on line 3417, but no explicit reference was found in the text == Unused Reference: 'Yergeau' is defined on line 3425, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Alvestrand' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berners-Lee' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bray' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sperberg-McQueen' ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. 'Lasher') -- Duplicate reference: RFC1807, mentioned in 'Cohen', was also mentioned in 'Lasher'. ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. 'Cohen') -- Duplicate reference: RFC1807, mentioned in '1995', was also mentioned in 'Cohen'. ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. '1995') -- Possible downref: Non-RFC (?) normative reference: ref. 'Leach' -- Possible downref: Non-RFC (?) normative reference: ref. 'Salz' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maloney' -- Possible downref: Non-RFC (?) normative reference: ref. '1996' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARC' -- Possible downref: Non-RFC (?) normative reference: ref. '1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'WebDAV' -- Duplicate reference: draft-yergeau-utf8-rev, mentioned in 'Yergeau', was also mentioned in '1997'. Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group Y.Y. Goland, Microsoft 3 INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine 4 A. Faizi, Netscape 5 S.R. Carter, Novell 6 D. Jensen, Novell 7 Expires April, 1998 November 19, 1997 9 Extensions for Distributed Authoring on the World Wide Web -- WEBDAV 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or made obsolete by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. Please send comments to 30 the Distributed Authoring and Versioning (WEBDAV) working group at 31 , which may be joined by sending a message 32 with subject "subscribe" to . 34 Discussions of the WEBDAV working group are archived at 35 . 37 Abstract 39 This document specifies a set of methods, headers, and content-types 40 ancillary to HTTP/1.1 for the management of resource properties, 41 creation and management of resource collections, namespace 42 manipulation, resource locking (collision avoidance), and efficient 43 transmission of resource changes. 45 Changes 47 1.1. Changes since draft-ietf-webdav-protocol-04.txt 49 [Editor's note: This section will not appear in the final form of 50 this document. Its purpose is to provide a concise list of changes 51 from the previous revision of the draft for use by reviewers.] 53 Added this change section. 55 Removed scoping for namespaces so the namespace for 56 every element is explicitly stated. 58 Changed the syntax from to . 60 Removed propfindresult, this was left over from the old search 61 format. 63 Changed all the DAV XML element names to lower case. 65 Changed the property format to use Name and Namespace rather than 66 name and schema. 68 Removed proploc attribute and removed section on GETting, DELETEing, 69 and PUTing properties since we do not provide a mechanism for 70 getting a URI for properties. Also removed the requirement that 71 properties be URI addressable. 73 Removed quoted string choice from owner header, it is just XML. 75 Made all the HTTP error codes use the same format. 77 Changed the name of the create element in PROPPATCH to set, the new 78 name seems to cause less confusion. 80 Moved all headers in the draft to a single section. 82 Deleted the state token section of the draft and moved the state 83 token headers to the header section of the draft. Removed the state 84 token header. 86 Changed the write lock section to state that a Lock-Token request 87 header, not a state-token request header, is to be submitted on 88 request for write locked resources. 90 Created a "generic" XML element section for XML elements that get 91 repeatedly re-used throughout the spec. I moved LINK XML element to 92 this section. 94 Made multistatus and Schema discovery their own level one sections. 96 Collected all the properties together. 98 Removed all references to the possibility of properties have their 99 own URIs. This includes removing the property identifier section. 101 Separated the section on web collections and namespaces into two 102 separate sections. 104 Collected all the new response codes together into their own 105 section. 107 Changed the XML multiresponse element name to multistatus. 109 Added a stand alone section on levels of DAV compliance. I also went 110 method by method, property by property, to specify compliance 111 requirements. 113 Added an introduction. 115 Changed all the "True" and "False" to "T" and "F". 117 Altered the first two paragraphs of the Property Names section to 118 make the relationship between a property's name and its schema a 119 little clearer. I also added some text in the same section defining 120 a property name as a namespace and element. 122 Added a second paragraph to property model for http resources - 123 overview. This paragraph clarifies why XML was chosen. 125 Added a 409 Conflict error to move to cover attempts to move a 126 collection with members. 128 Changed the collection requirement to read the collections SHOULD 129 end with "/". Also added a SHOULD about returning a location header 130 if the client submits a URL for a collection without a trailing "/". 132 Moved the owner header into the body due to size concerns. 134 Replaced the iscollection xml element with resourcetype. 136 Moved the DAV property to the DAV header that is returned with 137 OPTIONS. 139 Folded the tree draft into this draft. Changed the DELETE, COPY, 140 and MOVE sections to include their effect on collections as taken 141 from the tree draft. Created a Depth header section and put in the 142 general rules that were in the introduction to the tree draft. I 143 also added the 102 response and response-status header. 145 Removed the versioning section. 147 Put all the methods into a single section. 149 Replaced the PROPFIND request body with a propfind header. Now the 150 response can be cached just using vary. 152 Nuked resinfo for INDEX and combined it with multistatus which is 153 now used for both INDEX and PROPFIND. Stripped down INDEX as 154 agreed. 156 Removed the problem definition and proposed solution sections. We 157 can always cut and paste them together from the older version if we 158 feel we need them but this draft is supposed to be a dry run for 159 last call and last call documents do not have problem 160 definition/proposed solution sections. 162 Killed the section on schema discovery, it is controversial and we 163 aren't going to be able to require it. We should specify it in a 164 different spec. 166 Added a section on notational conventions used within the document. 168 Moved the terminology section to the end of the document to provide 169 better flow from the high-level introduction to the specific 170 introduction sections. 172 Increased the numeric value of the 4xx status codes introduced in 173 this specification to avoid conflicts with the new revision of the 174 HTTP/1.1 specification, which introduces two new 4xx status codes. 176 Wrote internationalization concerns section. 178 Added XML version number to all examples. 180 Contents 182 STATUS OF THIS MEMO...................................................1 183 ABSTRACT..............................................................1 184 CHANGES...............................................................1 186 1.1. Changes since draft-ietf-webdav-protocol-04.txt..................1 187 CONTENTS..............................................................5 188 2. INTRODUCTION.......................................................8 189 3. DATA MODEL FOR RESOURCE PROPERTIES.................................9 190 3.1. The Resource Property Model......................................9 191 3.2. Existing Metadata Proposals.....................................10 192 3.3. Properties and HTTP Headers.....................................10 193 3.4. Property Values.................................................10 195 3.5. Property Names..................................................11 196 4. COLLECTIONS OF WEB RESOURCES......................................11 197 4.1. Collection Resources............................................11 198 4.2. Creation and Retrieval of Collection Resources..................12 199 4.3. HTTP URL Namespace Model........................................13 200 4.4. Source Resources and Output Resources...........................13 201 5. LOCKING...........................................................14 203 5.1. Exclusive Vs. Shared Locks......................................14 204 5.2. Required Support................................................15 205 5.3. Lock Tokens.....................................................16 206 5.4. opaquelocktoken Lock Token URI Scheme...........................16 207 5.5. Lock Capability Discovery.......................................16 208 5.6. Active Lock Discovery...........................................17 209 6. WRITE LOCK........................................................17 210 6.1. Methods Restricted by Write Locks...............................17 212 6.2. Write Locks and Properties......................................17 213 6.3. Write Locks and Null Resources..................................17 214 6.4. Write Locks and Collections.....................................18 215 6.5. Write Locks and COPY/MOVE.......................................18 216 6.6. Re-issuing Write Locks..........................................18 217 6.7. Write Locks and The Lock-Token Request Header...................18 218 7. NOTATIONAL CONVENTIONS............................................19 220 8. HTTP METHODS FOR DISTRIBUTED AUTHORING............................19 221 8.1. PROPFIND........................................................19 222 8.2. PROPPATCH.......................................................23 223 8.3. MKCOL Method....................................................25 224 8.4. INDEX Method....................................................26 225 8.5. DELREF Method...................................................28 226 8.6. ADDREF Method...................................................28 227 8.7. GET, HEAD for Collections.......................................29 229 8.8. POST for Collections............................................29 230 8.9. DELETE..........................................................29 231 8.10. PUT............................................................31 232 8.11. COPY Method....................................................31 233 8.12. MOVE Method....................................................35 234 8.13. LOCK Method....................................................38 236 8.14. UNLOCK Method..................................................42 237 8.15. PATCH Method...................................................43 238 9. DAV HEADERS.......................................................47 239 9.1. Collection-Member Header........................................47 240 9.2. DAV Header......................................................47 241 9.3. Depth Header....................................................47 242 9.4. Destination Header..............................................48 243 9.5. Destroy Header..................................................48 245 9.6. Enforce-Live-Properties Header..................................49 246 9.7. If-None-State-Match.............................................49 247 9.8. If-State-Match..................................................50 248 9.9. Lock-Info Request Header........................................50 249 9.10. Lock-Token Request Header......................................51 250 9.11. Lock-Token Response Header.....................................51 251 9.12. Overwrite Header...............................................52 253 9.13. Propfind Request Header........................................52 254 9.14. Status-URI Response Header.....................................52 255 9.15. Timeout Header.................................................52 256 10. RESPONSE CODE EXTENSIONS TO RFC 2068.............................54 257 10.1. 102 Processing.................................................54 258 10.2. 207 Multi-Status...............................................54 259 10.3. 418 Unprocessable Entity.......................................54 260 10.4. 419 Insufficient Space on Resource.............................54 262 10.5. 420 Method Failure.............................................54 263 11. MULTI-STATUS RESPONSE............................................54 264 11.1. multistatus XML Element........................................55 265 11.2. response XML Element...........................................55 266 11.3. status XML Element.............................................55 267 11.4. responsedescription XML Element................................55 268 12. GENERIC DAV XML ELEMENTS.........................................55 270 12.1. href XML Element...............................................56 271 12.2. link XML Element...............................................56 272 12.3. prop XML element...............................................57 273 13. DAV PROPERTIES...................................................57 274 13.1. creationdate Property..........................................57 275 13.2. displayname Property...........................................57 276 13.3. get-content-language Property..................................58 277 13.4. get-content-length Property....................................58 279 13.5. get-content-type Property......................................58 280 13.6. get-etag Property..............................................58 281 13.7. get-last-modified Property.....................................59 282 13.8. index-content-language Property................................59 283 13.9. index-content-length Property..................................59 284 13.10. index-content-type Property...................................59 285 13.11. index-etag Property...........................................59 287 13.12. index-last-modified Property..................................60 288 13.13. lockdiscovery Property........................................60 289 13.14. resourcetype Property.........................................62 290 13.15. Source Link Property Type.....................................62 291 13.16. supportedlock Property........................................63 292 14. DAV COMPLIANCE LEVELS............................................64 293 14.1. Level 1........................................................64 294 14.2. Level 2........................................................64 296 15. INTERNATIONALIZATION SUPPORT.....................................65 297 16. SECURITY CONSIDERATIONS..........................................66 298 17. TERMINOLOGY......................................................66 299 18. COPYRIGHT........................................................66 300 19. ACKNOWLEDGEMENTS.................................................67 301 20. REFERENCES.......................................................69 302 21. AUTHORS' ADDRESSES...............................................71 303 2. Introduction 305 This document describes an extension to the HTTP/1.1 protocol that 306 allows clients to perform remote web content authoring operations. 307 This extension provides a coherent set of methods, headers, request 308 entity body formats, and response entity body formats that provide 309 operations for: 311 Properties: The ability to create, remove, and query information 312 about Web pages, such as its author, creation date, etc. Also, the 313 ability to link pages of any media type to related pages. 315 Collections: The ability to create sets of related documents, and to 316 receive a listing of pages at a particular hierarchy level (like a 317 directory listing in a file system). 319 Locking: The ability to keep more than one person from working on a 320 document at the same time. This prevents the "lost update problem" 321 in which modifications are lost as first one author, then another 322 writes their changes without merging the other author's changes 324 Namespace Operations: The ability to copy and move Web resources 326 Efficient Update: The ability to send changes which are proportional 327 to the size of the change rather than retransmitting the entire 328 resource. 330 Requirements and rationale for these operations are described in a 331 companion document, "Requirements for a Distributed Authoring and 332 Versioning Protocol for the World Wide Web" [Slein et al., 1997]. 334 The sections below provide a detailed introduction to resource 335 properties (Section 3), collections of resources (Section 4), and 336 locking operations (Section 5). These sections introduce the 337 abstractions manipulated by the WebDAV-specific HTTP methods 338 described in Section 8, "HTTP Methods for Distributed Authoring". 340 In HTTP/1.1, method parameter information was exclusively encoded in 341 HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter 342 information either in an Extensible Markup Language (XML) [Bray, 343 Sperberg-McQueen, 1997] request entity body, or in an HTTP header. 344 The use of XML to encode method parameters was motivated by the 345 ability to add extra XML elements to existing structures, providing 346 extensibility, and by XML's ability to encode information in ISO 347 10646 character sets, providing internationalization support. As a 348 rule of thumb, parameters are encoded in XML entity bodies when they 349 have unbounded length, or when they may be shown to a human user and 350 hence require encoding in an ISO 10646 character set. Otherwise, 351 parameters are encoded within an HTTP header. Section 9 describes 352 the new HTTP headers used with WebDAV methods. 354 In addition to encoding method parameters, XML is used in WebDAV to 355 encode the responses from methods, providing the extensibility and 356 internationalization advantages of XML for method output, as well as 357 input. XML elements used in this specification are defined in 358 Section 12. 360 While the response codes provided by HTTP/1.1 are sufficient to 361 describe the preponderance of error conditions encountered by WebDAV 362 methods, there are some errors that do not fall neatly into the 363 existing categories. New status codes developed for the WebDAV 364 methods are defined in Section 10. Since some WebDAV methods may 365 operate over many resources, the multiresponse status type has been 366 introduced to return status information for multiple resources. 367 Multiresponse status is described in Section 11. 369 The properties mechanism is employed by WebDAV to store information 370 about the current state of the resource. For example, when a lock 371 is taken out on a resource, a lock information property describes 372 the current state of the lock. Section 13 defines the properties 373 used within the WebDAV specification. 375 Finishing off the specification are sections on what it means to be 376 compliant with this specification (Section 14), on 377 internationalization support (Section 15), and on security (Section 378 16). 380 3. Data Model for Resource Properties 382 3.1. The Resource Property Model 384 Properties are pieces of data that describe the state of a resource. 385 Properties are data about data. 387 Properties are used in distributed authoring environments to provide 388 for efficient discovery and management of resources. For example, a 389 'subject' property might allow for the indexing of all resources by 390 their subject, and an 'author' property might allow for the 391 discovery of what authors have written which documents. 393 The DAV property model consists of name/value pairs. The name of a 394 property identifies the property's syntax and semantics, and 395 provides an address by which to refer to that syntax and semantics. 397 There are two categories of properties: "live" and "non-live". A 398 live property has its syntax and semantics enforced by the server. 399 This represents the two cases of a) the value of a property is read- 400 only, maintained by the server, and b) the value of the property is 401 maintained by the client, but server performs syntax checking on 402 submitted values. A non-live property has its syntax and semantics 403 enforced by the client; the server merely records the value of the 404 property verbatim. 406 3.2. Existing Metadata Proposals 408 Properties have long played an essential role in the maintenance of 409 large document repositories, and many current proposals contain some 410 notion of a property, or discuss web metadata more generally. These 411 include PICS [Miller et al., 1996], PICS-NG, the Rel/Rev draft 412 [Maloney, 1996], Web Collections, XML [Bray, Sperberg-McQueen, 413 1997], several proposals on representing relationships within HTML, 414 digital signature manifests (DCMF), and a position paper on Web 415 metadata architecture [Berners-Lee, 1997]. Work on PICS-NG and Web 416 Collections has been subsumed by the Resource Definition Framework 417 (RDF) metadata activity of the World Wide Web Consortium, which 418 consists of a network-based data model and an XML representation of 419 that model. 421 Some proposals come from a digital library perspective. These 422 include the Dublin Core [Weibel et al., 1995] metadata set and the 423 Warwick Framework [Lagoze, 1996], a container architecture for 424 different metadata schemas. The literature includes many examples 425 of metadata, including MARC [MARC, 1994], a bibliographic metadata 426 format, and RFC 1807 [Lasher, Cohen, 1995], a technical report 427 bibliographic format employed by the Dienst system. Additionally, 428 the proceedings from the first IEEE Metadata conference describe 429 many community-specific metadata sets. 431 Participants of the 1996 Metadata II Workshop in Warwick, UK 432 [Lagoze, 1996], noted that, "new metadata sets will develop as the 433 networked infrastructure matures" and "different communities will 434 propose, design, and be responsible for different types of 435 metadata." These observations can be corroborated by noting that 436 many community-specific sets of metadata already exist, and there is 437 significant motivation for the development of new forms of metadata 438 as many communities increasingly make their data available in 439 digital form, requiring a metadata format to assist data location 440 and cataloging. 442 3.3. Properties and HTTP Headers 444 Properties already exist, in a limited sense, in HTTP message 445 headers. However, in distributed authoring environments a 446 relatively large number of properties are needed to describe the 447 state of a resource, and setting/returning them all through HTTP 448 headers is inefficient. Thus a mechanism is needed which allows a 449 principal to identify a set of properties in which the principal is 450 interested and to then set or retrieve just those properties. 452 3.4. Property Values 454 The value of a property is expressed as a well-formed XML document. 456 XML has been chosen because it is a flexible, self-describing, 457 structured data format that supports rich schema definitions, and 458 because of its support for multiple character sets. XML's self- 459 describing nature allows any property's value to be extended by 460 adding new elements. Older clients will not break because they will 461 still have the data specified in the original schema and will ignore 462 elements they do not understand. XML's support for multiple 463 character sets allows human-readable properties to be encoded and 464 read in a character set familiar to the user. 466 3.5. Property Names 468 A property name is a universally unique identifier that is 469 associated with a schema that provides information about the syntax 470 and semantics of the property. 472 Because a property's name is universally unique, clients can depend 473 upon consistent behavior for a particular property across multiple 474 resources, so long as that property is "live" on the resources in 475 question. 477 The XML namespace mechanism, which is based on URIs, is used to name 478 properties because it provides a mechanism to prevent namespace 479 collisions and for varying degrees of administrative control. 481 The property namespace is flat; that is, no hierarchy of properties 482 is explicitly recognized. Thus, if a property A and a property A/B 483 exist on a resource, there is no recognition of any relationship 484 between the two properties. It is expected that a separate 485 specification will eventually be produced which will address issues 486 relating to hierarchical properties. 488 Finally, it is not possible to define the same property twice on a 489 single resource, as this would cause a collision in the resource's 490 property namespace. 492 4. Collections of Web Resources 494 This section provides a description of a new type of Web resource, 495 the collection, and discusses its interactions with the HTTP URL 496 namespace. The purpose of a collection resource is to model 497 collection-like objects (e.g., filesystem directories) within a 498 server's namespace. 500 All DAV compliant resources MUST support the HTTP URL namespace 501 model specified herein. 503 4.1. Collection Resources 505 A collection is a resource whose state consists of an unordered list 506 of internal members, an unordered list of external members, and a 507 set of properties. An internal member resource MUST have a URI that 508 is immediately relative to the base URI of the collection, that is, 509 a relative URI in which "../" is illegal, which MUST begin with "./" 510 and which SHOULD contain a "/" at the end of the URI if the internal 511 member resource is itself a collection. 513 An external member resource MUST be an absolute URI that is not an 514 internal URI. Any given internal or external URI MUST only belong 515 to the collection once, i.e., it is illegal to have multiple 516 instances of the same URI in a collection. Properties defined on 517 collections behave exactly as do properties on non-collection 518 resources. 520 There is a standing convention that when a collection is referred to 521 by its name without a trailing slash, the trailing slash is 522 automatically appended. Due to this, a resource MAY accept a URI 523 without a trailing "/" to point to a collection. In this case it 524 SHOULD return a location header in the response pointing to the URL 525 ending with the "/". For example, if a client performs an INDEX on 526 http://foo.bar/blah (no trailing slash), the resource 527 http://foo.bar/blah/ (trailing slash) MAY respond as if the 528 operation were invoked on it, and SHOULD return a location header 529 with http://foo.bar/blah/ in it. 531 4.2. Creation and Retrieval of Collection Resources 533 This document specifies the MKCOL method to create new collection 534 resources, rather than using the existing HTTP/1.1 PUT or POST 535 method, for the following reasons 537 In HTTP/1.1, the PUT method is defined to store the request body at 538 the location specified by the Request-URI. While a description 539 format for a collection can readily be constructed for use with PUT, 540 the implications of sending such a description to the server are 541 undesirable. For example, if a description of a collection that 542 omitted some existing resources were PUT to a server, this might be 543 interpreted as a command to remove those members. This would extend 544 PUT to perform DELETE functionality, which is undesirable since it 545 changes the semantics of PUT, and makes it difficult to control 546 DELETE functionality with an access control scheme based on methods. 548 While the POST method is sufficiently open-ended that a _create a 549 collection_ POST command could be constructed, this is undesirable 550 because it would be difficult to separate access control for 551 collection creation from other uses of POST. 553 This document specifies the INDEX method for listing the contents of 554 a collection, rather than relying on the existing HTTP/1.1 GET 555 method. This is to avoid conflict with the de-facto standard 556 practice of redirecting a GET request on a directory to its 557 index.html resource. 559 The exact definition of the behavior of GET and PUT on collections 560 is defined later in this document. 562 4.3. HTTP URL Namespace Model 564 The HTTP URL Namespace is a hierarchical namespace where the 565 hierarchy is delimited with the "/" character. DAV compliant 566 resources MUST maintain the consistency of the HTTP URL namespace. 567 Any attempt to create a resource (excepting the root member of a 568 namespace) that would not be the internal member of a collection 569 MUST fail. For example, if the collection http://www.foo.bar.org/a/ 570 exists, but http://www.foo.bar.org/a/b/does not exist, an attempt to 571 create http://www.foo.bar.org/a/b/c must fail. 573 4.4. Source Resources and Output Resources 575 For many resources, the entity returned by a GET method exactly 576 matches the persistent state of the resource, for example, a GIF 577 file stored on a disk. For this simple case, the URL at which a 578 resource is accessed is identical to the URL at which the source 579 (the persistent state) of the resource is accessed. This is also 580 the case for HTML source files that are not processed by the server 581 prior to transmission. 583 However, the server can sometimes process HTML resources before they 584 are transmitted as a return entity body. For example, server-side- 585 include directives within an HTML file instruct a server to replace 586 the directive with another value, such as the current date. In this 587 case, what is returned by GET (HTML plus date) differs from the 588 persistent state of the resource (HTML plus directive). Typically 589 there is no way to access the HTML resource containing the 590 unprocessed directive. 592 Sometimes the entity returned by GET is the output of a data- 593 producing process that is described by one or more source resources 594 (that may not even have a location in the URL namespace). A single 595 data-producing process may dynamically generate the state of a 596 potentially large number of output resources. An example of this is 597 a CGI script that describes a "finger" gateway process that maps 598 part of the namespace of a server into finger requests, such as 599 http://www.foo.bar.org/finger_gateway/user@host. 601 In the absence of distributed authoring capabilities, it is 602 acceptable to have no mapping of source resource(s) to the URI 603 namespace. In fact, preventing access to the source resource(s) has 604 desirable security benefits. However, if remote editing of the 605 source resource(s) is desired, the source resource(s) should be 606 given a location in the URI namespace. This source location should 607 not be one of the locations at which the generated output is 608 retrievable, since in general it is impossible for the server to 609 differentiate requests for source resources from requests for 610 process output resources. There is often a many-to-many 611 relationship between source resources and output resources. 613 On WebDAV compliant servers, for all output resources which have a 614 single source resource (and that source resource has a URI), the URI 615 of the source resource SHOULD be stored in a link on the output 616 resource with type http://www.ietf.org/standards/dav/source. Note 617 that by storing the source URIs in links on the output resources, 618 the burden of discovering the source is placed on the authoring 619 client. 621 5. Locking 623 The ability to lock a resource provides a mechanism for serializing 624 access to that resource. Using a lock, an authoring client can 625 provide a reasonable guarantee that another principal will not 626 modify a resource while it is being edited. In this way, a client 627 can prevent the "lost update" problem. 629 This specification allows locks to vary over two client-specified 630 parameters, the number of principals involved (exclusive vs. shared) 631 and the type of access to be granted. Furthermore, this document 632 only provides the definition of locking for one lock access type, 633 the write lock. However, the syntax is extensible, and permits the 634 eventual specification of other access types. 636 5.1. Exclusive Vs. Shared Locks 638 The most basic form of lock is an exclusive lock. This is a lock 639 where the access right in question is only granted to a single 640 principal. The need for this arbitration results from a desire to 641 avoid having to constantly merge results. 643 However, there are times when the goal of a lock is not to exclude 644 others from exercising an access right but rather to provide a 645 mechanism for principals to indicate that they intend to exercise 646 their access right. Shared locks are provided for this case. A 647 shared lock allows multiple principals to receive a lock. Hence any 648 principal with appropriate access can get the lock. 650 With shared locks there are two trust sets that affect a resource. 651 The first trust set is created by access permissions. Principals 652 who are trusted, for example, may have permission to write the 653 resource. Those who are not, don't. Among those who have access 654 permission to write the resource, the set of principals who have 655 taken out a shared lock also must trust each other, creating a 656 (typically) smaller trust set within the access permission write 657 set. 659 Starting with every possible principal on the Internet, in most 660 situations the vast majority of these principals will not have write 661 access to a given resource. Of the small number who do have write 662 access, some principals may decide to guarantee their edits are free 663 from overwrite conflicts by using exclusive write locks. Others may 664 decide they trust their collaborators will not overwrite their work 665 (the potential set of collaborators being the set of principals who 666 have write permission) and use a shared lock, which informs their 667 collaborators that a principal is potentially working on the 668 resource. 670 The WebDAV extensions to HTTP do not need to provide all of the 671 communications paths necessary for principals to coordinate their 672 activities. When using shared locks, principals may use any out of 673 band communication channel to coordinate their work (e.g., face-to- 674 face interaction, written notes, post-it notes on the screen, 675 telephone conversation, Email, etc.) The intent of a shared lock is 676 to let collaborators know who else is potentially working on a 677 resource. 679 Shared locks are included because experience from web distributed 680 authoring systems has indicated that exclusive write locks are often 681 too rigid. An exclusive write lock is used to enforce a particular 682 editing process: take out exclusive write lock, read the resource, 683 perform edits, write the resource, release the lock. This editing 684 process has the problem that locks are not always properly released, 685 for example when a program crashes, or when a lock owner leaves 686 without unlocking a resource. While both timeouts and 687 administrative action can be used to remove an offending lock, 688 neither mechanism may be available when needed; the timeout may be 689 long or the administrator may not be available. 691 Despite their potential problems, exclusive write locks are 692 extremely useful, since often a guarantee of freedom from overwrite 693 conflicts is what is needed. This specification provides both 694 exclusive write locks and the less strict mechanism of shared locks. 696 5.2. Required Support 698 A WebDAV compliant server is not required to support locking in any 699 form. If the server does support locking it MAY choose to support 700 any combination of exclusive and shared locks for any access types. 702 The reason for this flexibility is that locking policy strikes to 703 the very heart of the resource management and versioning systems 704 employed by various storage repositories. These repositories 705 require control over what sort of locking will be made available. 706 For example, some repositories only support shared write locks while 707 others only provide support for exclusive write locks while yet 708 others use no locking at all. As each system is sufficiently 709 different to merit exclusion of certain locking features, this 710 specification leaves locking as the sole axis of negotiation within 711 WebDAV. 713 5.3. Lock Tokens 715 A lock token is a URI that identifies a particular lock. A lock 716 token is returned by every successful LOCK operation in the lock- 717 token response header, and can also be discovered through lock 718 discovery on a resource. 720 Lock token URIs are required to be unique across all resources for 721 all time. This uniqueness constraint allows lock tokens to be 722 submitted across resources and servers without fear of confusion. 724 This specification provides a lock token URI scheme called 725 opaquelocktoken that meets the uniqueness requirements. However 726 resources are free to return any URI scheme so long as it meets the 727 uniqueness requirements. 729 5.4. opaquelocktoken Lock Token URI Scheme 731 The opaquelocktoken URI scheme is designed to be unique across all 732 resources for all time. Due to this uniqueness quality, a client 733 MAY submit an opaque lock token in a Lock-Token request header and 734 an if-state[-not]-match header on a resource other than the one that 735 returned it. 737 All resources MUST recognize the opaquelocktoken scheme and, at 738 minimum, recognize that the lock token was not generated by the 739 resource. Note, however, that resources are not required to 740 generate opaquelocktokens in LOCK method responses. 742 In order to guarantee uniqueness across all resources for all time 743 the opaquelocktoken requires the use of the GUID mechanism. 745 Opaquelocktoken generators, however, have a choice of how they 746 create these tokens. They can either generate a new GUID for every 747 lock token they create, which is potentially very expensive, or they 748 can create a single GUID and then add extension characters. If the 749 second method is selected then the program generating the extensions 750 MUST guarantee that the same extension will never be used twice with 751 the associated GUID. 753 Opaque-Lock-Token = "opaquelocktoken" ":" GUID [Extension] 754 GUID = ; As defined in [Leach, Salz, 1997] 755 Extension = *urlc ;urlc is defined in [Berners-Lee et al., 1997] 756 (draft-fielding-url-syntax-07.txt) 758 5.5. Lock Capability Discovery 760 Since server lock support is optional, a client trying to lock a 761 resource on a server can either try the lock and hope for the best, 762 or perform some form of discovery to determine what lock 763 capabilities the server supports. This is known as lock capability 764 discovery. Lock capability discovery differs from discovery of 765 supported access control types, since there may be access control 766 types without corresponding lock types. A client can determine what 767 lock types the server supports by retrieving the supportedlock 768 property. 770 Any DAV compliant resource that supports the LOCK method MUST 771 support the supportedlock property. 773 5.6. Active Lock Discovery 775 If another principal locks a resource that a principal wishes to 776 access, it is useful for the second principal to be able to find out 777 who the first principal is. For this purpose the lockdiscovery 778 property is provided. This property lists all outstanding locks, 779 describes their type, and provides their lock token. 781 Any DAV compliant resource that supports the LOCK method MUST 782 support the lockdiscovery property. 784 6. Write Lock 786 This section describes the semantics specific to the write access 787 type for locks. The write lock is a specific instance of a lock 788 type, and is the only lock type described in this specification. A 789 DAV compliant resource MAY support the write lock. 791 6.1. Methods Restricted by Write Locks 793 A write lock prevents a principal without the lock from successfully 794 executing a PUT, POST, PATCH, PROPPATCH, MOVE, DELETE, MKCOL, ADDREF 795 or DELREF on the locked resource. All other current methods, GET in 796 particular, function independent of the lock. 798 Note, however, that as new methods are created it will be necessary 799 to specify how they interact with a write lock. 801 6.2. Write Locks and Properties 803 While those without a write lock may not alter a property on a 804 resource it is still possible for the values of live properties to 805 change, even while locked, due to the requirements of their schemas. 806 Only dead properties and live properties defined to respect locks 807 are guaranteed not to change while write locked. 809 6.3. Write Locks and Null Resources 811 It is possible to assert a write lock on a null resource in order to 812 lock the name. Please note, however, that locking a null resource 813 effectively makes the resource non-null, as the resource now has 814 lock related properties defined on it. 816 6.4. Write Locks and Collections 818 A write lock on a collection prevents the addition or removal of 819 members of the collection. As a consequence, when a principal 820 issues a request to create a new internal member of a collection 821 using PUT or POST, or to remove an existing internal member of a 822 collection using DELETE, this request MUST fail if the principal 823 does not have a write lock on the collection. 825 However, if a write lock request is issued to a collection 826 containing internal member resources that are currently locked in a 827 manner which conflicts with the write lock, the request MUST fail 828 with a 409 Conflict status code. 830 6.5. Write Locks and COPY/MOVE 832 The owner of a write lock MUST NOT execute a MOVE method on a 833 resource he has locked. This specification intentionally does not 834 define what happens if a MOVE method request is made on a locked 835 resource by the lock's owner. 837 A COPY method invocation MUST NOT duplicate any write locks active 838 on the source. 840 6.6. Re-issuing Write Locks 842 If a principal already owns a write lock on a resource, any future 843 requests for the same type of write lock, on the same resource, 844 while the principal's previous write lock is in effect, MUST result 845 in a successful response with the same lock token as provided for 846 the currently existing lock. Two lock requests are defined to be 847 identical if their Lock-Info headers are identical. 849 6.7. Write Locks and The Lock-Token Request Header 851 If a user agent is not required to have knowledge about a lock when 852 requesting an operation on a locked resource, the following scenario 853 might occur. Program A, run by User A, takes out a write lock on a 854 resource. Program B, also run by User A, has no knowledge of the 855 lock taken out by Program A, yet performs a PUT to the locked 856 resource. In this scenario, the PUT succeeds because locks are 857 associated with a principal, not a program, and thus program B, 858 because it is acting with principal A's credential, is allowed to 859 perform the PUT. However, had program B known about the lock, it 860 would not have overwritten the resource, preferring instead to 861 present a dialog box describing the conflict to the user. Due to 862 this scenario, a mechanism is needed to prevent different programs 863 from accidentally ignoring locks taken out by other programs with 864 the same authorization. 866 In order to prevent these collisions the lock token request header 867 is introduced. Please refer to the Lock Token Request Header 868 section for details and requirements. 870 6.7.1. Write Lock Token Example 872 COPY /~fielding/index.html HTTP/1.1 873 Host: www.ics.uci.edu 874 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 875 Lock-Token: 876 878 HTTP/1.1 200 OK 880 In this example, both the source and destination are locked so two 881 lock tokens must be submitted. If only one of the two resources was 882 locked, then only one token would have to be submitted. 884 7. Notational Conventions 886 Since this document describes a set of extensions to the HTTP/1.1 887 protocol, the augmented BNF used herein to describe protocol 888 elements is exactly the same as described in Section 2.1 of RFC 889 2068, _Hypertext Transfer Protocol -- HTTP/1.1_ [Fielding et al., 890 1997]. Since this augmented BNF uses the basic production rules 891 provided in Section 2.2 of RFC 2068, these rules apply to this 892 document as well. 894 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 895 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 896 document are to be interpreted as described in RFC 2119 [Bradner, 897 1997]. 899 8. HTTP Methods for Distributed Authoring 901 8.1. PROPFIND 903 The PROPFIND method retrieves properties defined on the Request-URI, 904 if it is a non-collection resource, or on the Request-URI and 905 potentially its member resources, if the resource is a collection. 906 All DAV compliant resources MUST support the PROPFIND method. 908 A client MAY submit a Depth header with a PROPFIND on a collection 909 with a value of "0", "1" or "infinity". DAV compliant servers MUST 910 support the "0", "1" and "infinity" behaviors. By default, the 911 PROPFIND method on a collection without a Depth header MUST act as 912 if a Depth = infinity header was included. 914 A client MUST submit a Propfind request header describing what 915 information is being requested. It is possible to request 916 particular property values, all property values, or a list of the 917 names of the resource's properties. 919 The response is a text/xml message body that contains a multistatus 920 XML element that describes the results of the attempts to retrieve 921 the various properties. If a property was successfully retrieved 922 then its value MUST be returned in a prop XML element. If the scope 923 of PROPFIND covers more than a single resource, as is the case with 924 Depth values of "1" and "infinity", each response XML element MUST 925 contain an href XML element which identifies the resource on which 926 the properties in the prop XML element are defined. In the case of 927 allprop and propname, if a principal does not have the right to know 928 if a particular property exists, an error MUST NOT be returned. The 929 results of this method SHOULD NOT be cached. 931 8.1.1. Example: Retrieving Named Properties 933 PROPFIND /files/ HTTP/1.1 934 Host: www.foo.bar 935 Depth: 0 936 Propfind: 940 HTTP/1.1 207 Multi-Status 941 Content-Type: text/xml 942 Content-Length: xxxxx 944 945 946 947 948 949 950 951 Box type A 952 953 954 J.J. Dingleheimerschmidt 955 956 957 HTTP/1.1 200 OK 958 959 960 961 HTTP/1.1 403 Forbidden 962 The user does not have access to the 963 DingALing property. 964 965 966 There has been an access violation error. 967 968 970 In this example, PROPFIND is executed on the collection 971 http://www.foo.bar/files/. The specified depth is zero, hence the 972 PROPFIND applies only to the collection itself, and not to any of 973 its members. The Propfind header specifies the name of four 974 properties whose values are being requested. In this case only two 975 properties were returned, since the principal issuing the request 976 did not have sufficient access rights to see the third and fourth 977 properties. 979 8.1.2. Example: Using allprop to Retrieve All Properties 981 PROPFIND /container/ HTTP/1.1 982 Host: www.foo.bar 983 Depth: 1 984 Propfind: allprop 986 HTTP/1.1 200 OK 987 Content-Type: text/xml 988 Content-Length: xxxxx 990 991 992 993 994 995 http://www.foo.bar/container/ 996 997 998 Box type A 999 1000 1001 Hadrian 1002 1003 1004 HTTP 1.1 200 OK 1005 1006 1007 http://www.foo.bar/container/index.html 1008 1009 1010 Box type B 1011 1012 1013 HTTP 1.1 200 OK 1014 1015 1016 In this example, PROPFIND was invoked on the resource 1017 http://www.foo.bar/container/ with a Depth header of 1, meaning the 1018 request applies to the resource and its children, and a Propfind 1019 header of "allprop", meaning the request should return the name and 1020 value of all properties defined on each resource. 1022 The resource http://www.foo.bar/container/ has two properties 1023 defined on it, named http://www.foo.bar/boxschema/bigbox, and 1024 http://www.foo.bar/boxschema/author, while resource 1025 http://www.foo.bar/container/index.html has only a single resource 1026 defined on it, named http://www.foo.bar/boxschema/bigbox, another 1027 instance of the "bigbox" property type. 1029 8.1.3. Example: Using propname to Retrieve all Property Names 1031 PROPFIND /container/ HTTP/1.1 1032 Host: www.foo.bar 1033 Propfind: propname 1035 HTTP/1.1 200 OK 1036 Content-Type: text/xml 1037 Content-Length: xxxx 1039 1040 1041 1042 1043 1044 http://www.foo.bar/container/ 1045 1046 1047 1048 1049 HTTP 1.1 200 OK 1050 1051 1052 http://www.foo.bar/container/index.html 1053 1054 1055 1056 HTTP 1.1 200 OK 1057 1058 1060 In this example, PROPFIND is invoked on the collection resource 1061 http://www.foo.bar/container/, with a Propfind header set to 1062 "propname", meaning the name of all properties should be returned. 1063 Since no depth header is present, it assumes its default value of 1064 "infinity", meaning the name of the properties on the collection and 1065 all its progeny should be returned. 1067 Consistent with the previous example, resource 1068 http://www.foo.bar/container/ has two properties defined on it, 1069 http://www.foo.bar/boxschema/bigbox, and 1070 http://www.foo.bar/boxschema/author. The resource 1071 http://www.foo.bar/container/index.html, a member of the "container" 1072 collection, has only one property defined on it, 1073 http://www.foo.bar/boxschema/bigbox. 1075 8.2. PROPPATCH 1077 The PROPPATCH method processes instructions specified in the request 1078 body to set and/or remove properties defined on the resource 1079 identified by Request-URI. 1081 All DAV compliant resources MUST support the PROPPATCH method and 1082 MUST process instructions that are specified using the 1083 propertyupdate, set, and remove XML elements of the DAV schema. 1084 Execution of the directives in this method is, of course, subject to 1085 access control constraints. DAV compliant resources MUST support 1086 the setting of arbitrary dead properties. 1088 The request message body of a PROPPATCH method MUST contain at least 1089 one propertyupdate XML element. Instruction processing MUST occur 1090 in the order instructions are received (i.e., from top to bottom), 1091 and MUST be performed atomically. 1093 8.2.1. propertyupdate XML element 1095 Name: propertyupdate 1096 Namespace: http://www.ietf.org/standards/dav/ 1097 Purpose: To contain a request to alter the properties on a 1098 resource. 1099 Parent: None 1100 Values= 1*(set | remove) 1101 Description: This XML element is a container for the information 1102 required to modify the properties on the resource. This XML element 1103 is multi-valued. 1105 8.2.2. set XML element 1107 Name: set 1108 Namespace: http://www.ietf.org/standards/dav/ 1109 Purpose: To set the DAV properties specified inside the set XML 1110 element. 1111 Parent: propertyupdate 1112 Values= prop 1113 Description: This XML element MUST contain only a prop XML element. 1114 The elements contained by prop specify the name and value of 1115 properties that are set on the Request-URI. If a property already 1116 exists then its value is replaced. 1118 8.2.3. remove XML element 1120 Name: remove 1121 Namespace: http://www.ietf.org/standards/dav/ 1122 Purpose: To remove the DAV properties specified inside the remove 1123 XML element. 1124 Parent: propertyupdate 1125 Values= prop 1126 Description: Remove specifies that the properties specified in prop 1127 should be removed. Specifying the removal of a property that does 1128 not exist is not an error. All the elements in prop MUST be empty, 1129 as only the names of properties to be removed are required. 1131 8.2.4. Response Codes 1133 200 OK - The command succeeded. As there can be a mixture of sets 1134 and removes in a body, a 201 Create seems inappropriate. 1136 403 Forbidden - The client, for reasons the server chooses not to 1137 specify, cannot alter one of the properties. 1139 405 Conflict - The client has provided a value whose semantics are 1140 not appropriate for the property. This includes trying to set read- 1141 only properties. 1143 413 Request Entity Too Long - If a particular property is too long 1144 to be recorded then a composite XML error will be returned 1145 indicating the offending property. 1147 8.2.5. Example 1149 PROPPATCH /bar.html HTTP/1.1 1150 Host: www.foo.com 1151 Content-Type: text/xml 1152 Content-Length: xxxx 1154 1155 1156 1157 1158 1159 1160 1161 Jim Whitehead 1162 Roy Fielding 1163 1164 1165 1166 1167 1168 1169 1170 HTTP/1.1 207 Multi-Status 1171 Content-Type: text/xml 1172 Content-Length: xxxxx 1174 1175 1176 1177 1178 1179 1180 HTTP/1.1 420 Method Failure 1181 1182 1183 1184 HTTP/1.1 409 Conflict 1185 1186 Copyright Owner can not be deleted or 1187 altered. 1188 1190 In this example, the client requests the server to set the value of 1191 the http://www.w3.com/standards/z39.50/Authors property, and to 1192 remove the property http://www.w3.com/standards/z39.50/Copyright- 1193 Owner. Since the Copyright-Owner property could not be removed, no 1194 property modifications occur. The Method Failure response code for 1195 the Authors property indicates this action would have succeeded if 1196 it were not for the conflict with removing the Copyright-Owner 1197 property. 1199 8.3. MKCOL Method 1201 The MKCOL method is used to create a new collection. All DAV 1202 compliant resources MUST support the MKCOL method. 1204 8.3.1. Request 1206 MKCOL creates a new collection resource at the location specified by 1207 the Request-URI. If the Request-URI exists, then MKCOL must fail. 1208 During MKCOL processing, a server MUST make the Request-URI a member 1209 of its parent collection. If no such ancestor exists, the method 1210 MUST fail. When the MKCOL operation creates a new collection 1211 resource, all ancestors MUST already exist, or the method MUST fail 1212 with a 409 Conflict status code. For example, if a request to 1213 create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ 1214 exists, the request MUST fail. 1216 When MKCOL is invoked without a request body, the newly created 1217 collection has no members. 1219 A MKCOL request message MAY contain a message body. The behavior of 1220 a MKCOL request when the body is present is limited to creating 1221 collections, members of a collection, bodies of members and 1222 properties on the collections or members. If the server receives a 1223 MKCOL request entity type it does not support or understand it MUST 1224 respond with a 415 Unsupported Media Type status code. The exact 1225 behavior of MKCOL for various request media types is undefined in 1226 this document, and will be specified in separate documents. 1228 8.3.2. Response Codes 1230 Responses from a MKCOL request are not cacheable, since MKCOL has 1231 non-idempotent semantics. 1233 201 Created - The collection or structured resource was created in 1234 its entirety. 1236 403 Forbidden - This indicates at least one of two conditions: 1) 1237 The server does not allow the creation of collections at the given 1238 location in its namespace, and 2) The parent collection of the 1239 Request-URI exists but cannot accept members. 1241 405 Method Not Allowed - MKCOL can only be executed on a 1242 deleted/non-existent resource. 1244 409 Conflict - A collection cannot be made at the Request-URI until 1245 one or more intermediate collections have been created. 1247 415 Unsupported Media Type- The server does not support the request 1248 type of the body. 1250 419 Insufficient Space on Resource - The resource does not have 1251 sufficient space to record the state of the resource after the 1252 execution of this method. 1254 8.3.3. Example 1256 This example creates a collection called /webdisc/xfiles/ on the 1257 server www.server.org. 1259 MKCOL /webdisc/xfiles/ HTTP/1.1 1260 Host: www.server.org 1262 HTTP/1.1 201 Created 1264 8.4. INDEX Method 1266 The INDEX method is used to enumerate the members of a resource. 1267 All DAV compliant resources MUST support the INDEX method if they 1268 have members. 1270 8.4.1. The Request 1272 For a collection, INDEX MUST return a list of its members. All 1273 WebDAV compliant resources MUST support the text/xml response entity 1274 described below. The INDEX result for a collection MAY also return 1275 a list of the members of child collections, to any depth. 1277 Collections that respond to an INDEX method with a text/xml entity 1278 MUST contain a single multistatus XML element which contains a 1279 response XML element for each member. 1281 A resource that supports INDEX MUST return the resourcetype property 1282 for each member. 1284 Note that the prop XML element MAY contain additional properties. 1286 8.4.2. Example 1288 INDEX /user/yarong/dav_drafts/ HTTP/1.1 1289 Host: www.microsoft.com 1291 HTTP/1.1 200 OK 1292 Content-Type: text/xml 1293 Content-Length: xxx 1294 Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT 1295 ETag: _fooyyybar_ 1297 1298 1299 1300 1301 http://www.microsoft.com/user/yarong/dav_drafts/ 1302 1303 1304 1305 1306 1307 1308 HTTP 1.1 200 OK 1309 1310 1311 1312 http://www.microsoft.com/user/yarong/dav_drafts/base 1313 1314 1315 1316 1317 HTTP 1.1 200 OK 1318 1319 1320 8.5. ADDREF Method 1322 The ADDREF method is used to add external members to a resource. 1323 All DAV compliant collection resources MUST support the ADDREF 1324 method. All other DAV compliant resources MAY support the ADDREF 1325 method as appropriate. 1327 8.5.1. The Request 1329 The ADDREF method adds the URI specified in the Collection-Member 1330 header as an external member to the collection specified by the 1331 Request-URI. The value in the Collection-Member header MUST be an 1332 absolute URI meeting the requirements of an external member URI. 1334 It is not an error if the URI specified in the Collection-Member 1335 header already exists as an external member of the collection. 1336 However, after processing the ADDREF there MUST be only one instance 1337 of the URI in the collection. If the URI specified in the 1338 Collection-Member header already exists as an internal member of the 1339 collection, the ADDREF method MUST fail with a 412 Precondition 1340 Failed status code. 1342 8.5.2. Example 1344 ADDREF /~ejw/dav/ HTTP/1.1 1345 Host: www.ics.uci.edu 1346 Collection-Member: http://www.ietf.org/standards/dav/ 1348 HTTP/1.1 200 OK 1350 This example adds the URI http://www.ietf.org/standards/dav/ as an 1351 external member resource of the collection 1352 http://www.ics.uci.edu/~ejw/dav/. 1354 8.6. DELREF Method 1356 The DELREF method is used to remove external members from a 1357 resource. All DAV compliant collection resources MUST support the 1358 DELREF method. All other DAV compliant resources MUST support the 1359 DELREF method only if they support the ADDREF method. 1361 8.6.1. The Request 1363 The DELREF method removes the URI specified in the Collection-Member 1364 header from the collection specified by the Request-URI. 1366 DELREFing a URI which is not a member of the collection is not an 1367 error. DELREFing an internal member MUST fail with a 412 1368 Precondition Failed status code. 1370 8.6.2. Example 1372 DELREF /~ejw/dav/ HTTP/1.1 1373 Host: www.ics.udi.edu 1374 Collection-Member: http://www.ietf.org/standards/dav/ 1376 HTTP/1.1 200 OK 1378 This example removes the URI http://www.ietf.org/standards/dav/, an 1379 external member resource, from the collection 1380 http://www.ics.uci.edu/~ejw/dav/. 1382 8.7. GET, HEAD for Collections 1384 The semantics of GET are unchanged when applied to a collection, 1385 since GET is defined as, _retrieve whatever information (in the form 1386 of an entity) is identified by the Request-URI_ [Fielding et al., 1387 1997]. GET when applied to a collection MAY return the contents of 1388 an _index.html_ resource, a human-readable view of the contents of 1389 the collection, or something else altogether, and hence it is 1390 possible the result of a GET on a collection will bear no 1391 correlation to the state of the collection. 1393 Similarly, since the definition of HEAD is a GET without a response 1394 message body, the semantics of HEAD are unmodified when applied to 1395 collection resources. 1397 8.8. POST for Collections 1399 Since by definition the actual function performed by POST is 1400 determined by the server and often depends on the particular 1401 resource, the behavior of POST when applied to collections cannot be 1402 meaningfully modified because it is largely undefined. Thus the 1403 semantics of POST are unmodified when applied to a collection. 1405 8.9. DELETE 1407 8.9.1. DELETE Method for Non-Collection Resources 1409 If the DELETE method is issued to a non-collection resource which is 1410 an internal member of a collection, then during DELETE processing a 1411 server MUST remove the Request-URI from its parent collection. A 1412 server MAY remove the URI of a deleted resource from any collections 1413 of which the resource is an external member. 1415 8.9.2. DELETE for Collections 1416 The DELETE method on a collection MUST act as if a Depth = Infinity 1417 header was used on it. A client MUST NOT submit a Depth header on a 1418 DELETE on a collection with any value but Infinity. 1420 DELETE instructs that the collection specified in the request-URI, 1421 the records of its external member resources, and all its internal 1422 member resources, are to be deleted. 1424 If any member cannot be deleted then all of the member's progeny 1425 MUST NOT be deleted, so as to maintain the namespace. 1427 Any headers included with DELETE MUST be applied in processing every 1428 resource to be deleted. In this case, a header of special interest 1429 is the Destroy header, which specifies the method to be used to 1430 delete all resources in the scope of the DELETE. 1432 When the DELETE method has completed processing it MUST return a 1433 consistent namespace. 1435 The response SHOULD be a Multi-Status response that describes the 1436 result of the DELETE on each affected resource. 1438 8.9.2.1. Example 1440 DELETE /container/ HTTP/1.1 1441 Host: www.foo.bar 1442 Destroy: NoUndelete 1444 HTTP/1.1 207 Multi-Status 1445 Content-Type: text/xml 1446 Content-Length: xxxxx 1448 1449 1450 1451 1452 http://www.foo.bar/container/resource1 1453 http://www.foo.bar/container/resource2 1454 HTTP/1.1 200 OK 1455 1456 1457 http://www.foo.bar/container/ 1458 HTTP/1.1 420 Method Failure 1459 1460 1461 http://www.foo.bar/container/resource3 1462 HTTP/1.1 412 Precondition Failed 1463 1464 1465 In this example the attempt to delete 1466 http://www.foo.bar/container/resource3 failed because the server was 1467 unable to guarantee that resource3 would not be able to be 1468 undeleted. Consequently, the attempt to delete 1469 http://www.foo.bar/container/ also failed, but resource1 and 1470 resource2 were deleted. Even though a Depth header has not been 1471 included, a depth of infinity is assumed because the method is on a 1472 collection. As this example illustrates, DELETE processing need not 1473 be atomic. 1475 8.10. PUT 1477 8.10.1. PUT for Non-Collection Resources 1479 A PUT performed on an existing resource replaces the GET response 1480 entity of the resource. Properties defined on the resource MAY be 1481 recomputed during PUT processing. For example, if a server 1482 recognizes the content type of the request body, it may be able to 1483 automatically extract information that could be profitably exposed 1484 as properties. 1486 A PUT that would result in the creation of a resource without an 1487 appropriately scoped parent collection MUST fail with a 405 Method 1488 Not Allowed. 1490 8.10.2. PUT for Collections 1492 As defined in the HTTP/1.1 specification [Fielding et al., 1997], 1493 the "PUT method requests that the enclosed entity be stored under 1494 the supplied Request-URI." Since submission of an entity 1495 representing a collection would implicitly encode creation and 1496 deletion of resources, this specification intentionally does not 1497 define a transmission format for creating a collection using PUT. 1498 Instead, the MKCOL method is defined to create collections. If a 1499 PUT is invoked on a collection resource it MUST fail. 1501 When the PUT operation creates a new non-collection resource all 1502 ancestors MUST already exist. If all ancestors do not exist, the 1503 method MUST fail with a 409 Conflict status code. For example, if 1504 resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, 1505 then the request must fail. 1507 8.11. COPY Method 1509 The COPY method creates a duplicate of the specified resource. All 1510 DAV compliant resources MUST support the COPY method. 1512 Support for the COPY method does not guarantee the ability to copy a 1513 resource. For example, separate programs may control resources on 1514 the same server. As a result, it may not even be possible to copy a 1515 resource to a location that appears to be on the same server. 1517 8.11.1. The Request 1519 The COPY method creates a duplicate of the source resource, given by 1520 the Request-URI, in the destination resource, given by the 1521 Destination header. The Destination header MUST be present. The 1522 exact behavior of the COPY method depends on the type of the source 1523 resource. 1525 8.11.1.1. COPY for HTTP/1.1 resources 1527 When the source resource is not a collection the body of the 1528 destination resource MUST be octet-for-octet identical to the body 1529 of the source resource. Alterations to the destination resource do 1530 not modify the source resource. Alterations to the source resource 1531 do not modify the destination resource. Thus, all copies are 1532 performed _by-value_. 1534 All properties on the source resource MUST be duplicated on the 1535 destination resource, subject to modifying headers, following the 1536 definition for copying properties. 1538 8.11.1.2. COPY for Properties 1540 The following section defines how properties on a resource are 1541 handled during a COPY operation. 1543 Live properties SHOULD be duplicated as identically behaving live 1544 properties at the destination resource. Since they are live 1545 properties, the server determines the syntax and semantics of these 1546 properties. Properties named by the Enforce-Live-Properties header 1547 MUST be live on the destination resource, or the method MUST fail. 1548 If a property is not named by Enforce-Live-Properties and cannot be 1549 copied live, then its value MUST be duplicated, octet-for-octet, in 1550 an identically named, dead property on the destination resource. 1552 If a property on the source already exists on the destination 1553 resource and the Overwrite header is set to "T" then the property at 1554 the destination MUST be overwritten with the property from the 1555 source. If the Overwrite header is "F" and the previous situation 1556 exists, then the COPY MUST fail with a 409 Conflict. 1558 8.11.1.3. COPY for Collections 1560 The COPY method on a collection without a Depth header MUST act as 1561 if a Depth = infinity header was included. A client MAY submit a 1562 Depth header on a COPY on a collection with a value of "0" or 1563 "infinity". DAV compliant servers MUST support the "0" and 1564 "infinity" behaviors. 1566 A COPY of depth infinity instructs that the collection specified in 1567 the Request-URI, the records of its external member resources, and 1568 all its internal member resources, are to be copied to a location 1569 relative to the Destination header. 1571 A COPY of depth "0" only instructs that the collection, the 1572 properties, and its external members, not its internal members, are 1573 to be copied. 1575 Any headers included with a COPY are to be applied in processing 1576 every resource to be copied. 1578 The exception to this rule is the Destination header. This header 1579 only specifies the destination for the Request-URI. When applied to 1580 members of the collection specified in the request-URI the value of 1581 Destination is to be modified to reflect the current location in the 1582 hierarchy. So, if the request-URI is "a" and the destination is "b" 1583 then when a/c/d is processed it MUST use a destination of b/c/d. 1585 When the COPY method has completed processing it MUST have created a 1586 consistent namespace at the destination. Thus if it is not possible 1587 to COPY a collection with internal members, the internal members may 1588 still be copied but a collection will have to be created at the 1589 destination to contain them. 1591 The response is a Multi-Status response that describes the result of 1592 the COPY on each affected resource. The response is given for the 1593 resource that was to be copied, not the resource that was created as 1594 a result of the copy. In other words, each entry indicates whether 1595 the copy on the resource specified in the href succeeded or failed 1596 and why. 1598 The exception to this rule is for errors that occurred on the 1599 destination. For example, if the destination was locked the 1600 response would indicate the destination URL and a 421 Destination 1601 Locked error. 1603 8.11.1.4. Type Interactions 1605 If the destination resource identifies a collection and the 1606 Overwrite header is _T_, prior to performing the copy the server 1607 MUST perform a DELETE operation on the collection. 1609 8.11.2. Response Codes 1611 200 OK - The source resource was successfully copied to a pre- 1612 existing destination resource. 1614 201 Created - The source resource was successfully copied. The copy 1615 operation resulted in the creation of a new resource. 1617 412 Precondition Failed - This status code MUST be returned if the 1618 server was unable to maintain the liveness of the properties listed 1619 in the Enforce-Live-Properties header, or if the Overwrite header is 1620 "F", and the state of the destination resource is non-null. 1622 419 Insufficient Space on Resource - The destination resource does 1623 not have sufficient space to record the state of the resource after 1624 the execution of this method. 1626 421 Destination Locked _ The destination resource was locked and 1627 either a valid Lock-Token header was not submitted, or the Lock- 1628 Token header identifies a lock held by another principal. 1630 500 Server Error - The resource was in such a state that it could 1631 not be copied. This may occur if the Destination header specifies a 1632 resource that is outside the namespace the resource is able to 1633 interact with. 1635 8.11.3. Overwrite Example 1637 This example shows resource 1638 http://www.ics.uci.edu/~fielding/index.html being copied to the 1639 location http://www.ics.uci.edu/users/f/fielding/index.html. The 1640 contents of the destination resource were overwritten, if non-null. 1642 COPY /~fielding/index.html HTTP/1.1 1643 Host: www.ics.uci.edu 1644 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1646 HTTP/1.1 200 OK 1648 8.11.4. No Overwrite Example 1650 The following example shows the same copy operation being performed, 1651 except with the Overwrite header set to _F._ A response of 412 1652 Precondition Failed is returned because the destination resource has 1653 a non-null state. 1655 COPY /~fielding/index.html HTTP/1.1 1656 Host: www.ics.uci.edu 1657 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1658 Overwrite: _F_ 1660 HTTP/1.1 412 Precondition Failed 1662 8.11.5. Collection Example 1664 COPY /container/ HTTP/1.1 1665 Host: www.foo.bar 1666 Destination: http://www.foo.bar/othercontainer/ 1667 Enforce-Live-Properties: * 1668 Depth: Infinity 1669 HTTP/1.1 207 Multi-Status 1670 Content-Type: text/xml 1671 Content-Length: xxxxx 1673 1674 1675 1676 1677 http://www.foo.bar/othercontainer/resource1 1678 http://www.foo.bar/othercontainer/resource2 1679 http://www.foo.bar/othercontainer/ 1680 http://www.foo.bar/othercontainer/R2/D2 1681 HTTP/1.1 201 Created 1682 1683 1684 http://www.foo.bar/othercontainer/R2/ 1685 HTTP/1.1 412 Precondition Failed 1686 1687 1689 The Depth header is unnecessary as the default behavior of COPY on a 1690 collection is to act as if a "Depth: Infinity" header had been 1691 submitted. In this example most of the resources, along with the 1692 collection, were copied successfully. However the collection R2 1693 failed, most likely due to a problem with enforcing live properties. 1694 R2's member D2 was successfully copied. As a result a collection 1695 was created at www.foo.bar/othercontainer/R2 to contain D2. 1697 8.12. MOVE Method 1699 The move operation on a resource is the logical equivalent of a copy 1700 followed by a delete, where the actions are performed atomically. 1701 All DAV compliant resources MUST support the MOVE method. 1703 However, support for the MOVE method does not guarantee the ability 1704 to move a resource to a particular destination. For example, 1705 separate programs may actually control different sets of resources 1706 on the same server. Therefore, it may not even be possible to move 1707 a resource within a namespace that appears to belong to the same 1708 server. 1710 8.12.1. The Request 1712 If a resource exists at the destination, the destination resource 1713 will be DELETEd as a side effect of the MOVE operation, subject to 1714 the restrictions of the Overwrite header. 1716 8.12.2. MOVE for Collections 1718 MOVE instructs that the collection specified in the Request-URI, the 1719 records of its external member resources, and all its internal 1720 member resources, are to be moved to a location relative to the 1721 Destination header. 1723 The MOVE method on a collection MUST act as if a Depth "infinity" 1724 header was used on it. A client MUST NOT submit a Depth header on a 1725 MOVE on a collection with any value but "infinity". 1727 Any headers included with MOVE are to be applied in processing every 1728 resource to be moved. 1730 The exception to this rule is the Destination header. The behavior 1731 of this header is the same as given for COPY on collections. 1733 When the MOVE method has completed processing it MUST have created a 1734 consistent namespace on both the source and destination, creating 1735 collections at the source or destination as necessary. 1737 As specified in the definition of MOVE, a MOVE of a collection over 1738 another collection causes the destination collection and all its 1739 members to be deleted. 1741 The response is a Multi-Status response that describes the result of 1742 the MOVE on each effected resource. The response is given for the 1743 resource that was to be moved, not the resource that was created as 1744 a result of the move. In other words, each entry indicates whether 1745 the move on the resource specified in the href succeeded or failed 1746 and why. 1748 The exception to this rule is for errors that occurred on the 1749 destination. For example, if the destination was locked the 1750 response would indicate the destination URL and a 421 Destination 1751 Locked error. 1753 8.12.3. Response Codes 1755 200 OK - The move operation was successful. 1757 409 Conflict _ The MOVE was attempted on a collection with members. 1758 While the COPY part of this operation could succeed the DELETE could 1759 not. Therefore the MOVE MUST fail. 1761 412 Precondition Failed - This status code MUST be returned if the 1762 server was unable to maintain the liveness of the properties listed 1763 in the Enforce-Live-Properties header, or if the Overwrite header is 1764 "F", and the state of the destination resource is non-null. 1766 421 Destination Locked - The destination resource was locked and 1767 either a valid Lock-Token header was not submitted, or the Lock- 1768 Token header identifies a lock held by another principal. 1770 502 Bad Gateway - This may occur when the destination is 1772 o 1773 n another 1774 server and the destination server refuses to accept the resource 1775 8.12.4. Overwrite Example 1777 This example shows resource 1778 http://www.ics.uci.edu/~fielding/index.html being moved to the 1779 location http://www.ics.uci.edu/users/f/fielding/index.html. The 1780 contents of the destination resource were overwritten, if non-null. 1782 MOVE /~fielding/index.html HTTP/1.1 1783 Host: www.ics.uci.edu 1784 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1786 HTTP/1.1 200 OK 1788 8.12.5. Collection Example 1790 MOVE /container/ HTTP/1.1 1791 Host: www.foo.bar 1792 Destination: http://www.foo.bar/othercontainer/ 1793 Enforce-Live-Properties: * 1794 Overwrite: False 1795 Lock-Token: 1797 HTTP/1.1 207 Multi-Status 1798 Content-Type: text/xml 1799 Content-Length: xxxxx 1801 1802 1803 1804 1805 http://www.foo.bar/container/resource1 1806 http://www.foo.bar/container/resource2 1807 http://www.foo.bar/container/ 1808 http://www.foo.bar/container/C2/R2 1809 HTTP/1.1 201 Created 1810 1811 1812 http://www.foo.bar/container/C2 1813 HTTP/1.1 420 Method Failure 1814 1815 http://www.foo.bar/othercontainer/C2 1816 HTTP/1.1 409 Conflict 1817 1818 1820 In this example the client has submitted a number of lock tokens 1821 with the request. A lock token will need to be submitted for every 1822 resource, both source and destination, anywhere in the scope of the 1823 method, that is locked. In this case the proper lock token was not 1824 submitted for the destination http://www.foo.bar/othercontainer/C2. 1825 This means that the resource continer/c2 could not be moved, 1826 although its child container/C2/R2 could be moved. 1828 8.13. LOCK Method 1830 The following sections describe the LOCK method, which is used to 1831 take out a lock of any access type. These sections on the LOCK 1832 method describe only those semantics that are specific to the LOCK 1833 method and are independent of the access type of the lock being 1834 requested. Once the general LOCK method has been described, 1835 subsequent sections describe the semantics of the "write" access 1836 type, and the write lock. 1838 8.13.1. Operation 1840 A LOCK method invocation creates the lock specified by the Lock-Info 1841 header on the Request-URI. Lock method requests SHOULD have a XML 1842 request body which contains an Owner XML element for this lock 1843 request. The LOCK request MAY have a Timeout header. 1845 A successful response to a lock invocation MUST include Lock-Token 1846 and Timeout headers. Clients MUST assume that locks may arbitrarily 1847 disappear at any time, regardless of the value given in the Timeout 1848 header. The Timeout header only indicates the behavior of the 1849 server if "extraordinary" circumstances do not occur. For example, 1850 an administrator may remove a lock at any time or the system may 1851 crash in such a way that it loses the record of the lock's 1852 existence. The response MUST also contain the value of the 1853 lockdiscovery property in a prop XML element. 1855 8.13.2. The Effect of Locks on Properties and Collections 1857 By default the scope of a lock is the entire state of the resource, 1858 including its body and associated properties. As a result, a lock 1859 on a resource also locks the resource's properties, and a lock on a 1860 property may lock a property's resource or may restrict the ability 1861 to lock the property's resource. Only a single lock token MUST be 1862 used when a lock extends to cover both a resource and its 1863 properties. Note that certain lock types MAY override this 1864 behavior. 1866 For collections, a lock also affects the ability to add or remove 1867 members. The nature of the effect depends upon the type of access 1868 control involved. 1870 8.13.3. Locking Replicated Resources 1872 Some servers automatically replicate resources across multiple URLs. 1873 In such a circumstance the server MAY only accept a lock on one of 1874 the URLs if the server can guarantee that the lock will be honored 1875 across all the URLs. 1877 8.13.4. Locking Multiple Resources 1879 The LOCK method supports locking multiple resources simultaneously 1880 by allowing for the listing of several URIs in the LOCK request. 1881 These URIs, in addition to the Request-URI, are then to be locked as 1882 a result of the LOCK method's invocation. When multiple resources 1883 are specified the LOCK method only succeeds if all specified 1884 resources are successfully locked. 1886 The Lock-Tree option of the lock request specifies that the resource 1887 and all its internal children (including internal collections, and 1888 their internal members) are to be locked. This is another mechanism 1889 by which a request for a lock on multiple resources can be 1890 specified. 1892 Currently existing locks can not be extended to cover more or less 1893 resources, and any request to expand or contract the number of 1894 resources in a lock MUST fail with a 409 Conflict status code. So, 1895 for example, if resource A is exclusively write locked and then the 1896 same principal asks to exclusively write lock resources A, B, and C, 1897 the request will fail as A is already locked and the lock can not be 1898 extended. 1900 A successful result will return a single lock token which represents 1901 all the resources that have been locked. If an UNLOCK is executed 1902 on this token, all associated resources are unlocked. 1904 If the lock cannot be granted to all resources, a 409 Conflict 1905 status code MUST be returned with a response entity body containing 1906 a multistatus XML element describing which resource(s) prevented the 1907 lock from being granted. 1909 8.13.5. Interaction with other Methods 1911 The interaction of a LOCK with various methods is dependent upon the 1912 lock type. However, independent of lock type, a successful DELETE 1913 of a resource MUST cause all of its locks to be removed. 1915 8.13.6. Lock Compatibility Table 1917 The table below describes the behavior that occurs when a lock 1918 request is made on a resource. 1920 Current lock state/ Shared Lock Exclusive 1921 Lock request Lock 1922 None True True 1923 Shared Lock True False 1924 Exclusive Lock False False* 1925 Legend: True = lock MAY be granted. False = lock MUST NOT be 1926 granted. *=if the principal requesting the lock is the owner of the 1927 lock, the lock MAY be regranted. 1929 The current lock state of a resource is given in the leftmost 1930 column, and lock requests are listed in the first row. The 1931 intersection of a row and column gives the result of a lock request. 1932 For example, if a shared lock is held on a resource, and an 1933 exclusive lock is requested, the table entry is _false_, indicating 1934 the lock must not be granted. 1936 If an exclusive or shared lock is re-requested by the principal who 1937 owns the lock, the lock MUST be regranted. If the lock is 1938 regranted, the same lock token that was previously issued MUST be 1939 returned. 1941 8.13.7. Owner XML Element 1943 Name: owner 1944 Namespace: http://www.ietf.org/standards/dav/ 1945 Purpose: Provide information about the principal taking out a 1946 lock. 1947 Parent: Any 1948 Values: XML Elements 1949 Descripton: The Owner XML element provides information sufficient 1950 for either directly contacting a principal (such as a telephone 1951 number or Email URI), or for discovering the principal (such as the 1952 URL of a homepage) who owns a lock. 1954 8.13.8. Lock Response 1956 A successful lock response MUST contain a Lock-Token response 1957 header, a Timeout header and a prop XML element in the response body 1958 which contains the value of the lockdiscovery property. 1960 8.13.9. Response Codes 1962 409 Conflict - The resource is locked, so the method has been 1963 rejected. 1965 412 Precondition Failed - The included Lock-Token was not 1966 enforceable on this resource or the server could not satisfy the 1967 request in the Lock-Info header. 1969 8.13.10. Example - Simple Lock Request 1971 LOCK /workspace/webdav/proposal.doc HTTP/1.1 1972 Host: webdav.sb.aol.com 1973 Lock-Info: LockType=Write LockScope=Exclusive 1974 Timeout: Infinite; Second-4100000000 1975 Content-Type: text/xml 1976 Content-Length: xyz 1978 1979 1980 1981 http://www.ics.uci.edu/~ejw/contact.html 1982 1984 HTTP/1.1 200 OK 1985 Lock-Token: opaquelocktoken:xyz122393481230912asdfa09s8df09s7df 1986 Timeout: Second-604800 1987 Content-Type: text/xml 1988 Content-Length: xxxxx 1990 1991 1992 1993 1994 1995 write 1996 exclusive 1997 1998 1999 2000 http://www.ics.uci.edu/~ejw/contact.html 2001 2002 2003 Second-604800 2004 2005 2006 opaquelocktoken:xyz122393481230912asdfa09s8df09s7df 2007 2008 2009 2010 2011 2013 This example shows the successful creation of an exclusive write 2014 lock on resource 2015 http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The 2016 resource http://www.ics.uci.edu/~ejw/contact.html contains contact 2017 information for the owner of the lock. The server has an activity- 2019 based timeout policy in place on this resource, which causes the 2020 lock to automatically be removed after 1 week (604800 seconds). The 2021 response has a Lock-Token header that gives the lock token URL that 2022 uniquely identifies the lock created by this lock request. 2024 8.13.11. Example - Multi-Resource Lock Request 2026 LOCK /workspace/webdav/proposal.doc HTTP/1.1 2027 Host: webdav.sb.aol.com 2028 Lock-Info: LockType=Write LockScope=Exclusive 2029 Addlocks= 2030 Timeout: Infinite, Second-4100000000 2032 2033 2034 http://www.ics.uci.edu/~ejw/contact.html 2036 HTTP/1.1 409 Conflict 2037 Content-Type: text/xml 2038 Content-Length: xxxxx 2040 2041 2042 2043 2044 2045 http://webdav.sb.aol.com/workspace/webdav/proposal.doc 2046 2047 2048 http://webdav.sb.aol.com/workspace/webdav/ 2049 2050 HTTP/1.1 202 Accepted 2051 2052 2053 http://foo.bar/blah 2054 HTTP/1.1 403 Forbidden 2055 2056 2058 This example shows a request for an exclusive write lock on three 2059 resources, http://webdav.sb.aol.com/workspace/webdav/proposal.doc, 2060 http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah. In 2061 this request, the client has specified that it desires an infinite 2062 length lock, if available, otherwise a timeout of 4.1 billion 2063 seconds, if available. The Owner header field specifies the web 2064 address for contact information for the principal taking out the 2065 lock. 2067 This lock request has failed, because the server rejected the lock 2068 request for http://foo.bar/blah. The 409 Conflict status code 2069 indicates that the server was unable to satisfy the request because 2070 there is a conflict between the state of the resources and the 2071 operation named in the request. Within the multistatus, the 202 2072 Accepted status code indicates that the lock method was accepted by 2073 the resources, and would have been completed if all resources named 2074 in the request were able to be locked. The 403 Forbidden status 2075 code indicates that the server does not allow lock requests on this 2076 resource. 2078 8.14. UNLOCK Method 2079 The UNLOCK method removes the lock identified by the lock token in 2080 the Lock-Token header from the Request-URI, and all other resources 2081 included in the lock. 2083 Any DAV compliant resource which supports the LOCK method MUST 2084 support the UNLOCK method. 2086 8.14.1. Example 2088 UNLOCK /workspace/webdav/info.doc HTTP/1.1 2089 Host: webdav.sb.aol.com 2090 Lock-Token:opaquelocktoken:123AbcEfg1284h23h2 2092 HTTP/1.1 200 OK 2094 In this example, the lock identified by the lock token 2095 "opaquelocktoken:123AbcEfg1284h23h2" is successfully removed from 2096 the resource http://webdav.sb.aol.com/workspace/webdav/info.doc. If 2097 this lock included more than just one resource, the lock was removed 2098 from those resources as well. 2100 8.15. PATCH Method 2102 The PATCH method is used to modify parts of the entity returned in 2103 the response to a GET method. DAV compliant resources MAY support 2104 the PATCH method. 2106 8.15.1. The Request 2108 The request entity of the PATCH method contains a list of 2109 differences between the resource identified by the Request-URI and 2110 the desired content of the resource after the PATCH action has been 2111 applied. The list of differences is in a format defined by the 2112 media type of the entity (e.g., "application/diff") and must include 2113 sufficient information to allow the server to convert the original 2114 version of the resource to the desired version. Processing 2115 performed by PATCH is atomic. Hence all changes MUST be 2116 successfully executed or the method fails. PATCH MUST fail if 2117 executed on a non-existent resource; i.e., PATCH does not create a 2118 resource as a side effect. 2120 If the request appears (at least initially) to be acceptable, the 2121 server MUST transmit an interim 100 response message after receiving 2122 the empty line terminating the request headers and continue 2123 processing the request. Since the semantics of PATCH are non- 2124 idempotent, responses to this method are not cacheable. 2126 While server support for PATCH is optional, if a server does support 2127 PATCH, it MUST support at least the text/xml diff format defined 2128 below. Support for the VTML difference format [VTML] is 2129 recommended, but not required. 2131 8.15.2. text/xml elements for PATCH 2133 The resourceupdate XML element contains a set of XML sub-entities 2134 that describe modification operations. The name and meaning of 2135 these XML elements are given below. Processing of these directives 2136 MUST be performed in the order encountered within the XML document. 2137 A directive operates on the resource as modified by all previous 2138 directives (executed in sequential order). The length of the 2139 resource MAY be extended or reduced by a PATCH. 2141 The changes specified by the resourceupdate XML element MUST be 2142 executed atomically. 2144 8.15.2.1. resourceupdate XML Element 2146 Name: resourceupdate 2147 Namespace: http://www.ietf.org/standards/dav/patch/ 2148 Purpose: Contains an ordered set of changes to a non-collection, 2149 non-property resource. 2150 Parent: None 2151 Value= *(insert | delete | replace) 2153 8.15.2.2. insert XML Element 2155 Name: insert 2156 Namespace: http://www.ietf.org/standards/dav/patch/ 2157 Purpose: Insert the XML element's contents starting at the 2158 specified octet. 2159 Parent: resourceupdate 2160 Value: The insert XML element MUST contain an octet-range XML 2161 attribute that specifies an octet position within the body of a 2162 resource. A value of _end_ specifies the end of the resource. The 2163 body of the insert XML element contains the octets to be inserted. 2165 Please note that in order to protect the white space contained in 2166 this XML element the following attribute/value MUST be included in 2167 the element: XML-SPACE = "PRESERVE". This attribute is defined in 2168 the XML specification [Bray, Sperberg-McQueen, 1997]. 2170 8.15.2.3. delete XML Element 2172 Name: delete 2173 Namespace: http://www.ietf.org/standards/dav/patch/ 2174 Purpose: Removes the specified range of octets. 2175 Parent: resourceupdate 2176 Value: The delete XML element MUST contain an octet-range XML 2177 attribute. 2179 Discussion: The octets that are deleted are removed, which means the 2180 resource is collapsed and the length of the resource is decremented 2181 by the size of the octet range. It is not appropriate to replace 2182 deleted octets with zeroed-out octets, since zero is a valid octet 2183 value. 2185 8.15.2.4. replace XML Element 2187 Name: replace 2188 Namespace: http://www.ietf.org/standards/dav/patch/ 2189 Purpose: Replaces the specified range of octets with the contents 2190 of the XML element. If the number of octets in the XML element is 2191 different from the number of octets specified, the update MUST be 2192 rejected. 2193 Parent: resourceupdate 2194 Value: The replace XML element MUST contain an octet-range XML 2195 attribute. The contents of the entity are the replacement octets. 2197 Please note that in order to protect the white space contained in 2198 this XML element the following attribute/value MUST be included in 2199 the element: XML-SPACE = "PRESERVE" 2200 . 2202 This attribute is defined in the 2203 XML specification [Bray, Sperberg-McQueen, 1997]. 2205 8.15.2.5. octet-range Attribute 2207 Name: octet-range 2208 Namespace: http://www.ietf.org/standards/dav/patch/ 2209 Purpose: Specifies a range of octets that the enclosing property 2210 affects. 2211 Parent: insert | delete | replace 2212 Value: number [_-_ (number | _end_)] 2213 Number = 1*Digit 2215 Description: Octet numbering begins with 0. If the octet contains a 2216 single number then the operation is to begin at that octet and to 2217 continue for a length specified by the operation. In the case of a 2218 delete, this would mean to delete a single octet. In the case of an 2219 insert this would mean to begin the insertion at the specified octet 2220 and to continue for the length of the included value, extending the 2221 resource if necessary. In the case of replace, the replace begins 2222 at the specified octet and overwrites all that follow to the length 2223 of the included value. 2225 8.15.3. Response Codes 2227 200 OK - The request entity body was processed without error, 2228 resulting in an update to the state of the resource. 2230 409 Conflict - If the update information in the request message body 2231 does not make sense given the current state of the resource (e.g., 2232 an instruction to delete a non-existent line), this status code MAY 2233 be returned. 2235 415 Unsupported Media Type - The server does not support the content 2236 type of the update instructions in the request message body. 2238 418 Unprocessable Entity - The entity body submitted with the PATCH 2239 was not understood by the resource. 2241 419 Insufficient Space on Resource - The resource does not have 2242 sufficient space to record the state of the resource after the 2243 execution of this method. 2245 8.15.4. HTML file modification Example 2247 The following example shows a modification of the title and contents 2248 of the HTML resource http://www.example.org/hello.html. 2250 Before: 2251 2252 2253 Hello world HTML page 2254 2255 2256

Hello, world!

2257 2258 2260 PATCH Request: Response: 2262 PATCH hello.html HTTP/1.1 2263 Host: www.example.org 2264 Content-Type: text/xml 2265 Content-Length: xxx 2267 HTTP/1.1 100 Continue 2269 2270 2272 2273 2274 14&003CTITLE&003ENew 2275 Title&003C/TITLE&003E 2276 38-50 2277 86&003CP&003ENew paragraph&003C/P&003E 2279 2281 HTTP/1.1 200 OK 2283 After: 2284 2285 2286 New Title 2287 2288 2289

Hello, world!

2290

New paragraph

2291 2292 2294 9. HTTP Headers for Distributed Authoring 2296 9.1. Collection-Member Header 2298 CollectionMember = "Collection-Member" ":" URI ; URI is defined in 2299 section 3.2.1 of [Fielding et al., 1997] 2301 The Collection-Member header specifies the URI of an external 2302 resource to be added/deleted to/from a collection. 2304 9.2. DAV Header 2306 DAV = "DAV" ":" ("1" | "2" | extend) 2308 This header indicates that the resource supports the DAV schema and 2309 protocol to the level indicated. All DAV compliant resources MUST 2310 return the DAV header on all OPTIONS responses. 2312 9.3. Depth Header 2314 Depth = "Depth" ":" ("0" | "1" | "infinity") 2316 The Depth header is used with methods executed on collections to 2317 indicate whether the method is to be applied only to the collection 2318 (Depth = 0), to the collection and its immediate children, (Depth = 2319 1), or the collection and all its progeny (Depth = infinity). Note 2320 that Depth = 1 and Depth = infinity behavior only applies to 2321 internal member resources, and not to external member resources. 2323 The Depth header is only supported if a method's definition 2324 explicitly provides for such support. 2326 The following rules are the default behavior for any method that 2327 supports the depth header. A method MAY override these defaults by 2328 defining different behavior in its definition. 2330 Methods which support the depth header MAY choose not to support all 2331 of the header's values and MAY define, on a case by case basis, the 2332 behavior of the method on a collection if a depth header is not 2333 present. For example, the MOVE method only supports Depth = infinity 2334 and if a depth header is not present will act as if a Depth = 2335 infinity header had been applied. 2337 Clients MUST NOT rely upon methods executing on members of their 2338 hierarchies in any particular order or the execution being atomic. 2339 Note that methods MAY provide guarantees on ordering and atomicity. 2341 Upon execution, a method with a depth header will perform as much of 2342 its assigned task as possible and then return a response specifying 2343 what it was able to accomplish and what it failed to do. 2345 So, for example, an attempt to COPY a hierarchy may result in some 2346 of the members being copied and some not. 2348 Any headers on a method with a depth header MUST be applied to all 2349 resources in the scope of the method. For example, an if-match 2350 header will have its value applied against every resource in the 2351 method's scope and will cause the method to fail if the header fails 2352 to match. 2354 If a resource, source or destination, within the scope of the method 2355 is locked in such a way as to prevent the successful execution of 2356 the method, then the lock token for that resource MUST be submitted 2357 with the request in the Lock-Token request header. 2359 9.4. Destination Header 2361 Destination = "Destination" ":" URI 2363 The Destination header specifies a destination resource for methods 2364 such as COPY and MOVE, which take two URIs as parameters. 2366 9.5. Destroy Header 2368 DestroyHeader = "Destroy" ":" #Choices 2370 Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | extend 2372 Extend = RFC-Reg | Coded-URL 2374 RFC-Req = Token ; This is a token value (defined in section 2.2 of 2375 [Fielding et al., 1997]) that has been published as an RFC. 2377 Coded-URL = "<" URI ">" 2379 When deleting a resource the client often wishes to specify exactly 2380 what sort of delete should be performed. The Destroy header, used 2381 with the Mandatory header, allows the client to specify the end 2382 result it desires. The Destroy header is specified as follows: 2384 The Undelete token requests that, if possible, the resource should 2385 be left in a state such that it can be undeleted. The server is not 2386 required to honor this request. 2388 The NoUndelete token requests that the resource MUST NOT be left in 2389 a state such that it can be undeleted. 2391 The VersionDestroy token includes the functionality of the 2392 NoUndelete token and extends it to include having the server remove 2393 all versioning references to the resource that it has control over. 2395 9.6. Enforce-Live-Properties Header 2397 EnforceLiveProperties = "Enforce-Live-Properties_ _:" (_*_ | "Omit" 2398 | 1*(Property-Name)) 2400 Property-Name = Coded-URL 2402 The Enforce-Live-Properties header specifies properties that MUST be 2403 _live_ after they are copied (moved) to the destination resource of 2404 a copy (or move). If the value _*_ is given for the header, then it 2405 designates all live properties on the source resource. If the value 2406 is "Omit" then the server MUST NOT duplicate on the destination 2407 resource any properties that are defined on the source resource. If 2408 this header is not included then the server is expected to act as 2410 defined by the default property handling behavior of the associated 2411 method. 2413 9.7. If-None-State-Match 2415 If-None-State-Match = "If-None-State-Match" ":" 1#Coded-URL 2417 The If-None-State-Match header is intended to have similar 2418 functionality to the If-None-Match header defined in section 14.26 2419 of RFC 2068. However the if-none-state-match header is intended for 2420 use with any URI which represents state information about a 2421 resource, referred to as a state token. A typical example is a lock 2422 token. 2424 If any of the state tokens identifies the current state of the 2425 resource, the server MUST NOT perform the requested method. 2426 Instead, if the request method was GET, HEAD, INDEX, or PROPFIND, 2427 the server SHOULD respond with a 304 Not Modified response, 2428 including the cache-related entity-header fields (particularly ETag) 2429 of the current state of the resource. For all other request 2430 methods, the server MUST respond with a status of 412 Precondition 2431 Failed. 2433 If none of the state tokens identifies the current state of the 2434 resource, the server MAY perform the requested method. 2436 If any of the tokens is not recognized then the method MUST fail 2437 with a 412 Precondition Failed. 2439 Note that the "AND" and "OR" keywords specified with the If-State- 2440 Match header are intentionally not defined for If-None-State-Match, 2441 because this functionality is not required. 2443 9.8. If-State-Match 2445 If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#Coded-URL 2447 The If-State-Match header is intended to have similar functionality 2448 to the If-Match header defined in section 14.25 of RFC 2068. 2449 However the If-State-Match header is intended for use with any URI 2450 which represents state information about a resource. A typical 2451 example is a lock token. 2453 If the AND keyword is used and all of the state tokens identify the 2454 state of the resource, then the server MAY perform the requested 2455 method. If the OR keyword is used and any of the state tokens 2456 identifies the current state of the resource, then the server MAY 2457 perform the requested method. If the keyword requirement for the 2458 the keyword used is not met, the server MUST NOT perform the 2459 requested method, and MUST return a 412 Precondition Failed 2460 response. 2462 If any of the tokens is not recognized then the method MUST fail 2463 with a 412 Precondition Failed. 2465 9.9. Lock-Info Request Header 2467 LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope [SP 2468 AdditionalLocks] [SP Lock-Tree] 2469 DAVLockType = "LockType" "=" DAVLockTypeValue 2470 DAVLockTypeValue = ("Write" | Extend) 2471 DAVLockScope = "LockScope" "=" DAVLockScopeValue 2472 DAVLockScopeValue = ("Exclusive" |"Shared" | Extend) 2473 AdditionalLocks = "AddLocks" "=" 1*("<" URI ">") 2474 Lock-Tree = "Lock-Tree" "=" ("T" | "F") 2476 The Lock-Info request header specifies the scope and type of a lock 2477 for a LOCK method request. The syntax specification below is 2478 extensible, allowing new type and scope identifiers to be added. 2480 The LockType field specifies the access type of the lock. At 2481 present, this specification only defines one lock type, the "Write" 2482 lock. The LockScope field specifies whether the lock is an 2483 exclusive lock, or a shared lock. The AddLocks field specifies 2484 additional URIs, beyond the Request-URI, to which the lock request 2485 applies. The LockTree field is used to specify recursive locks. If 2486 the LockTree field is "T", the lock request applies to the hierarchy 2487 traversal of the internal member resources of the Request-URI, and 2488 the AddLocks URIs, inclusive of the Request-URI and the AddLocks 2489 URIs. It is not an error if LockTree is "T", and the Request-URI or 2490 the AddLocks URIs have no internal member resources. By default, 2491 the value of LockTree is "F", and this field MAY be omitted when its 2492 value is "F". 2494 9.10. Lock-Token Request Header 2496 Lock-Token = "Lock-Token" ":" 1#Coded-URL 2498 The Lock-Token request header, containing a lock token owned by the 2499 requesting principal, is used by the principal to indicate that the 2500 principal is aware of the existence of the lock specified by the 2501 lock token. 2503 If the following conditions are met: 2505 1) The method is restricted by a lock type that requires the 2506 submission of a lock token, such as a write lock, 2507 2) The user-agent has authenticated itself as a principal, 2508 3) The user-agent is submitting a method request to a resource on 2509 which the principal owns a write lock, 2511 Then: 2513 1) The method request MUST include a Lock-Token header with the lock 2514 token, or, 2515 2) The method MUST fail with a 409 Conflict status code. 2517 If multiple resources are involved with a method, such as a COPY or 2518 MOVE method, then the lock tokens, if any, for all involved 2519 resources, MUST be included in the Lock-Token request header. 2521 For example, Program A, used by user A, takes out a write lock on a 2522 resource. Program A then makes a number of PUT requests on the 2523 locked resource. All the requests contain a Lock-Token request 2524 header that includes the write lock state token. Program B, also 2525 run by User A, then proceeds to perform a PUT to the locked 2526 resource. However, program B was not aware of the existence of the 2527 lock and so does not include the appropriate Lock-Token request 2528 header. The method is rejected even though principal A is 2529 authorized to perform the PUT. Program B can, if it so chooses, now 2530 perform lock discovery and obtain the lock token. Note that 2531 programs A and B can perform GETs without using the Lock-Token 2532 header because the ability to perform a GET is not affected by a 2533 write lock. 2535 Having a lock token provides no special access rights. Anyone can 2536 find out anyone else's lock token by performing lock discovery. 2537 Locks are to be enforced based upon whatever authentication 2538 mechanism is used by the server, not based on the secrecy of the 2539 token values. 2541 9.11. Lock-Token Response Header 2542 Lock-Token = "Lock-Token" ":" Coded-URL 2544 If a resource is successfully locked then a Lock-Token header will 2545 be returned containing the lock token that represents the lock. 2547 9.12. Overwrite Header 2549 Overwrite = "Overwrite" ":" ("T" | "F") 2551 The Overwrite header specifies whether the server should overwrite 2552 the state of a non-null destination resource during a COPY or MOVE. 2553 A value of _F_ states that the server MUST NOT perform the COPY or 2554 MOVE operation if the state of the destination resource is non-null. 2555 By default, the value of Overwrite is _T,_ and a client MAY omit 2556 this header from a request when its value is _T._ While the 2557 Overwrite header appears to duplicate the functionality of the If- 2558 Match: * header of HTTP/1.1, If-Match applies only to the Request- 2559 URI, and not to the Destination of a COPY or MOVE. 2561 If a COPY or MOVE is not performed due to the value of the Overwrite 2562 header, the method MUST fail with a 409 Conflict status code. 2564 9.13. Propfind Request Header 2566 Propfind = "Propfind" ":" ("allprop" | "propname" | RFC-Reg | 2567 1*(Property-Name)) 2569 The Propfind header is used to specify which properties are to be 2570 returned in a PROPFIND method. The properties are identified by 2571 their URIs. Two special tokens are defined for use with the 2572 Propfind header, allprop and propname. The allprop token specifies 2573 that all property names and values on the resource are to be 2574 returned. The propname token specifies that only a list of property 2575 names on the resource are to be returned. 2577 9.14. Status-URI Response Header 2579 The Status-URI response header MAY be used with the 102 Processing 2580 response code to inform the client as to the status of a method. 2582 Status-URI = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status- 2583 Code is defined in 6.1.1 of [Fielding et al., 1997] 2585 The URIs listed in the header are source resources which have been 2586 affected by the outstanding method. The status code indicates the 2587 resolution of the method on the identified resource. So, for 2588 example, if a MOVE method on a collection is outstanding and a 102 2589 "Processing" response with a Status-URI response header is returned, 2590 the included URIs will indicate resources that have had move 2591 attempted on them and what the result was. 2593 9.15. Timeout Header 2594 TimeOut = "Timeout" ":" 1#TimeType 2595 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) 2596 DAVTimeOutVal = 1*digit 2597 Other = Extend field-value ; See section 4.2 of RFC 2068 2599 Clients MAY include Timeout headers in their LOCK requests. 2600 However, the server is not required to honor or even consider these 2601 requests. Clients MUST NOT submit a Timeout request header with any 2602 method other than a LOCK method. 2604 A Timeout request header MUST contain at least one TimeType and MAY 2605 contain multiple TimeType entries. The purpose of listing multiple 2606 TimeType entries is to indicate multiple different values and value 2607 types that are acceptable to the client. The client lists the 2608 TimeType entries in order of preference. 2610 The Timeout response header MUST use a Second value, Infinite, or a 2611 TimeType the client has indicated familiarity with. The server MAY 2612 assume a client is familiar with any TimeType submitted in a Timeout 2613 header. 2615 The _Second_ TimeType specifies the number of seconds that MUST 2616 elapse between granting of the lock at the server, and the automatic 2617 removal of the lock. A server MUST not generate a timeout value for 2618 _Second_ greater than 2^32-1. 2620 The timeout counter is restarted any time an owner of the lock sends 2621 a method to any member of the lock, including unsupported methods, 2622 or methods which are unsuccessful. It is recommended that the HEAD 2623 method be used when the goal is simply to restart the timeout 2624 counter. 2626 If the timeout expires then the lock is lost. Specifically the 2627 server SHOULD act as if an UNLOCK method was executed by the server 2628 on the resource using the lock token of the timed-out lock, 2629 performed with its override authority. Thus logs should be updated 2630 with the disposition of the lock, notifications should be sent, 2631 etc., just as they would be for an UNLOCK request. 2633 Servers are advised to pay close attention to the values submitted 2634 by clients, as they will be indicative of the type of activity the 2635 client intends to perform. For example, an applet running in a 2636 browser may need to lock a resource, but because of the instability 2637 of the environment within which the applet is running, the applet 2638 may be turned off without warning. As a result, the applet is 2639 likely to ask for a relatively small timeout value so that if the 2640 applet dies, the lock can be quickly harvested. However, a document 2641 management system is likely to ask for an extremely long timeout 2642 because its user may be planning on going off-line. 2644 10. Response Code Extensions to HTTP/1.1 2646 The following response codes are added to those defined in HTTP/1.1 2647 [Fielding et al., 1997]. 2649 10.1. 102 Processing 2651 Methods can potentially take a long period of time to process, 2652 especially methods that support the Depth header. In such cases the 2653 client may time-out the connection while waiting for a response. To 2654 prevent this the server MAY return a 102 response code to indicate 2655 to the client that the server is still processing the method. 2657 If a method is taking longer than 20 seconds (a reasonable, but 2658 arbitrary value) to process the server SHOULD return a 102 2659 "Processing" response. 2661 10.2. 207 Multi-Status 2663 The response requires providing status for multiple independent 2664 operations. 2666 10.3. 418 Unprocessable Entity 2668 The server understands the content type of the request entity, but 2669 was unable to process the contained instructions. 2671 10.4. 419 Insufficient Space on Resource 2673 The resource does not have sufficient space to record the state of 2674 the resource after the execution of this method. 2676 10.5. 420 Method Failure 2678 The method was not executed on a particular resource within its 2679 scope because some part of the method's execution failed causing the 2680 entire method to be aborted. For example, if a resource could not 2681 be moved as part of a MOVE method, all the other resources would 2682 fail with a 420 Method Failure. 2684 10.6. 421 Destination Locked 2686 The destination resource of a method is locked, and either the 2687 request did not contain a valid Lock-Info header, or the Lock-Info 2688 header identifies a lock held by another principal. 2690 11. Multi-Status Response 2692 The default 207 Multi-Status response body is a text/xml HTTP entity 2693 that contains a single XML element called multistatus, which 2694 contains a set of XML elements called response, one for each 200, 2695 300, 400, and 500 series status code generated during the method 2696 invocation. 100 series status codes MUST NOT be recorded in a 2697 response XML element. 2699 11.1. multistatus XML Element 2701 Name: multistatus 2702 Namespace: http://www.ietf.org/standards/dav/ 2703 Purpose: Contains multiple response messages. 2704 Parent: Any 2705 Value: 1*response [responsedescription] 2706 Description: The responsedescription at the top level is used to 2707 provide a general message describing the overarching nature of the 2708 response. If this value is available an application MAY use it 2709 instead of presenting the individual response descriptions contained 2710 within the responses. 2712 11.2. response XML Element 2714 Name: response 2715 Namespace: http://www.ietf.org/standards/dav/ 2716 Purpose: Holds a single response 2717 Parent: multistatus 2718 Value: href [prop] status [responsedescription] 2719 Description: Prop MUST contain one or more empty XML elements 2720 representing the names of properties. Multiple properties may be 2721 included if the same response applies to them all. If href is used 2722 then the response refers to a problem with the referenced resource, 2723 not a property. 2725 11.3. status XML Element 2727 Name: status 2728 Namespace: http://www.ietf.org/standards/dav/ 2729 Purpose: Holds a single HTTP status-line 2730 Parent: response 2731 Value: status-line ;status-line defined in [Fielding et al., 2732 1997] 2734 11.4. responsedescription XML Element 2736 Name: responsedescription 2737 Namespace: http://www.ietf.org/standards/dav/ 2738 Purpose: Contains a message that can be displayed to the user 2739 explaining the nature of the response. 2740 Parent: multistatus | response 2741 Value: Any 2742 Description: This XML element provides information suitable to be 2743 presented to a user. 2745 12. Generic DAV XML Elements 2746 12.1. href XML Element 2748 Name: href 2749 Namespace: http://www.ietf.org/standards/dav/ 2750 Purpose: To identify that the content of the element is a URI. 2751 Parent: Any 2752 Value: URI ; See section 3.2.1 of [Fielding et al., 1997] 2754 12.2. link XML Element 2756 Name: link 2757 Namespace: http://www.ietf.org/standards/dav/ 2758 Purpose: To identify a property as a link and to contain the 2759 source and destination of that link. 2760 Values= 1*src 1*dst 2761 Description: Link is used to provide the sources and destinations of 2762 a link. The type of the property containing the link XML element 2763 provides the type of the link. Link is a multi-valued element, so 2764 multiple Links may be used together to indicate multiple links with 2765 the same type. 2767 12.2.1. src XML Element 2769 Name: src 2770 Namespace: http://www.ietf.org/standards/dav/ 2771 Purpose: To indicate the source of a link. 2772 Parent: link 2773 Values= URI 2775 12.2.2. dst XML Element 2777 Name: dst 2778 Namespace: http://www.ietf.org/standards/dav/ 2779 Purpose: To indicate the destination of a link 2780 Parent: link 2781 Values= URI 2783 12.2.3. Example 2785 2786 2787 2788 2789 2790 2791 Source 2792 http://foo.bar/program 2793 http://foo.bar/src/main.c 2794 2795 2796 Library 2797 http://foo.bar/program 2798 http://foo.bar/src/main.lib 2799 2800 2801 Makefile 2802 http://foo.bar/program 2803 http://foo.bar/src/makefile 2804 2805 2806 2808 In this example the resource http://foo.bar/program has a source 2809 property that contains three links. Each link contains three 2810 elements, two of which, src and dst, are part of the DAV schema 2811 defined in this document, and one which is defined by the schema 2812 http://www.foocorp.com/project/ (Source, Library, and Makefile). A 2813 client which only implements the elements in the DAV spec will not 2814 understand the foocorp elements and will ignore them, thus seeing 2815 the expected source and destination links. An enhanced client may 2816 know about the foocorp elements and be able to present the user with 2817 additional information about the links. This example demonstrates 2818 the power of XML markup that allows for element values to be 2819 enhanced without breaking older clients. 2821 12.3. prop XML element 2823 Name: prop 2824 Namespace: http://www.ietf.org/standards/dav/ 2825 Purpose: Contains properties related to a resource. 2826 Parent: Any 2827 Values: XML Elements 2828 Description: The prop XML element is a generic container for 2829 properties defined on resources. All elements inside prop MUST 2830 define properties related to the resource. No other elements may be 2831 used inside of a prop element. 2833 13. DAV Properties 2835 13.1. creationdate Property 2837 Name: creationdate 2838 Namespace: http://www.ietf.org/standards/dav/ 2839 Purpose: The time and date the resource was created. 2840 Value: The time and date MUST be given in ISO 8601 format 2841 [ISO8601] 2842 Description: This property SHOULD be defined on all DAV compliant 2843 resources. If present, it contains a timestamp of the moment when 2844 the resource was created (i.e., the moment it had non-null state). 2846 13.2. displayname Property 2847 Name: displayname 2848 Namespace: http://www.ietf.org/standards/dav/ 2849 Purpose: A name for the resource that is suitable for 2850 presentation to a user. 2851 Value: Any valid XML character data (as defined in [Bray, 2852 Sperberg-McQueen, 1997]) 2853 Description:This property SHOULD be defined on all DAV compliant 2854 resources. If present, the property contains a description of the 2855 resource that is suitable for presentation to a user. 2857 13.3. get-content-language Property 2859 Name: get-content-language 2860 Namespace: http://www.ietf.org/standards/dav/ 2861 Purpose: Contains the Content-Language header returned by a GET 2862 without accept headers. If no Content-Language header is available, 2863 this property MUST NOT exist. 2864 Value: language-tag ;language-tag is defined in section 14.13 2865 of RFC 2068 2867 13.4. get-content-length Property 2869 Name: get-content-length 2870 Namespace: http://www.ietf.org/standards/dav/ 2871 Purpose: Contains the Content-Length header returned by a GET 2872 without accept headers. If no Content-Length header is available, 2873 this property MUST NOT exist. 2874 Value: content-length ; see section 14.14 of RFC 2068 2876 13.5. get-content-type Property 2878 Name: get-content-type 2879 Namespace: http://www.ietf.org/standards/dav/ 2880 Purpose: Contains the Content-Type header returned by a GET 2881 without accept headers. If no Content-Type header is available, 2882 this property MUST NOT exist. 2883 Value: media-type ; defined in Section 3.7 of [Fielding et 2884 al., 1997] 2886 13.6. get-etag Property 2888 Name: get-etag 2889 Namespace: http://www.ietf.org/standards/dav/ 2890 Purpose: Contains the ETag header returned by a GET without 2891 accept headers. If no ETag header is available, this property MUST 2892 NOT exist. 2893 Value: entity-tag ; defined in Section 3.11 of [Fielding et 2894 al., 1997] 2895 Description:Note that the ETag on some resource may reflect changes 2896 in any part of the state of the resource, not necessarily just a 2897 change to the response to the GET method. For example, a change in 2898 the ACL may cause the ETag to change. 2900 13.7. get-last-modified Property 2902 Name: get-last-modified 2903 Namespace: http://www.ietf.org/standards/dav/ 2904 Purpose: Contains the Last-Modified header returned by a GET 2905 method without accept headers. If no Last-Modified header is 2906 available, this property MUST NOT exist. 2907 Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et 2908 al., 1997] 2909 Description:Note that the last-modified date on some resource may 2910 reflect changes in any part of the state of the resource, not 2911 necessarily just a change to the response to the GET method. For 2912 example, a change in a property may cause the last-modified date to 2913 change. 2915 13.8. index-content-language Property 2917 Name: index-content-language 2918 Namespace: http://www.ietf.org/standards/dav/ 2919 Purpose: Contains the Content-Language header returned by an 2920 INDEX without accept headers. If no Content-Language header is 2921 available, this property MUST NOT exist. 2922 Value: language-tag ;language-tag is defined in section 14.13 2923 of RFC 2068 2925 13.9. index-content-length Property 2927 Name: index-content-length 2928 Namespace: http://www.ietf.org/standards/dav/ 2929 Purpose: Contains the Content-Length header returned by an INDEX 2930 without accept headers. If no Content-Length header is available, 2931 this property MUST NOT exist. 2932 Value: content-length ; see section 14.14 of RFC 2068 2934 13.10. index-content-type Property 2936 Name: index-content-type 2937 Namespace: http://www.ietf.org/standards/dav/ 2938 Purpose: Contains the Content-Type header returned by an INDEX 2939 without accept headers. If no Content-Type header is available, 2940 this property MUST NOT exist. 2941 Value: media-type ; defined in Section 3.7 of [Fielding et 2942 al., 1997] 2944 13.11. index-etag Property 2946 Name: index-etag 2947 Namespace: http://www.ietf.org/standards/dav/ 2948 Purpose: Contains the ETag header returned by an INDEX without 2949 accept headers. If no ETag header is available, this property MUST 2950 NOT exist. 2952 Value: entity-tag ; defined in Section 3.11 of [Fielding et 2953 al., 1997] 2954 Description:Note that the ETag on some resource may reflect changes 2955 in any part of the state of the resource, not necessarily just a 2956 change to the response to the INDEX method. For example, a change 2957 in the ACL may cause the ETag to change. 2959 13.12. index-last-modified Property 2961 Name: index-last-modified 2962 Namespace: http://www.ietf.org/standards/dav/ 2963 Purpose: Contains the Last-Modified header returned by an INDEX 2964 method without accept headers. If no Last-Modified header is 2965 available, this property MUST NOT exist. 2966 Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et 2967 al., 1997] 2968 Description:Note that the last-modified date on some resource may 2969 reflect changes in any part of the state of the resource, not 2970 necessarily just a change to the response to the INDEX method. For 2971 example, a change in a property may cause the last-modified date to 2972 change. 2974 13.13. lockdiscovery Property 2976 Name: lockdiscovery 2977 Namespace: http://www.ietf.org/standards/dav/ 2978 Purpose: To discover what locks are active on a resource 2979 Values= *activelock 2980 Description:The lockdiscovery property returns a listing of who has 2981 a lock, what type of lock he have, the timeout type and the time 2982 remaining on the timeout, and the associated lock token. The server 2983 is free to withhold any or all of this information if the requesting 2984 principal does not have sufficient access rights to see the 2985 requested data. A server which supports locks MUST provide the 2986 lockdiscovery property on any resource with locks on it. 2988 13.13.1. activelock XML Element 2990 Name: activelock 2991 Namespace: http://www.ietf.org/standards/dav/ 2992 Purpose: A multivalued XML element that describes a particular 2993 active lock on a resource 2994 Parent: lockdiscovery 2995 Values= locktype lockscope [addlocks] owner timeout locktoken 2997 13.13.2. owner XML Element 2999 Name: owner 3000 Namespace: http://www.ietf.org/standards/dav/ 3001 Purpose: Returns owner information 3002 Parent: activelock 3003 Values= XML:REF | *PCDATA 3004 13.13.3. timeout XML Element 3006 Name: timeout 3007 Namespace: http://www.ietf.org/standards/dav/ 3008 Purpose: Returns information about the timeout associated with 3009 the lock 3010 Parent: activelock 3011 Values= TimeType 3013 13.13.4. addlocks XML Element 3015 Name: addlocks 3016 Namespace: http://www.ietf.org/standards/dav/ 3017 Purpose: Lists additional resources associated with this lock, if 3018 any. 3019 Parent: activelock 3020 Values= 1*href 3022 13.13.5. locktoken XML Element 3024 Name: locktoken 3025 Namespace: http://www.ietf.org/standards/dav/ 3026 Purpose: Returns the lock token 3027 Parent: activelock 3028 Values= href 3029 Description:The href contains a Lock-Token-URL. 3031 13.13.6. Example 3033 PROPFIND /container/ HTTP/1.1 3034 Host: www.foo.bar 3035 Content-Length: xxxx 3036 Content-Type: text/xml 3038 3039 3040 3041 3042 3044 HTTP/1.1 207 Multi-Status 3045 Content-Type: text/xml 3046 Content-Length: xxxxx 3048 3049 3050 3051 3052 3053 3054 3055 write 3056 exclusive 3057 3058 http://foo.com/doc/ 3059 3060 Jane Smith 3061 Infinite 3062 3063 iamuri:unique!!!!! 3064 3065 3066 3067 3068 HTTP/1.1 200 OK 3069 3070 3072 This resource has a single exclusive write lock on it, with an 3073 infinite timeout. This same lock also covers the resource 3074 http://foo.com/doc/. 3076 13.14. resourcetype Property 3078 Name: resourcetype 3079 Namespace: http://www.ietf.org/standards/dav/ 3080 Purpose: This property contains a series of XML elements that 3081 specify information regarding the nature of the resource. This 3082 specification only defines a single value, collection. 3083 Value: XML elements 3084 Description:This property MUST be defined on all DAV compliant 3085 resources. The default value is empty. 3087 13.14.1. collection XML Element 3089 Name: collection 3090 Namespace: http://www.ietf.org/standards/dav/ 3091 Purpose: Identifies the associated resource as a collection. 3092 Collection resources MUST define this value with the resourcetype 3093 property. 3094 Parent: resourcetype 3095 Values: None 3097 13.15. Source Link Property Type 3099 Name: source 3100 Namespace: http://www.ietf.org/standards/dav/link/ 3101 Purpose: The destination of the source link identifies the 3102 resource that contains the unprocessed source of the link's source. 3103 Parent: None 3104 Value: An XML document with zero or more link XML elements. 3106 Discussion: The source of the link (src) is typically the URI of the 3107 output resource on which the link is defined, and there is typically 3108 only one destination (dst) of the link, which is the URI where the 3109 unprocessed source of the resource may be accessed. When more than 3111 one link destination exists, this specification asserts no policy on 3112 ordering. 3114 13.16. supportedlock Property 3116 Name: supportedlock 3117 Namespace: http://www.ietf.org/standards/dav/ 3118 Purpose: To provide a listing of the lock capabilities supported 3119 by the resource. 3120 Values: An XML document containing zero or more LockEntry XML 3121 elements. 3122 Description:The supportedlock property of a resource returns a 3123 listing of the combinations of scope and access types which may be 3124 specified in a lock request on the resource. Note that the actual 3125 contents are themselves controlled by access controls so a server is 3126 not required to provide information the client is not authorized to 3127 see. If supportedlock is available on _*_ then it MUST define the 3128 set of locks allowed on all resources on that server. 3130 13.16.1. lockentry XML Element 3132 Name: lockentry 3133 Namespace: http://www.ietf.org/standards/dav/ 3134 Purpose: Defines a DAVLockType/LockScope pair that may be legally 3135 used with a LOCK on the specified resource. 3136 Parent: supportedlock 3137 Values= locktype lockscope 3139 13.16.2. locktype XML Element 3141 Name: locktype 3142 Namespace: http://www.ietf.org/standards/dav/ 3143 Purpose: Lists a DAVLockType 3144 Parent: lockentry 3145 Values= DAVLockTypeValue 3147 13.16.3. lockscope XML Element 3149 Name: lockscope 3150 Namespace: http://www.ietf.org/standards/dav/ 3151 Purpose: Lists a DAVLockScope 3152 Parent: lockentry 3154 Values: DAVLockScopeValue 3156 13.16.4. Example 3158 PROPFIND /container/ HTTP/1.1 3159 Host: www.foo.bar 3160 Content-Length: xxxx 3161 Content-Type: text/xml 3163 3164 3165 3166 3167 3169 HTTP/1.1 207 Multi-Status 3170 Content-Type: text/xml 3171 Content-Length: xxxxx 3173 3174 3175 3176 3177 3178 3179 3180 Write 3181 Exclusive 3182 3183 3184 Write 3185 Shared 3186 3187 3188 3189 HTTP/1.1 200 OK 3190 3191 3193 14. DAV Compliance Levels 3195 A DAV compliant resource can choose from two levels of compliance. 3196 A client can discover which level a resource supports by executing 3197 OPTIONS on the resource, and examining the "DAV" header which is 3198 returned. 3200 Since this document describes extensions to the HTTP/1.1 protocol, 3201 minimally all DAV compliant resources, clients, and proxies MUST be 3202 compliant with RFC 2068 [Fielding et al., 1997]. 3204 14.1. Level 1 3206 A level 1 compliant resource MUST meet all "MUST" requirements in 3207 all sections of this document. 3209 14.2. Level 2 3210 A level 2 compliant resource MUST meet all level 1 requirements and 3211 support the supportedlock property as well as the LOCK method. 3213 15. Internationalization Considerations 3215 In the realm of internationalization issues, this specification is 3216 substantively in compliance with the IETF Character Set Policy 3217 [Alvestrand, 1997]. In this specification, human-readable fields can 3218 be found in either the value of a property, or in an error message 3219 returned in a response entity body. In both cases, the human- 3220 readable content is encoded using XML, which has explicit provisions 3221 for character set tagging and encoding, and requires by default that 3222 XML processors read XML elements encoded using the UTF-8 and UCS-2 3223 encodings of the ISO 10646 basic multilingual plane. Furthermore, 3224 XML contains provisions for encoding XML elements using other 3225 encoding schemes, notable among them UCS-4, which permits encoding 3226 of characters from any ISO 10646 character plane. 3228 The default character set encoding for XML data in this 3229 specification, and in general, is UTF-8. WebDAV compliant 3230 applications MUST support the UTF-8 and UCS-2 character set 3231 encodings for XML elements, and SHOULD support the UCS-4 encoding. 3232 The XML character set encoding declaration for each supported 3233 character set MUST also be supported, since it is by using this 3234 encoding declaration that an XML processor determines the encoding 3235 of an element. 3237 XML also provides language tagging capability which provides the 3238 ability to specify the language of the contents of a particular XML 3239 element. Although XML, and hence WebDAV, does not use RFC 1766 3240 language tags for its language names, the benefit of using standard 3241 XML in this context outweighs the advantage of using RFC 1766 3242 language tags. 3244 Names used within this specification fall into two categories: names 3245 specific to protocol elements such as methods and headers, names of 3246 XML elements, and names of properties. Naming of protocol elements 3247 follows the precedent of HTTP, using English names encoded in 3248 USASCII for methods and headers. Since these protocol elements are 3249 not visible to users, and are in fact simply long token identifiers, 3250 they do not need to support encoding in multiple character sets. 3251 Similarly, though the names of XML elements used in this 3252 specification are English names encoded in UTF-8, these names are 3253 not visible to the user, and hence do not need to support multiple 3254 character set encodings. 3256 The name of a property defined on a resource is a URI. Although 3257 some applications (e.g., a generic property viewer) will display 3258 property URIs directly to their users, it is expected that the 3259 typical application will use a fixed set of properties, and will 3260 provide a mapping from the property name URI to a human-readable 3261 field when displaying the property name to a user. It is only in 3262 the case where the set of properties is not known ahead of time that 3263 an application need display a property name URI to a user. We 3264 recommend that applications provide human-readable property names 3265 wherever feasible. 3267 For error reporting, we follow the convention of HTTP/1.1 status 3268 codes, including with each status code a short, English description 3269 of the code (e.g., 421 Destination Locked). While the possibility 3270 exists that a poorly crafted user agent would display this message 3271 to a user, internationalized applications will ignore this message, 3272 and display an appropriate message in the user's language and 3273 character set. 3275 Since interoperation of clients and servers does not require locale 3276 information, this specification does not specify any mechanism for 3277 transmission of this information. 3279 16. Security Considerations 3280 [TBD] 3282 17. Terminology 3284 Collection - A resource that contains member resources. 3286 Member Resource - A resource contained by a collection. There are 3287 two types of member resources: external and internal. 3289 Internal Member Resource _ A member resource of a collection whose 3290 URI is relative to the URI of the collection. 3292 External Member Resource - A member resource of a collection with an 3293 absolute URI that is not relative to its parent's URI. 3295 Property - A name/value pair that contains descriptive information 3296 about a resource. 3298 Live Property _ A property whose semantics and syntax are enforced 3299 by the server. For example, a live "content-length" property would 3300 have its value, the length of the entity returned by a GET request, 3301 automatically calculated by the server. 3303 Dead Property _ A property whose semantics and syntax are not 3304 enforced by the server. The server only records the value of a dead 3305 property; the client is responsible for maintaining the consistency 3306 of the syntax and semantics of a dead property. 3308 18. Copyright 3309 The following copyright notice is copied from RFC 2026 chapter 10.4, 3310 and describes the applicable copyright for this document 3312 Copyright (C) The Internet Society November 19, 1997. All Rights 3313 Reserved. 3315 This document and translations of it may be copied and furnished to 3316 others, and derivative works that comment on or otherwise explain it 3317 or assist in its implementation may be prepared, copied, published 3318 and distributed, in whole or in part, without restriction of any 3319 kind, provided that the above copyright notice and this paragraph 3320 are included on all such copies and derivative works. However, this 3321 document itself may not be modified in any way, such as by removing 3322 the copyright notice or references to the Internet Society or other 3323 Internet organizations, except as needed for the purpose of 3324 developing Internet standards in which case the procedures for 3325 copyrights defined in the Internet Standards process must be 3326 followed, or as required to translate it into languages other than 3327 English. 3329 The limited permissions granted above are perpetual and will not be 3330 revoked by the Internet Society or its successors or assignees. 3332 This document and the information contained herein is provided on an 3333 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3334 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3335 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3336 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3337 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3339 19. Acknowledgements 3341 A specification such as this thrives on piercing critical review and 3342 withers from apathetic neglect. The authors gratefully acknowledge 3343 the contributions of the following people, whose insights were so 3344 valuable at every stage of our work. 3346 Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell, Bernard 3347 Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, 3348 Jr., Jim Davis, Keith Dawson, Mark Day, Martin Duerst, David Durand, 3349 Lee Farrell, Chuck Fay, Roy Fielding, Mark Fisher, Alan Freier, 3350 George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, 3351 Steve Henning, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul 3352 Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, 3353 Michael Mealling, Keith Moore, Henrik Nielsen, Kenji Ota, Bob 3354 Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, 3355 Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, 3356 Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John 3357 Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and 3358 Lauren Wood. 3360 One from this list deserves special mention. The contributions by 3361 Larry Masinter have been invaluable, both in helping the formation 3362 of the working group and in patiently coaching the authors along the 3363 way. In so many ways he has set high standards we have toiled to 3364 meet. 3366 20. References 3368 [Alvestrand, 1997] H. T. Alvestrand, "IETF Policy on Character Sets 3369 and Languages." Internet-draft, work-in-progress. 3370 ftp://ds.internic.net/internet-drafts/draft-alvestrand-charset- 3371 policy-02.txt 3373 [Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture." 3374 Unpublished white paper, January 1997. 3375 http://www.w3.org/pub/WWW/DesignIssues/Metadata.html. 3377 [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate 3378 Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 3379 1997. 3381 [Bray, Sperberg-McQueen, 1997] T. Bray, C. M. Sperberg-McQueen, 3382 "Extensible Markup Language (XML): Part I. Syntax", WD-xml- 3383 lang.html, http://www.w3.org/pub/WWW/TR/WD-xml-lang.html. 3385 [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H. 3386 Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." 3387 RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. 3388 ftp://ds.internic.net/rfc/rfc2068.txt 3390 [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for 3391 Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995. 3392 ftp://ds.internic.net/rfc/rfc1807.txt 3394 [Leach, Salz, 1997] P. J. Leach, R. Salz, "UUIDs and GUIDs." 3395 Internet-draft (expired), work-in-progress, February, 1997. 3396 http://www.internic.net/internet-drafts/draft-leach-uuids-guids- 3397 00.txt 3399 [Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet 3400 draft (expired), work-in-progress, January, 1996. 3402 [MARC, 1994] Network Development and MARC Standards, Office, ed. 3403 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: 3404 Cataloging Distribution Service, Library of Congress. 3406 [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. 3407 Treese, "PICS Label Distribution Label Syntax and Communication 3408 Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-961031. 3409 http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html. 3411 [Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., 3412 D. Durand, "Requirements for Distributed Authoring and Versioning 3413 Protocol for the World Wide Web." RFC XXXX. Xerox, Univ. of Bologna, 3414 U.C. Irvine, Boston Univ. YYY, 1997. 3415 ftp://ds.internic.net/rfc/rfcXXXX.txt 3417 [WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata 3418 Operations." Unpublished manuscript. 3419 http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html 3421 [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel, 3422 "OCLC/NCSA Metadata Workshop Report." 3423 http://purl.oclc.org/metadata/dublin_core_report. 3425 [Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of 3426 Unicode and ISO 10646", Internet Draft, work-in-progress, draft- 3427 yergeau-utf8-rev-00.txt, http://www.internic.net/internet- 3428 drafts/draft-yergeau-utf8-rev-00.txt. 3430 21. Authors' Addresses 3432 Y. Y. Goland 3433 Microsoft Corporation 3434 One Microsoft Way 3435 Redmond, WA 98052-6399 3436 Email: yarong@microsoft.com 3438 E. J. Whitehead, Jr. 3439 Dept. Of Information and Computer Science 3440 University of California, Irvine 3441 Irvine, CA 92697-3425 3442 Email: ejw@ics.uci.edu 3444 A. Faizi 3445 Netscape 3446 685 East Middlefield Road 3447 Mountain View, CA 94043 3448 Email: asad@netscape.com 3450 S. R. Carter 3451 Novell 3452 1555 N. Technology Way 3453 M/S ORM F111 3454 Orem, UT 84097-2399 3455 Email: srcarter@novell.com 3457 D. Jensen 3458 Novell 3459 1555 N. Technology Way 3460 M/S ORM F111 3461 Orem, UT 84097-2399 3462 Email: dcjensen@novell.com