idnits 2.17.1 draft-reschke-webdav-locking-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2152. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2165. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2181), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 46 longer pages, the longest (page 34) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2518, but the abstract doesn't seem to directly say this. It does mention RFC2518 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2518, updated by this document, for RFC5378 checks: 1997-07-21) -- 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 (June 9, 2004) is 7260 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: 'Extension' is mentioned on line 1443, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11578' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Reschke 2 Internet-Draft greenbytes 3 Updates: 2518 (if approved) June 9, 2004 4 Expires: December 8, 2004 6 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol 7 draft-reschke-webdav-locking-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 8, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document specifies a set of methods and headers ancillary to 41 HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, 42 RFC2518) for the management of resource locking (collision 43 avoidance). It updates those sections from RFC2518 that specify 44 WebDAV's locking features. 46 Editorial Note 48 [[anchor1: Note that this document is not a product of the WebDAV 49 working group. It is just an experiment to study the feasability of 50 extracing the locking feature into a separate specification. 51 --reschke]] 53 Distribution of this document is unlimited. Please send comments to 54 the WebDAV working group at w3c-dist-auth@w3.org [1], which may be 55 joined by sending a message with subject "subscribe" to 56 w3c-dist-auth-request@w3.org [2]. 58 Discussions of the WEBDAV working group are archived at URL: . 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.2 Method Preconditions and Postconditions . . . . . . . . . 5 65 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 6 66 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1 Common XML elements used in property values . . . . . . . 6 68 3.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 6 69 3.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 6 71 3.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 7 72 3.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 8 73 3.3.1 Examples for the DAV:supportedlock property . . . . . 9 74 4. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.1 Example - Simple Lock Request . . . . . . . . . . . . 10 77 4.1.2 Example - Multi-Resource Lock Request . . . . . . . . 12 78 4.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 13 79 4.2.1 Example - Refreshing a Write Lock . . . . . . . . . . 14 80 5. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.1 Example - UNLOCK . . . . . . . . . . . . . . . . . . . . . 16 82 6. Additional status codes . . . . . . . . . . . . . . . . . . . 16 83 6.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7. Additional method semantics for other Methods . . . . . . . . 16 85 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 16 86 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 16 87 9. Security considerations . . . . . . . . . . . . . . . . . . . 17 88 9.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 17 89 10. Internationalization Considerations . . . . . . . . . . . . 17 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 94 13.2 Informative References . . . . . . . . . . . . . . . . . . . 18 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 96 A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 19 97 A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 19 98 A.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 19 99 A.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 19 100 A.2 Additional features . . . . . . . . . . . . . . . . . . . 20 101 A.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 20 102 B. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 20 103 B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 104 B.2 Locking . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 B.2.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . 21 106 B.2.2 Required Support . . . . . . . . . . . . . . . . . . . 22 107 B.2.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . 22 108 B.2.4 Lock Capability Discovery . . . . . . . . . . . . . . 22 109 B.2.5 Active Lock Discovery . . . . . . . . . . . . . . . . 23 110 B.2.6 Usage Considerations . . . . . . . . . . . . . . . . . 23 111 B.3 Write Lock . . . . . . . . . . . . . . . . . . . . . . . . 24 112 B.3.1 Methods Restricted by Write Locks . . . . . . . . . . 24 113 B.3.2 Write Locks and Lock Tokens . . . . . . . . . . . . . 24 114 B.3.3 Write Locks and Properties . . . . . . . . . . . . . . 24 115 B.3.4 Write Locks and Collections . . . . . . . . . . . . . 25 116 B.3.5 Write Locks and the If Request Header . . . . . . . . 25 117 B.3.6 Write Locks and COPY/MOVE . . . . . . . . . . . . . . 26 118 B.3.7 Refreshing Write Locks . . . . . . . . . . . . . . . . 26 119 B.4 HTTP Methods for Distributed Authoring . . . . . . . . . . 27 120 B.4.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 27 121 B.5 HTTP Headers for Distributed Authoring . . . . . . . . . . 29 122 B.5.1 Depth Header . . . . . . . . . . . . . . . . . . . . . 29 123 B.5.2 If Header . . . . . . . . . . . . . . . . . . . . . . 29 124 B.5.3 Lock-Token Header . . . . . . . . . . . . . . . . . . 29 125 B.5.4 Timeout Request Header . . . . . . . . . . . . . . . . 30 126 B.6 XML Element Definitions . . . . . . . . . . . . . . . . . 31 127 B.6.1 lockinfo XML Element . . . . . . . . . . . . . . . . . 31 128 C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 129 C.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 31 130 C.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 31 131 C.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 31 132 C.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 32 133 C.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 32 134 C.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 32 135 C.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 32 136 C.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 32 137 D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 32 138 D.1 Node Field Generation Without the IEEE 802 Address . . . . 33 139 E. Change Log (to be removed by RFC Editor before publication) . 35 140 E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 35 141 E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 35 142 F. Resolved issues (to be removed by RFC Editor before 143 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 35 144 F.1 054_IF_AND_AUTH . . . . . . . . . . . . . . . . . . . . . 36 145 F.2 052_LOCK_BODY_SHOULD_BE_MUST . . . . . . . . . . . . . . . 36 146 F.3 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER . . . . . . . . 36 147 F.4 060_LOCK_REFRESH_BODY . . . . . . . . . . . . . . . . . . 37 148 F.5 079_UNLOCK_BY_NON_LOCK_OWNER . . . . . . . . . . . . . . . 37 149 F.6 8.10.1_lockdiscovery_on_failure . . . . . . . . . . . . . 37 150 G. Open issues (to be removed by RFC Editor prior to 151 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 38 152 G.1 import-rfc3253-stuff . . . . . . . . . . . . . . . . . . . 38 153 G.2 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 38 154 G.3 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 155 G.4 008_URI_URL . . . . . . . . . . . . . . . . . . . . . . . 38 156 G.5 040_LOCK_ISSUES_06 . . . . . . . . . . . . . . . . . . . . 39 157 G.6 044_REPORT_OTHER_RESOURCE_LOCKED . . . . . . . . . . . . . 40 158 G.7 056_DEPTH_LOCK_AND_IF . . . . . . . . . . . . . . . . . . 40 159 G.8 057_LOCK_SEMANTICS . . . . . . . . . . . . . . . . . . . . 40 160 G.9 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY . . . . . 41 161 G.10 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . . 41 162 G.11 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED . . . . . . . . . . 42 163 G.12 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 42 164 G.13 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 42 165 G.14 072_LOCK_URL_WITH_NO_PARENT_COLLECTION . . . . . . . . . . 42 166 G.15 065_UNLOCK_WHAT_URL . . . . . . . . . . . . . . . . . . . 43 167 G.16 067_UNLOCK_NEEDS_IF_HEADER . . . . . . . . . . . . . . . . 43 168 G.17 068_UNLOCK_WITHOUT_GOOD_TOKEN . . . . . . . . . . . . . . 44 169 G.18 040_LOCK_ISSUES_08 . . . . . . . . . . . . . . . . . . . . 44 170 G.19 040_LOCK_ISSUES_03 . . . . . . . . . . . . . . . . . . . . 45 171 G.20 040_LOCK_ISSUES_04 . . . . . . . . . . . . . . . . . . . . 46 172 G.21 053_LOCK_INHERITANCE . . . . . . . . . . . . . . . . . . . 46 173 G.22 015_MOVE_SECTION_6.4.1_TO_APPX . . . . . . . . . . . . . . 46 174 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 175 Intellectual Property and Copyright Statements . . . . . . . . 50 177 1. Introduction 179 1.1 Terminology 181 The terminology used here follows and extends that in the WebDAV 182 Distributed Authoring Protocol specification [RFC2518]. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 This document uses XML DTD fragments ([XML]) as a purely notational 189 convention. WebDAV request and response bodies cannot be validated 190 due to the specific extensibility rules defined in section 23 of 191 [RFC2518] and due to the fact that all XML elements defined by this 192 specification use the XML namespace name "DAV:". In particular: 194 o Element names use the "DAV:" namespace. 196 o Element ordering is irrelevant. 198 o Extension elements/attributes (elements/attributes not already 199 defined as valid child elements) may be added anywhere, except 200 when explicitly stated otherwise. 202 1.2 Method Preconditions and Postconditions 204 A "precondition" of a method describes the state on the server that 205 must be true for that method to be performed. A "postcondition" of a 206 method describes the state on the server that must be true after that 207 method has completed. If a method precondition or postcondition for 208 a request is not satisfied and unless a more specific HTTP status 209 code applies, the response status of the request MUST be either 403 210 (Forbidden) if the request should not be repeated because it will 211 always fail, or 409 (Conflict) if it is expected that the user might 212 be able to resolve the conflict and resubmit the request. 214 In order to allow better client handling of error responses, a 215 distinct XML element type is associated with each method precondition 216 and postcondition of a request. When a particular precondition is 217 not satisfied or a particular postcondition cannot be achieved, the 218 appropriate XML element MUST be returned as the child of a top-level 219 DAV:error element in the response body, unless otherwise negotiated 220 by the request. In a 207 Multi-Status response, the DAV:error 221 element would appear in the appropriate DAV:responsedescription 222 element. 224 2. Overview of Locking 226 3. Properties 228 The locking feature introduces the following properties for a 229 resource. 231 3.1 Common XML elements used in property values 233 3.1.1 Lock Scopes 235 236 237 239 3.1.2 Lock Types 241 242 244 At present, this specification only defines one lock type, the write 245 lock. 247 3.2 DAV:lockdiscovery property 249 The DAV:lockdiscovery property returns a listing of who has a lock, 250 what type of lock he has, the timeout type, the time remaining on the 251 timeout, the associated lock token and the root of the lock. The 252 server is free to withhold any or all of this information if the 253 requesting principal does not have sufficient access rights to see 254 the requested data. 256 258 261 depth: the value of the Depth header (see Appendix B.5.1; takes the 262 values "0", "1" or "infinity"). 264 266 owner: provides information about the principal taking out a lock; 267 should be sufficient for either directly contacting a principal (such 268 as a telephone number or email URI), or for discovering the principal 269 (such as the URL of a homepage). 271 273 timeout: the timeout associated with a lock (defined in Appendix 274 B.5.4). 276 278 locktoken: the lock token associated with a lock; the href element 279 contains the lock token. 281 283 lockroot: the URL of the resource that was addressed in the LOCK 284 request; the href element contains the URL of the resource to which 285 the LOCK request has been applied. 287 289 href: defined in [RFC2518], section 12.3. 291 293 3.2.1 Examples for the DAV:lockdiscovery 294 DAV:lockdiscovery property for a resource that has two shared write 295 locks on it, with infinite timeouts: 297 298 299 300 301 0 302 Jane Smith 303 Infinite 304 305 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 307 308 309 http://example.com/container/ 311 312 313 314 315 316 317 318 0 319 John Doe 320 Infinite 321 322 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77 324 325 326 http://example.com/container/ 328 329 330 332 DAV:lockdiscovery property for a resource with no locks on it: 334 336 3.3 DAV:supportedlock property 338 The DAV:supportedlock property of a resource returns a listing of the 339 combinations of scope and access types which may be specified in a 340 lock request on the resource. Note that the actual contents are 341 themselves controlled by access controls so a server is not required 342 to provide information the client is not authorized to see. 344 345 347 3.3.1 Examples for the DAV:supportedlock property 349 DAV:supportedlock property for a resource that supports both 350 exclusive and shares write locks: 352 353 354 355 356 357 358 359 360 361 363 DAV:supportedlock property for a resource that doesn't support any 364 locks at all: 366 368 4. LOCK Method 370 The following sections describe the LOCK method, which is used to 371 take out a lock of any access type or to refresh an existing lock. 373 4.1 Creating Locks 375 [[anchor13: TODO: move method description from appendix --reschke]] 377 4.1.1 Example - Simple Lock Request 379 >>Request 381 LOCK /workspace/webdav/proposal.doc HTTP/1.1 382 Host: example.com 383 Timeout: Infinite, Second-4100000000 384 Content-Type: text/xml; charset="utf-8" 385 Content-Length: xxxx 386 Authorization: Digest username="ejw", 387 realm="ejw@example.com", nonce="...", 388 uri="/workspace/webdav/proposal.doc", 389 response="...", opaque="..." 391 392 393 394 395 396 http://example.org/~ejw/contact.html 397 398 400 >>Response 402 HTTP/1.1 200 OK 403 Lock-Token: 404 Content-Type: text/xml; charset="utf-8" 405 Content-Length: xxxx 407 408 409 410 411 412 413 Infinity 414 415 http://example.org/~ejw/contact.html 417 418 Second-604800 419 420 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 422 423 424 http://example.com/workspace/webdav/proposal.doc 426 427 428 429 431 This example shows the successful creation of an exclusive write lock 432 on resource http://example.com/workspace/webdav/proposal.doc. The 433 resource http:/example.org/~ejw/contact.html contains contact 434 information for the owner of the lock. The server has an 435 activity-based timeout policy in place on this resource, which causes 436 the lock to automatically be removed after 1 week (604800 seconds). 438 4.1.2 Example - Multi-Resource Lock Request 440 >>Request 442 LOCK /webdav/ HTTP/1.1 443 Host: example.com 444 Timeout: Infinite, Second-4100000000 445 Depth: infinity 446 Content-Type: text/xml; charset="utf-8" 447 Content-Length: xxxx 448 Authorization: Digest username="ejw", 449 realm="ejw@example.com", nonce="...", 450 uri="/workspace/webdav/proposal.doc", 451 response="...", opaque="..." 453 454 455 456 457 458 http://example.org/~ejw/contact.html 459 460 462 >>Response 464 HTTP/1.1 207 Multi-Status 465 Content-Type: text/xml; charset="utf-8" 466 Content-Length: xxxx 468 469 470 471 /webdav/secret 472 HTTP/1.1 403 Forbidden 473 474 475 /webdav/ 476 HTTP/1.1 424 Failed Dependency 477 478 480 This example shows a request for an exclusive write lock on a 481 collection and all its children. In this request, the client has 482 specified that it desires an infinite length lock, if available, 483 otherwise a timeout of 4.1 billion seconds, if available. The 484 request entity body contains the contact information for the 485 principal taking out the lock, in this case a web page URL. 487 The error is a 403 (Forbidden) response on the resource 488 http://example.com/webdav/secret. Because this resource could not be 489 locked, none of the resources were locked. 491 4.2 Refreshing Locks 493 A LOCK request with no request body is a "LOCK refresh" request. 494 It's purpose is to restart all timers associated with a lock. 496 If an error is received in response to a refresh LOCK request the 497 client SHOULD assume that the lock was not refreshed. 499 Marshalling: 501 The request MUST include an "If" header that contains the lock 502 tokens of the locks to be refreshed (note there may be multiple in 503 the case of shared locks). 505 The request MAY include a new "Timeout" header to be used as the 506 new timeout value for the lock(s) to be refreshed. 508 The response to a successful lock refresh request MUST contain the 509 value of the current DAV:lockdiscovery property in a prop XML 510 element. 512 Preconditions: 514 (DAV:lock-owner-matches, HTTP status 412): [[anchor16: TODO: 515 describe authenticated-user-must-be-owner-of-lock precondition 516 --reschke]] 518 Postconditions: 520 (DAV:locks-refreshed): Timers associated with the those locks 521 submitted in the "If" request header whose lock root is the 522 resource identified by the request URI MUST be reset to their 523 original value (or alternatively to the new value given in the 524 "Timeout" request header). 526 4.2.1 Example - Refreshing a Write Lock 528 >>Request 530 LOCK /workspace/webdav/proposal.doc HTTP/1.1 531 Host: example.com 532 Timeout: Infinite, Second-4100000000 533 If: () 534 Authorization: Digest username="ejw", 535 realm="ejw@example.com", nonce="...", 536 uri="/workspace/webdav/proposal.doc", 537 response="...", opaque="..." 539 >>Response 541 HTTP/1.1 200 OK 542 Content-Type: text/xml; charset="utf-8" 543 Content-Length: xxxx 545 546 547 548 549 550 551 Infinity 552 553 http://example.org/~ejw/contact.html 555 556 Second-604800 557 558 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 560 561 562 http://example.com/workspace/webdav/proposal.doc 564 565 566 567 569 This request would refresh the lock, resetting any time outs. Notice 570 that the client asked for an infinite time out but the server choose 571 to ignore the request. 573 5. UNLOCK Method 575 The UNLOCK method removes the lock identified by the lock token in 576 the Lock-Token request header from the resource identified by the 577 Request-URI, and all other resources included in the lock. 579 If all resources which have been locked under the submitted lock 580 token can not be unlocked then the UNLOCK request MUST fail. 582 Any DAV compliant resource which supports the LOCK method MUST 583 support the UNLOCK method. 585 A server MAY allow principals other than a lock owner to unlock a 586 resource. In this case, this capability SHOULD be under access 587 control (see [RFC3744], section 3.5). Note that there is a tradeoff 588 in allowing non-owners of a lock to unlock a resource. It can be 589 beneficial to allow non-lock owners to perform UNLOCK requests 590 because it allows the adminstrator of the server to configure the 591 server to grant longer lock timeouts because the administrator knows 592 that there is a process in place to allow users to deal with 593 forgotten locks left by other users. On the other hand, a 594 disadvantage of unlocking someone else's lock is that can create a 595 situation where two users are working on modifications to the same 596 resource at the same time which can result in a client having to 597 perform an merge that wasn't previously planned. 599 Marshalling: 601 The request MUST include a "Lock-Token" header that identifies the 602 lock to be removed. 604 [[anchor18: Specify optional request body? --reschke]] 606 Preconditions: 608 (DAV:lock-token-matches): The lock identified by the "Lock-Token" 609 request header exists, and the resource identified by the request 610 URI indeed is directly locked by the specified lock. 612 (DAV:lock-owner-matches): Unless the server allows other users 613 than the lock owner to unlock a resource, the principal associated 614 with the lock MUST match the principal authenticated for the 615 UNLOCK request. 617 Postconditions: 619 (DAV:lock-removed): The lock MUST have been removed from all 620 resources included in the lock. 622 5.1 Example - UNLOCK 624 >>Request 626 UNLOCK /workspace/webdav/info.doc HTTP/1.1 627 Host: example.com 628 Lock-Token: 629 Authorization: Digest username="ejw", 630 realm="ejw@example.com", nonce="...", 631 uri="/workspace/webdav/proposal.doc", 632 response="...", opaque="..." 634 >>Response 636 HTTP/1.1 204 No Content 638 In this example, the lock identified by the lock token 639 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 640 successfully removed from the resource 641 http://example.com/workspace/webdav/info.doc. If this lock included 642 more than just one resource, the lock is removed from all resources 643 included in the lock. The 204 (No Content) status code is used 644 instead of 200 (OK) because there is no response entity body. 646 6. Additional status codes 648 6.1 423 Locked 650 The 423 (Locked) status code means the source or destination resource 651 of a method is locked. 653 7. Additional method semantics for other Methods 655 8. Capability discovery 657 8.1 OPTIONS method 659 If the server supports locking, it MUST return both the compliance 660 class names "2" and "locking" as fields in the "DAV" response header 661 (see [RFC2518], section 9.1) from an OPTIONS request on any resource 662 implemented by that server. A value of "2" or "locking" in the "DAV" 663 response header MUST indicate that the server meets all class "1" 664 requirements defined in [RFC2518] and supports all MUST level 665 requirements and REQUIRED features specified in this document, 666 including: 668 o LOCK and UNLOCK methods, 669 o DAV:lockdiscovery and DAV:supportedlock properties, 671 o "Time-Out" request header, "Lock-Token" request and response 672 header. 674 Note that for servers implementing this specification, the compliance 675 classes "2" and "locking" are synonymous. However, new clients can 676 take advantage of the new "locking" compliance class to detect server 677 support for changes introduced by this specification (see Appendix 678 A). 680 9. Security considerations 682 All security considerations mentioned in [RFC2518] also apply to this 683 document. Additionally, lock tokens introduce new privacy issues 684 discussed below. 686 9.1 Privacy Issues Connected to Locks 688 When submitting a lock request a user agent may also submit an owner 689 XML field giving contact information for the person taking out the 690 lock (for those cases where a person, rather than a robot, is taking 691 out the lock). This contact information is stored in a 692 DAV:lockdiscovery property on the resource, and can be used by other 693 collaborators to begin negotiation over access to the resource. 694 However, in many cases this contact information can be very private, 695 and should not be widely disseminated. Servers SHOULD limit read 696 access to the DAV:lockdiscovery property as appropriate. 697 Furthermore, user agents SHOULD provide control over whether contact 698 information is sent at all, and if contact information is sent, 699 control over exactly what information is sent. 701 10. Internationalization Considerations 703 All internationalization considerations mentioned in [RFC2518] also 704 apply to this document. 706 11. IANA Considerations 708 This specification updates the definition of the "opaquelocktoken" 709 URI scheme described in Appendix D, registered my means of [RFC2518], 710 section 6.4. There are no additional IANA considerations. 712 12. Acknowledgements 714 This document is the collaborative product of 716 o the authors, 717 o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault 718 - and 720 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron 721 Goland, Del Jensen and Jim Whitehead. 723 This document has also benefited from thoughtful discussion by Mark 724 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, 725 Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias 726 Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV 727 working group. 729 13. References 731 13.1 Normative References 733 [ISO-11578] 734 International Organization for Standardization, "ISO/IEC 735 11578:1996. Information technology - Open Systems 736 Interconnection - Remote Procedure Call (RPC)", 1996. 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 742 Resource Identifiers (URI): Generic Syntax", RFC 2396, 743 August 1998. 745 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 746 Jensen, "HTTP Extensions for Distributed Authoring -- 747 WEBDAV", RFC 2518, February 1999. 749 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 750 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 751 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 753 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 754 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 755 Edition)", W3C REC-xml-20040204, February 2004, 756 . 758 13.2 Informative References 760 [RFC3744] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web 761 Distributed Authoring and Versioning (WebDAV) Access 762 Control Protocol", RFC 3744, May 2004. 764 URIs 766 [1] 768 [2] 770 Author's Address 772 Julian F. Reschke 773 greenbytes GmbH 774 Salzmannstrasse 152 775 Muenster, NW 48159 776 Germany 778 Phone: +49 251 2807760 779 Fax: +49 251 2807761 780 EMail: julian.reschke@greenbytes.de 781 URI: http://greenbytes.de/tech/webdav/ 783 Appendix A. Changes to RFC2518 785 See Section 8 for a description about how clients can discover 786 support for this version of the WebDAV Locking protocol. 788 A.1 Removed/Deprecated features 790 A.1.1 Implicit lock refresh 792 In section 9.8, [RFC2518] specifies that locks should be refreshed 793 implicitly every time "...any time an owner of the lock sends a 794 method to any member of the lock, including unsupported methods, or 795 methods which are unsuccessful." This features has been removed 796 (locks need to be refreshed explicitly using the LOCK method). 798 Compatibility considerations 800 Clients historically have never relied on this feature as it was 801 never implemented in widely deployed WebDAV servers. 803 A.1.2 Lock-null resources 805 In section 7.4, [RFC2518] specifies a special resource type called 806 "lock-null resource" that's being created when a LOCK method request 807 is applied to a null resource. In practice, no real interoperability 808 was achieved because many servers failed to implement this feature 809 properly and few clients (if any) ever relied on that particular 810 functionality. 812 Removing this feature also means that there is no atomic way to 813 create a collection in locked state, but in practice, this doesn't 814 seem to be a problem. 816 Compatibility considerations 818 There do not seem to be any widely deployed clients that actually 819 relied on "lock-null resources". 821 A.2 Additional features 823 A.2.1 DAV:lockroot element in DAV:activelock 825 Clients can take advantage of the new DAV:lockroot element to 826 discover the URL to which the LOCK request (that created the lock) 827 was applied. 829 Compatibility consideration 831 Clients will have to fail gracefully when communicating with older 832 servers that do not support the new property. 834 Appendix B. Text to be integrated from RFC2518 836 B.1 Introduction 838 Locking: The ability to keep more than one person from working on a 839 document at the same time. This prevents the "lost update problem," 840 in which modifications are lost as first one author then another 841 writes changes without merging the other author's changes. 843 B.2 Locking 845 The ability to lock a resource provides a mechanism for serializing 846 access to that resource. Using a lock, an authoring client can 847 provide a reasonable guarantee that another principal will not modify 848 a resource while it is being edited. In this way, a client can 849 prevent the "lost update" problem. 851 This specification allows locks to vary over two client-specified 852 parameters, the number of principals involved (exclusive vs. shared) 853 and the type of access to be granted. This document defines locking 854 for only one access type, write. However, the syntax is extensible, 855 and permits the eventual specification of locking for other access 856 types. 858 B.2.1 Exclusive Vs. Shared Locks 860 The most basic form of lock is an exclusive lock. This is a lock 861 where the access right in question is only granted to a single 862 principal. The need for this arbitration results from a desire to 863 avoid having to merge results. 865 However, there are times when the goal of a lock is not to exclude 866 others from exercising an access right but rather to provide a 867 mechanism for principals to indicate that they intend to exercise 868 their access rights. Shared locks are provided for this case. A 869 shared lock allows multiple principals to receive a lock. Hence any 870 principal with appropriate access can get the lock. 872 With shared locks there are two trust sets that affect a resource. 873 The first trust set is created by access permissions. Principals who 874 are trusted, for example, may have permission to write to the 875 resource. Among those who have access permission to write to the 876 resource, the set of principals who have taken out a shared lock also 877 must trust each other, creating a (typically) smaller trust set 878 within the access permission write set. 880 Starting with every possible principal on the Internet, in most 881 situations the vast majority of these principals will not have write 882 access to a given resource. Of the small number who do have write 883 access, some principals may decide to guarantee their edits are free 884 from overwrite conflicts by using exclusive write locks. Others may 885 decide they trust their collaborators will not overwrite their work 886 (the potential set of collaborators being the set of principals who 887 have write permission) and use a shared lock, which informs their 888 collaborators that a principal may be working on the resource. 890 The WebDAV extensions to HTTP do not need to provide all of the 891 communications paths necessary for principals to coordinate their 892 activities. When using shared locks, principals may use any out of 893 band communication channel to coordinate their work (e.g., 894 face-to-face interaction, written notes, post-it notes on the screen, 895 telephone conversation, Email, etc.) The intent of a shared lock is 896 to let collaborators know who else may be working on a resource. 898 Shared locks are included because experience from web distributed 899 authoring systems has indicated that exclusive locks are often too 900 rigid. An exclusive lock is used to enforce a particular editing 901 process: take out an exclusive lock, read the resource, perform 902 edits, write the resource, release the lock. This editing process 903 has the problem that locks are not always properly released, for 904 example when a program crashes, or when a lock owner leaves without 905 unlocking a resource. While both timeouts and administrative action 906 can be used to remove an offending lock, neither mechanism may be 907 available when needed; the timeout may be long or the administrator 908 may not be available. 910 B.2.2 Required Support 912 A WebDAV compliant server is not required to support locking in any 913 form. If the server does support locking it may choose to support 914 any combination of exclusive and shared locks for any access types. 916 The reason for this flexibility is that locking policy strikes to the 917 very heart of the resource management and versioning systems employed 918 by various storage repositories. These repositories require control 919 over what sort of locking will be made available. For example, some 920 repositories only support shared write locks while others only 921 provide support for exclusive write locks while yet others use no 922 locking at all. As each system is sufficiently different to merit 923 exclusion of certain locking features, this specification leaves 924 locking as the sole axis of negotiation within WebDAV. 926 B.2.3 Lock Tokens 928 A lock token is a type of state token, represented as a URI, which 929 identifies a particular lock. A lock token is returned by every 930 successful LOCK operation in the DAV:lockdiscovery property in the 931 response body, and can also be found through lock discovery on a 932 resource. 934 Lock token URIs MUST be unique across all resources for all time. 935 This uniqueness constraint allows lock tokens to be submitted across 936 resources and servers without fear of confusion. 938 This specification provides a lock token URI scheme called 939 "opaquelocktoken" that meets the uniqueness requirements. However 940 resources are free to return any URI scheme so long as it meets the 941 uniqueness requirements. 943 Submitting a lock token provides no special access rights. Anyone 944 can find out anyone else's lock token by performing lock discovery. 945 Locks MUST be enforced based upon whatever authentication mechanism 946 is used by the server, not based on the secrecy of the token values. 948 B.2.4 Lock Capability Discovery 950 Since server lock support is optional, a client trying to lock a 951 resource on a server can either try the lock and hope for the best, 952 or perform some form of discovery to determine what lock capabilities 953 the server supports. This is known as lock capability discovery. 955 Lock capability discovery differs from discovery of supported access 956 control types, since there may be access control types without 957 corresponding lock types. A client can determine what lock types the 958 server supports by retrieving the DAV:supportedlock property. 960 Any DAV compliant resource that supports the LOCK method MUST support 961 the DAV:supportedlock property. 963 B.2.5 Active Lock Discovery 965 If another principal locks a resource that a principal wishes to 966 access, it is useful for the second principal to be able to find out 967 who the first principal is. For this purpose the DAV:lockdiscovery 968 property is provided. This property lists all outstanding locks, 969 describes their type, and where available, provides their lock token. 971 Any DAV compliant resource that supports the LOCK method MUST support 972 the DAV:lockdiscovery property. 974 B.2.6 Usage Considerations 976 Although the locking mechanisms specified here provide some help in 977 preventing lost updates, they cannot guarantee that updates will 978 never be lost. Consider the following scenario: 980 o Two clients A and B are interested in editing the resource 981 'index.html'. Client A is an HTTP client rather than a WebDAV 982 client, and so does not know how to perform locking. 984 o Client A doesn't lock the document, but does a GET and begins 985 editing. 987 o Client B does LOCK, performs a GET and begins editing. 989 o Client B finishes editing, performs a PUT, then an UNLOCK. 991 o Client A performs a PUT, overwriting and losing all of B's 992 changes. 994 There are several reasons why the WebDAV protocol itself cannot 995 prevent this situation. First, it cannot force all clients to use 996 locking because it must be compatible with HTTP clients that do not 997 comprehend locking. Second, it cannot require servers to support 998 locking because of the variety of repository implementations, some of 999 which rely on reservations and merging rather than on locking. 1000 Finally, being stateless, it cannot enforce a sequence of operations 1001 like LOCK / GET / PUT / UNLOCK. 1003 WebDAV servers that support locking can reduce the likelihood that 1004 clients will accidentally overwrite each other's changes by requiring 1005 clients to lock resources before modifying them. Such servers would 1006 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying 1007 resources. 1009 WebDAV clients can be good citizens by using a lock / retrieve / 1010 write /unlock sequence of operations (at least by default) whenever 1011 they interact with a WebDAV server that supports locking. 1013 HTTP 1.1 clients can be good citizens, avoiding overwriting other 1014 clients' changes, by using entity tags in If-Match headers with any 1015 requests that would modify resources. 1017 Information managers may attempt to prevent overwrites by 1018 implementing client-side procedures requiring locking before 1019 modifying WebDAV resources. 1021 B.3 Write Lock 1023 This section describes the semantics specific to the write lock type. 1024 The write lock is a specific instance of a lock type, and is the only 1025 lock type described in this specification. 1027 B.3.1 Methods Restricted by Write Locks 1029 A write lock MUST prevent a principal without the lock from 1030 successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, 1031 DELETE, or MKCOL on the locked resource. All other current methods, 1032 GET in particular, function independently of the lock. 1034 Note, however, that as new methods are created it will be necessary 1035 to specify how they interact with a write lock. 1037 B.3.2 Write Locks and Lock Tokens 1039 A successful request for an exclusive or shared write lock MUST 1040 result in the generation of a unique lock token associated with the 1041 requesting principal. Thus if five principals have a shared write 1042 lock on the same resource there will be five lock tokens, one for 1043 each principal. 1045 B.3.3 Write Locks and Properties 1047 While those without a write lock may not alter a property on a 1048 resource it is still possible for the values of live properties to 1049 change, even while locked, due to the requirements of their schemas. 1050 Only dead properties and live properties defined to respect locks are 1051 guaranteed not to change while write locked. 1053 B.3.4 Write Locks and Collections 1055 A write lock on a collection, whether created by a "Depth: 0" or 1056 "Depth: infinity" lock request, prevents the addition or removal of 1057 member URIs of the collection by non-lock owners. As a consequence, 1058 when a principal issues a PUT or POST request to create a new 1059 resource under a URI which needs to be an internal member of a write 1060 locked collection to maintain HTTP namespace consistency, or issues a 1061 DELETE to remove a resource which has a URI which is an existing 1062 internal member URI of a write locked collection, this request MUST 1063 fail if the principal does not have a write lock on the collection. 1065 However, if a write lock request is issued to a collection containing 1066 member URIs identifying resources that are currently locked in a 1067 manner which conflicts with the write lock, the request MUST fail 1068 with a 423 (Locked) status code. 1070 If a lock owner causes the URI of a resource to be added as an 1071 internal member URI of a locked collection then the new resource MUST 1072 be automatically added to the lock. This is the only mechanism that 1073 allows a resource to be added to a write lock. Thus, for example, if 1074 the collection /a/b/ is write locked and the resource /c is moved to 1075 /a/b/c then resource /a/b/c will be added to the write lock. 1077 B.3.5 Write Locks and the If Request Header 1079 If a user agent is not required to have knowledge about a lock when 1080 requesting an operation on a locked resource, the following scenario 1081 might occur. Program A, run by User A, takes out a write lock on a 1082 resource. Program B, also run by User A, has no knowledge of the 1083 lock taken out by Program A, yet performs a PUT to the locked 1084 resource. In this scenario, the PUT succeeds because locks are 1085 associated with a principal, not a program, and thus program B, 1086 because it is acting with principal A's credential, is allowed to 1087 perform the PUT. However, had program B known about the lock, it 1088 would not have overwritten the resource, preferring instead to 1089 present a dialog box describing the conflict to the user. Due to 1090 this scenario, a mechanism is needed to prevent different programs 1091 from accidentally ignoring locks taken out by other programs with the 1092 same authorization. 1094 In order to prevent these collisions a lock token MUST be submitted 1095 by an authorized principal in the If header for all locked resources 1096 that a method may interact with or the method MUST fail. For 1097 example, if a resource is to be moved and both the source and 1098 destination are locked then two lock tokens must be submitted, one 1099 for the source and the other for the destination. 1101 B.3.5.1 Example - Write Lock 1103 >>Request 1105 COPY /~fielding/index.html HTTP/1.1 1106 Host: example.com 1107 Destination: http://example.com/users/f/fielding/index.html 1108 If: 1109 () 1111 >>Response 1113 HTTP/1.1 204 No Content 1115 In this example, even though both the source and destination are 1116 locked, only one lock token must be submitted, for the lock on the 1117 destination. This is because the source resource is not modified by 1118 a COPY, and hence unaffected by the write lock. In this example, 1119 user agent authentication has previously occurred via a mechanism 1120 outside the scope of the HTTP protocol, in the underlying transport 1121 layer. 1123 B.3.6 Write Locks and COPY/MOVE 1125 A COPY method invocation MUST NOT duplicate any write locks active on 1126 the source. However, as previously noted, if the COPY copies the 1127 resource into a collection that is locked with "Depth: infinity", 1128 then the resource will be added to the lock. 1130 A successful MOVE request on a write locked resource MUST NOT move 1131 the write lock with the resource. However, the resource is subject 1132 to being added to an existing lock at the destination, as specified 1133 in Appendix B.3.4. For example, if the MOVE makes the resource a 1134 child of a collection that is locked with "Depth: infinity", then the 1135 resource will be added to that collection's lock. Additionally, if a 1136 resource locked with "Depth: infinity" is moved to a destination that 1137 is within the scope of the same lock (e.g., within the namespace tree 1138 covered by the lock), the moved resource will again be a added to the 1139 lock. In both these examples, as specified in Appendix B.3.5, an If 1140 header must be submitted containing a lock token for both the source 1141 and destination. 1143 B.3.7 Refreshing Write Locks 1145 [[anchor45: Just state that locks can be refreshed and point to 1146 actual method description. --reschke]] 1148 B.4 HTTP Methods for Distributed Authoring 1150 B.4.1 LOCK Method 1152 B.4.1.1 Operation 1154 [[anchor49: Make sure updated method description discusses applying 1155 LOCK to null resources. --reschke]] 1157 A LOCK method invocation creates the lock specified by the lockinfo 1158 XML element on the resource identified by the Request-URI. Lock 1159 method requests SHOULD have a XML request body which contains an 1160 owner XML element for this lock request, unless this is a refresh 1161 request. The LOCK request may have a Timeout header. 1163 Clients MUST assume that locks may arbitrarily disappear at any time, 1164 regardless of the value given in the Timeout header. The Timeout 1165 header only indicates the behavior of the server if "extraordinary" 1166 circumstances do not occur. For example, an administrator may remove 1167 a lock at any time or the system may crash in such a way that it 1168 loses the record of the lock's existence. The response for a 1169 successful LOCK creation request MUST contain the value of the 1170 DAV:lockdiscovery property in a prop XML element. 1172 In order to indicate the lock token associated with a newly created 1173 lock, a Lock-Token response header MUST be included in the response 1174 for every successful LOCK request for a new lock. Note that the 1175 Lock-Token header would not be returned in the response for a 1176 successful refresh LOCK request because a new lock was not created. 1178 B.4.1.2 The Effect of Locks on Properties and Collections 1180 The scope of a lock is the entire state of the resource, including 1181 its body and associated properties. As a result, a lock on a 1182 resource MUST also lock the resource's properties. 1184 For collections, a lock also affects the ability to add or remove 1185 members. The nature of the effect depends upon the type of access 1186 control involved. 1188 B.4.1.3 Locking Replicated Resources 1190 A resource may be made available through more than one URI. However 1191 locks apply to resources, not URIs. Therefore a LOCK request on a 1192 resource MUST NOT succeed if can not be honored by all the URIs 1193 through which the resource is addressable. 1195 B.4.1.4 Depth and Locking 1197 The Depth header may be used with the LOCK method. Values other than 1198 0 or infinity MUST NOT be used with the Depth header on a LOCK 1199 method. All resources that support the LOCK method MUST support the 1200 Depth header. 1202 A Depth header of value 0 means to just lock the resource specified 1203 by the Request-URI. 1205 If the Depth header is set to infinity then the resource specified in 1206 the Request-URI along with all its internal members, all the way down 1207 the hierarchy, are to be locked. A successful result MUST return a 1208 single lock token which represents all the resources that have been 1209 locked. If an UNLOCK is successfully executed on this token, all 1210 associated resources are unlocked. If the lock cannot be granted to 1211 all resources, a 207 (Multistatus) status code MUST be returned with 1212 a response entity body containing a multistatus XML element 1213 describing which resource(s) prevented the lock from being granted. 1214 Hence, partial success is not an option. Either the entire hierarchy 1215 is locked or no resources are locked. 1217 If no Depth header is submitted on a LOCK request then the request 1218 MUST act as if a "Depth:infinity" had been submitted. 1220 B.4.1.5 Interaction with other Methods 1222 The interaction of a LOCK with various methods is dependent upon the 1223 lock type. However, independent of lock type, a successful DELETE of 1224 a resource MUST cause all of its locks to be removed. 1226 B.4.1.6 Lock Compatibility Table 1228 The table below describes the behavior that occurs when a lock 1229 request is made on a resource. 1231 +-------------------------+--------------------+--------------------+ 1232 | Current lock state / | Shared Lock | Exclusive Lock | 1233 | Lock request | | | 1234 +-------------------------+--------------------+--------------------+ 1235 | None | True | True | 1236 | Shared Lock | True | False | 1237 | Exclusive Lock | False | False* | 1238 +-------------------------+--------------------+--------------------+ 1240 Legend: True = lock may be granted. False = lock MUST NOT be 1241 granted. *=It is illegal for a principal to request the same lock 1242 twice. 1244 The current lock state of a resource is given in the leftmost column, 1245 and lock requests are listed in the first row. The intersection of a 1246 row and column gives the result of a lock request. For example, if a 1247 shared lock is held on a resource, and an exclusive lock is 1248 requested, the table entry is "false", indicating the lock must not 1249 be granted. 1251 B.4.1.7 Status Codes 1253 200 (OK) - The lock request succeeded and the value of the 1254 DAV:lockdiscovery property is included in the body. 1256 412 (Precondition Failed) - The included lock token was not 1257 enforceable on this resource or the server could not satisfy the 1258 request in the lockinfo XML element. 1260 423 (Locked) - The resource is locked, so the method has been 1261 rejected. 1263 B.5 HTTP Headers for Distributed Authoring 1265 B.5.1 Depth Header 1267 [[anchor56: Add "Depth" header considerations: --reschke]] 1269 If a resource, source or destination, within the scope of the method 1270 with a Depth header is locked in such a way as to prevent the 1271 successful execution of the method, then the lock token for that 1272 resource MUST be submitted with the request in the If request header. 1274 B.5.2 If Header 1276 [[anchor57: Add "If" header considerations: --reschke]] 1278 B.5.3 Lock-Token Header 1280 Lock-Token = "Lock-Token" ":" Coded-URL 1282 The Lock-Token request header is used with the UNLOCK method to 1283 identify the lock to be removed. The lock token in the Lock-Token 1284 request header MUST identify a lock that contains the resource 1285 identified by Request-URI as a member. 1287 The Lock-Token response header is used with the LOCK method to 1288 indicate the lock token created as a result of a successful LOCK 1289 request to create a new lock. 1291 B.5.4 Timeout Request Header 1293 TimeOut = "Timeout" ":" 1#TimeType 1294 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) 1295 DAVTimeOutVal = 1*digit 1296 Other = "Extend" field-value ; See section 4.2 of [RFC2616] 1298 [[anchor58: Discussion of timeout behaviour should move somewhere 1299 else. Keep only the actual syntax description here. --reschke]] 1300 Clients may include Timeout headers in their LOCK requests. However, 1301 the server is not required to honor or even consider these requests. 1302 Clients MUST NOT submit a Timeout request header with any method 1303 other than a LOCK method. 1305 A Timeout request header MUST contain at least one TimeType and may 1306 contain multiple TimeType entries. The purpose of listing multiple 1307 TimeType entries is to indicate multiple different values and value 1308 types that are acceptable to the client. The client lists the 1309 TimeType entries in order of preference. 1311 Timeout response values MUST use a Second value, Infinite, or a 1312 TimeType the client has indicated familiarity with. The server may 1313 assume a client is familiar with any TimeType submitted in a Timeout 1314 header. 1316 The "Second" TimeType specifies the number of seconds that will 1317 elapse between granting of the lock at the server, and the automatic 1318 removal of the lock. The timeout value for TimeType "Second" MUST 1319 NOT be greater than 2^32-1. 1321 If the timeout expires then the lock may be lost. Specifically, if 1322 the server wishes to harvest the lock upon time-out, the server 1323 SHOULD act as if an UNLOCK method was executed by the server on the 1324 resource using the lock token of the timed-out lock, performed with 1325 its override authority. Thus logs should be updated with the 1326 disposition of the lock, notifications should be sent, etc., just as 1327 they would be for an UNLOCK request. 1329 Servers are advised to pay close attention to the values submitted by 1330 clients, as they will be indicative of the type of activity the 1331 client intends to perform. For example, an applet running in a 1332 browser may need to lock a resource, but because of the instability 1333 of the environment within which the applet is running, the applet may 1334 be turned off without warning. As a result, the applet is likely to 1335 ask for a relatively small timeout value so that if the applet dies, 1336 the lock can be quickly harvested. However, a document management 1337 system is likely to ask for an extremely long timeout because its 1338 user may be planning on going off-line. 1340 A client MUST NOT assume that just because the time-out has expired 1341 the lock has been lost. 1343 B.6 XML Element Definitions 1345 B.6.1 lockinfo XML Element 1347 Name: lockinfo 1349 Namespace: DAV: 1351 Purpose: The lockinfo XML element is used with a LOCK method to 1352 specify the type of lock the client wishes to have created. 1354 1356 Appendix C. GULP 1358 *Copied from 1359 * 1360 . 1362 C.1 Directly vs Indirectly 1364 A lock either directly or indirectly locks a resource. 1366 C.2 Creating Locks 1368 A LOCK request with a non-empty body creates a new lock, and the 1369 resource identified by the request-URL is directly locked by that 1370 lock. The "lock-root" of the new lock is the request-URL. If at the 1371 time of the request, the request-URL is not mapped to a resource, a 1372 new resource with no content MUST be created by the request. 1374 C.3 Lock Inheritance 1376 If a collection is directly locked by a depth:infinity lock, all 1377 members of that collection (other than the collection itself) are 1378 indirectly locked by that lock. In particular, if an internal member 1379 resource is added to a collection that is locked by a depth:infinity 1380 lock, and if the resource is not locked by that lock, then the 1381 resource becomes indirectly locked by that lock. Conversely, if a 1382 resource is indirectly locked with a depth:infinity lock, and if the 1383 result of deleting an internal member URI is that the resource is no 1384 longer a member of the collection that is directly locked by that 1385 lock, then the resource is no longer locked by that lock. 1387 C.4 Removing Locks 1389 An UNLOCK request deletes the lock with the specified lock token. 1390 The request-URL of the request MUST identify the resource that is 1391 directly locked by that lock. After a lock is deleted, no resource 1392 is locked by that lock. 1394 C.5 Submitting Lock Tokens 1396 A lock token is "submitted" in a request when it appears in an "If" 1397 request header. 1399 C.6 Locked State 1401 If a request would modify the content for a locked resource, a dead 1402 property of a locked resource, a live property that is defined to be 1403 lockable for a locked resource, or an internal member URI of a locked 1404 collection, the request MUST fail unless the lock-token for that lock 1405 is submitted in the request. An internal member URI of a collection 1406 is considered to be modified if it is added, removed, or identifies a 1407 different resource. 1409 C.7 URL protection 1411 If a request causes a directly locked resource to no longer be mapped 1412 to the lock-root of that lock, then the request MUST fail unless the 1413 lock-token for that lock is submitted in the request. If the request 1414 succeeds, then that lock MUST have been deleted by that request. 1416 C.8 Exclusive vs Shared 1418 If a request would cause a resource to be locked by two different 1419 exclusive locks, the request MUST fail. 1421 Appendix D. 'opaquelocktoken' URI Scheme 1423 The opaquelocktoken URI scheme is designed to be unique across all 1424 resources for all time. Due to this uniqueness quality, a client may 1425 submit an opaque lock token in an If header on a resource other than 1426 the one that returned it. 1428 All resources MUST recognize the opaquelocktoken scheme and, at 1429 minimum, recognize that the lock token does not refer to an 1430 outstanding lock on the resource. 1432 In order to guarantee uniqueness across all resources for all time 1433 the opaquelocktoken requires the use of the Universal Unique 1434 Identifier (UUID) mechanism, as described in [ISO-11578]. 1436 Opaquelocktoken generators, however, have a choice of how they create 1437 these tokens. They can either generate a new UUID for every lock 1438 token they create or they can create a single UUID and then add 1439 extension characters. If the second method is selected then the 1440 program generating the extensions MUST guarantee that the same 1441 extension will never be used twice with the associated UUID. 1443 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID 1444 production is the string representation of a UUID, as defined in 1445 [ISO-11578]. Note that white space (LWS) is not allowed between 1446 elements of this production. 1448 Extension = path ; path is defined in [RFC2396], section 3.3. 1450 D.1 Node Field Generation Without the IEEE 802 Address 1452 UUIDs, as defined in [ISO-11578], contain a "node" field that 1453 contains one of the IEEE 802 addresses for the server machine. As 1454 noted in Section 9.1, there are several security risks associated 1455 with exposing a machine's IEEE 802 address. This section provides an 1456 alternate mechanism for generating the "node" field of a UUID which 1457 does not employ an IEEE 802 address. WebDAV servers MAY use this 1458 algorithm for creating the node field when generating UUIDs. The 1459 text in this section is originally from an Internet-Draft by Paul 1460 Leach and Rich Salz, who are noted here to properly attribute their 1461 work. 1463 The ideal solution is to obtain a 47 bit cryptographic quality random 1464 number, and use it as the low 47 bits of the node ID, with the most 1465 significant bit of the first octet of the node ID set to 1. This bit 1466 is the unicast/multicast bit, which will never be set in IEEE 802 1467 addresses obtained from network cards; hence, there can never be a 1468 conflict between UUIDs generated by machines with and without network 1469 cards. 1471 If a system does not have a primitive to generate cryptographic 1472 quality random numbers, then in most systems there are usually a 1473 fairly large number of sources of randomness available from which one 1474 can be generated. Such sources are system specific, but often 1475 include: 1477 o the percent of memory in use 1479 o the size of main memory in bytes 1481 o the amount of free main memory in bytes 1483 o the size of the paging or swap file in bytes 1484 o free bytes of paging or swap file 1486 o the total size of user virtual address space in bytes 1488 o the total available user address space bytes 1490 o the size of boot disk drive in bytes 1492 o the free disk space on boot drive in bytes 1494 o the current time 1496 o the amount of time since the system booted 1498 o the individual sizes of files in various system directories 1500 o the creation, last read, and modification times of files in 1501 various system directories 1503 o the utilization factors of various system resources (heap, etc.) 1505 o current mouse cursor position 1507 o current caret position 1509 o current number of running processes, threads 1511 o handles or IDs of the desktop window and the active window 1513 o the value of stack pointer of the caller 1515 o the process and thread ID of caller 1517 o various processor architecture specific performance counters 1518 (instructions executed, cache misses, TLB misses) 1520 (Note that it is precisely the above kinds of sources of randomness 1521 that are used to seed cryptographic quality random number generators 1522 on systems without special hardware for their construction.) 1524 In addition, items such as the computer's name and the name of the 1525 operating system, while not strictly speaking random, will help 1526 differentiate the results from those obtained by other systems. 1528 The exact algorithm to generate a node ID using these data is system 1529 specific, because both the data available and the functions to obtain 1530 them are often very system specific. However, assuming that one can 1531 concatenate all the values from the randomness sources into a buffer, 1532 and that a cryptographic hash function such as MD5 is available, then 1533 any 6 bytes of the MD5 hash of the buffer, with the multicast bit 1534 (the high bit of the first byte) set will be an appropriately random 1535 node ID. 1537 Other hash functions, such as SHA-1, can also be used. The only 1538 requirement is that the result be suitably random in the sense that 1539 the outputs from a set uniformly distributed inputs are themselves 1540 uniformly distributed, and that a single bit change in the input can 1541 be expected to cause half of the output bits to change. 1543 Appendix E. Change Log (to be removed by RFC Editor before publication) 1545 E.1 Since draft-reschke-webdav-locking-00 1547 Add and resolve issue "rfc2606-compliance". Resolve issues 1548 "extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL", 1549 "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS", 1550 "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02", 1551 "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL", 1552 "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION", 1553 "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC", 1554 "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK", 1555 "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS", 1556 "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and 1557 "111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work 1558 on moving text from RFC2518 excerpts into new sections. Define new 1559 compliance class "locking" (similar to "bis" in RFC2518bis, but only 1560 relevant to locking). Reformatted "GULP" into separate subsections 1561 for easier reference. 1563 E.2 Since draft-reschke-webdav-locking-01 1565 Update "008_URI_URL", "040_LOCK_ISSUES_06", 1566 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY", 1567 "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN". 1568 Re-opened "065_UNLOCK_WHAT_URL". Close 1569 "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK 1570 refresh method descriptions. Fix page title (TXT version). Close 1571 "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH", 1572 "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and 1573 resolve "8.10.1_lockdiscovery_on_failure". Started attempt to 1574 clarify status code. 1576 Appendix F. Resolved issues (to be removed by RFC Editor before 1577 publication) 1579 Issues that were either rejected or resolved in this version of this 1580 document. 1582 F.1 054_IF_AND_AUTH 1584 Type: change 1586 1588 geoffrey.clemm@rational.com (2000-01-27): The fact that use of 1589 authentication credentials with submission of lock tokens is required 1590 should be strengthened in the document. 1592 julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token 1593 in an If header (usages != UNLOCK) SHOULD be restricted to whatever 1594 the server thinks the "owner" of the lock is. 1596 Resolution (2004-06-06): Duplicate of 057_LOCK_SEMANTICS. 1598 F.2 052_LOCK_BODY_SHOULD_BE_MUST 1600 Type: change 1602 1604 gstein@lyra.org (1999-11-23): Section 8.10.1 states that a LOCK 1605 method request SHOULD have an XML request body. This SHOULD should 1606 instead be MUST. 1608 julian.reschke@greenbytes.de (2004-04-25): Clarify that for creating 1609 LOCKs, it MUST have a request body which SHOULD have the DAV:owner 1610 element. For LOCK refreshes, no body is required. 1612 Resolution (2004-06-01): Clarify that LOCK refresh MUST NOT have a 1613 request body. Also clarify Lock-Token header vs If header. See 1614 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0124.html. 1616 F.3 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER 1618 Type: change 1620 1622 dbrotsky@Adobe.COM (): The LOCK renewal request should not us an IF 1623 header to specify what lock is being renewed. This limits the use of 1624 the IF header. 1626 Resolution (2004-06-04): Rejected. See also 1627 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY 1629 F.4 060_LOCK_REFRESH_BODY 1631 Type: change 1633 1635 rickard.falk@excosoft.se (2000-07-11): Section 7.8 of RFC 2518 1636 indicates that clients may submit a lock refresh without a body. 1637 However, it implies that clients could submit a lock refresh with a 1638 body. Server implementations have been disallowing a lock refresh 1639 with a body. It might make sense to codify this practice, and 1640 disallow submission of a body on a lock refresh. 1642 Resolution (2004-06-01): Clarify that LOCK refresh MUST NOT have a 1643 request body. Also clarify Lock-Token header vs If header. See 1644 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0124.html. 1646 F.5 079_UNLOCK_BY_NON_LOCK_OWNER 1648 Type: change 1650 lisa@xythos.com (): At present, the specification is not explicit 1651 about who might be capable of grabbing a lock token via lock 1652 discovery and the submitting it in UNLOCK (and/or for a subsequent 1653 write operation). It is OK for the resource owner to grab the lock 1654 token and do UNLOCK/write? Is it OK to have a "grab lock token" 1655 privilege that can be assigned to anyone? 1657 Resolution (2004-06-06): Resolved in part by putting it under ACL 1658 control: 1659 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html 1660 and the response that follows it. 1662 F.6 8.10.1_lockdiscovery_on_failure 1664 Type: change 1666 1668 julian.reschke@greenbytes.de (2004-06-04): Returning 1669 DAV:lockdiscovery on error seems to be (a) useless and (b) 1670 underspecified (the example given in section 8.10.10 isn't compliant 1671 to the multstatus response format). 1673 Resolution (2004-06-08): Specify returning DAV:lockdiscovery just 1674 upon success. Fix example (will use precondition names when they are 1675 defined). 1677 Appendix G. Open issues (to be removed by RFC Editor prior to 1678 publication) 1680 G.1 import-rfc3253-stuff 1682 Type: change 1684 julian.reschke@greenbytes.de (2004-04-25): Import error marshalling 1685 and terminology from RFC3253. 1687 G.2 import-gulp 1689 Type: change 1691 julian.reschke@greenbytes.de (2004-05-25): Make specification text 1692 compatible with GULP where it isn't. Integrate GULP as normative 1693 specification of the locking behaviour. 1695 G.3 edit 1697 Type: edit 1699 julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for 1700 editorial fixes/enhancements. 1702 G.4 008_URI_URL 1704 Type: change 1706 1708 masinter@parc.xerox.com (1998-11-09): Perform a thorough review of 1709 the specification to ensure that URI and URL are used correctly, and 1710 consistently throughout. 1712 julian.reschke@greenbytes.de (2004-06-04): Use "request URI" when 1713 talking particularily about HTTP messages because this is the term 1714 used by RFC2616. Use "URL" when talking about HTTP/WebDAV resources. 1715 Otherwise use URI, making sure that if a relativeURI (as defined by 1716 RFC2396) is allowed, we say so. 1718 Resolution: Seems to have been deferred: 1719 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html, 1720 but there is some follow on discussion on what exactly needs to be 1721 clarified: 1722 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html, 1723 but no specific action was concluded besides the fact that we don't 1724 need to wait for RFC2396 to be updated or request any changes/ 1725 clarifications to that. 1727 G.5 040_LOCK_ISSUES_06 1729 Type: change 1731 1733 ccjason@us.ibm.com (1999-06-07): Upon cursory reading of the rfc 2518 1734 sec 8.10.4 through 8.11 I was confused by the plethoria of error 1735 codes. Nothing seems to unify them. 8.10.4 speaks of a return code 1736 of 409 Conflict if a lock can't be granted. - Firstly, I can't tell 1737 if it is saying that the 409 is within the multistatus body... or in 1738 the response header. - Secondly, later text seems to use a different 1739 status codes and never mentions this one again. 8.10.7 lists status 1740 codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed, 1741 but 409 Conflict (mentioned above) is not. - In the case of 412 1742 Precondition Failed, the description the follows doesn't seem to 1743 describe a "precondition failed". And it sounds like it's talking 1744 about an access request that includes a "locktoken", not a LOCK 1745 request that generates one. - The 423 Locked condition also sort of 1746 sounds like it's talking about an access request rather than a LOCK 1747 request. 8.10.10 lists LOCK status codes - 207 Multistatus which was 1748 not mentioned above - 403 Forbidden which was not mentioned above. 1749 - 424 Failed dependency which was not mentioned above. 8.11 UNLOCK 1750 - we don't mention what the failure response should look like. - 1751 comment: 200 OK seems like a better response than 204 No Content. 1752 The brief explanation isn't persuasive and seems to say that the 1753 response code should serve the purpose of the Content-Length. 1754 header. - we should probably explicitly say if an UNLOCK can only be 1755 done on the original resource... and will fail even if the resource 1756 specified is locked by virtue of being a child of the original 1757 resource. Or is this too obvious? I know it's something easy to 1758 goof up in an implementation. 1760 julian.reschke@greenbytes.de (2004-06-04): (1) 8.10.4 is wrong. The 1761 return code is 207. See issue 037_DEEP_LOCK_ERROR_STATUS, resolved 1762 in draft 01. (2) General agreement that descriptions of error 1763 marshalling needs to be redone. This applies both th LOCK and 1764 UNLOCK. (3) Agreement that the argument given for 204 is lame; 1765 clients should handle all 2xx status codes with the notable exception 1766 of 207 as "success". We may want to explain that in RFC2518bis' 1767 section about 207. 1769 G.6 044_REPORT_OTHER_RESOURCE_LOCKED 1771 Type: change 1773 1775 wiggs@xythos.com (1999-07-23): In some cases, such as when the parent 1776 collection of a resource is locked, a 423 (Locked) status code is 1777 returned even though the resource identified by the Request-URI is 1778 not locked. This can be confusing, since it is not possible for a 1779 client to easily discover which resource is causing the locked status 1780 code to be returned. An improved status report would indicate the 1781 resource causing the lock message. 1783 julian.reschke@greenbytes.de (2004-04-25): Proposal to define a 1784 specific precondition element plus specific child elements similar to 1785 RFC3744, section 7.1.1. 1787 G.7 056_DEPTH_LOCK_AND_IF 1789 Type: change 1791 1793 joe@orton.demon.co.uk (2000-03-04): The specification is currently 1794 silent on how to use the If header for submitting a locktoken when 1795 performing a DELETE in a Depth infinity locked collection. Should 1796 the If header have both the collection URL and the Request-URI, or 1797 just the Request-URI? An example of this is needed. 1799 julian.reschke@greenbytes.de (2004-04-25): Clarify as part of 1800 integrating GULP. May need to test interop with existing 1801 implementations. 1803 G.8 057_LOCK_SEMANTICS 1805 Type: change 1807 (): At present, the WebDAV specification is not excruciatingly 1808 explicit that writing to a locked resource requires the combination 1809 of the lock token, plus an authentication principal. At one point, 1810 the spec. discusses an "authorized" principal, but "authorized" is 1811 never explicitly defined. 1813 julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token 1814 in an If header (usages != UNLOCK) SHOULD be restricted to whatever 1815 the server thinks the "owner" of the lock is. See discussion at 1816 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#88. 1818 G.9 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY 1820 Type: change 1822 jrd3@alum.mit.edu (): Is the complexity of the IF header appropriate 1823 for the simple task o verifying that a client knowingly owns a lock? 1824 The IF header seems to serve a different purpose. One of those 1825 purposes is for the server to verify that you have the lock token 1826 (and that you know the root of it?). Another is for the client to 1827 check some preconditions before doing an action. Another seems to be 1828 to specify what lock to refresh in a lock refresh request. This 1829 seems to create ambiguity in our definition of the semantics of the 1830 IF: header. 1832 ccjason@us.ibm.com (): It is felt by the group that it's important 1833 that the client not just own and hold the lock token, but that it 1834 also know where the lock is rooted before it does tasks related to 1835 that lock. This still leaves the lock referesh issue unresolved. 1837 julian.reschke@greenbytes.de (2004-06-02): Re.: using Lock-Token to 1838 identify the lock to be refreshed 1839 (http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0127.html): 1840 problems with current rfc2518bis-05 wording; also no support in 1841 popular implementations; suggestion to roll-back changes in -bis and 1842 keep "If" header based syntax. 1844 G.10 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL 1846 Type: change 1848 (): Right now the server uses the IF: header to verify that a client 1849 knows what locks it has that are affected by an operation before it 1850 allows the operation. Must the client provide the root URL of a 1851 lock, any URL for a pertainent loc, or some specific URL in the IF: 1852 header. 1854 ccjason@us.ibm.com (): It is felt by the group that it's important 1855 that the client not just own and hold the lock token, but that it 1856 also know where the lock is rooted before it does tasks related to 1857 that lock. This is just a point of info. The issue itself still 1858 needs to be brought up and answered.still 1860 G.11 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED 1862 Type: change 1864 (): The DAV:owner field of a lock is controlled by the locking client 1865 and should not be manipulated by the server. This is the only place 1866 the client can store info. The roundtrip details should match what 1867 we resolve for the PROP_ROUNDTRIP issue. Examples should also be 1868 checked. 1870 Resolution: Resolved by repeated statement and no disagreement. 1872 G.12 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION 1874 Type: change 1876 1878 ccjason@us.ibm.com (): What resource should be flagged in the 1879 multistatus response to locking issues in COPY/MOVE requests? 1881 Resolution: Resolved to flag the locking errors at the source 1882 resource that was affected by the problem. The details of how to 1883 describe the error was deferred to a subsequent version of WebDAV. - 1884 6/15/02 - 2518bis does not reflect this. 1886 G.13 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION 1888 Type: change 1890 1892 (): The method of describing the details of (beyond what resolved by 1893 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of 1894 various locking and ACL COPY/MOVE problems is deferred. Two 1895 proposals were outlined in the discussion, but interest was not great 1896 and we clearly don't have interoperability to take these proposals 1897 forward. 1899 G.14 072_LOCK_URL_WITH_NO_PARENT_COLLECTION 1901 Type: change 1902 1904 dbrotsky@Adobe.COM (): If a LOCK request is submitted to a URL that 1905 doesn't have a parent collection, what should be the correct 1906 response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409 1907 response in this case. Seems like LOCK should have this requirement 1908 as well. 1910 Resolution: Resolved that since LNRs no longer exist (see 1911 NULL_RESOURCE_CLARIFY) the server should return 409. We should 1912 insure that the new text we add to replace LNRs does not create an 1913 ambiguity: 1914 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html 1916 G.15 065_UNLOCK_WHAT_URL 1918 Type: change 1920 1922 Juergen.Pill@softwareag.com (2001-03-01): What do you return if the 1923 unlock request specifies a URL on which the lock does not reside? 1924 What if it's on a URL that is locked by the lock, but it's not the 1925 resource where the lock is rooted? 1927 (): Resolution (as of May 31, 2004) from RFC2518 issues list: 1928 Resolved that you can specify any URL locked by the lock you want to 1929 unlock. 1930 (http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html) 1931 We should resolve the issue of UNLOCK'ing other URLs in a few days. 1933 julian.reschke@greenbytes.de (2004-06-01): New discussion, resolution 1934 pending. See 1935 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0120.html. 1937 G.16 067_UNLOCK_NEEDS_IF_HEADER 1939 Type: change 1941 1943 dbrotsky@Adobe.COM (): Shouldn't we be using an IF header to do an 1944 UNLOCK seeing as you need to prove you are holding a lock before you 1945 can remove it? (This might be contingent on 1946 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) 1948 julian.reschke@greenbytes.de (2004-06-04): (1) Keep "Lock-Token" 1949 header to specify the lock to be removed. (2) Need to check whether 1950 existing implementations indeed want to see an "If" header as well. 1952 G.17 068_UNLOCK_WITHOUT_GOOD_TOKEN 1954 Type: change 1956 1958 dbrotsky@Adobe.COM (): What should UNLOCK return if a bad token is 1959 provided or no token. (This might be contingent on 1960 UNLOCK_NEEDS_IF_HEADER.) 1962 julian.reschke@greenbytes.de (2004-06-06): According to the rewritten 1963 description, this will be a 4xx with condition code 1964 DAV:lock-token-matches. Check the status codes for existing 1965 implementations, though. 1967 julian.reschke@greenbytes.de (2004-06-07): Results: (a) Microsoft IIS 1968 5.0: (a1) no lock token: 400, (a2) bad lock token: 412, (a3) unlocked 1969 resource: 412. (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, 1970 (b2): bad lock token: 400, (b3) unlocked resource: 400. (c) SAP 1971 Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock 1972 token: 412, (c3) unlocked resource: 412. (d) Xythos (Sharemation): 1973 see (c). 1975 julian.reschke@greenbytes.de (2004-06-07): Related: what's the status 1976 code when the lock doesn't exist? 1978 G.18 040_LOCK_ISSUES_08 1980 Type: change 1982 1984 ccjason@us.ibm.com (1999-06-07): Shared locks... read locks... Our 1985 justifcation for shared locks ("Shared locks are included 1986 because....") seems faulty. It's not a mechansim for dealing with 1987 programs that forget to release their locks. That remains a problem 1988 with shared locks. In this case they'd forget to release a shared 1989 lock and block exclusive lock users. Timeouts and administrative 1990 action are the solutions to this problem... not shared locks. BTW, 1991 I'd think that the use of exclusive locks is just fine. I do have a 1992 problem with shared locks though... or at least shared write locks. 1993 Although they were relatively easy to define, I see them as solving a 1994 red herring problem of multiple entites cooperatively writing using 1995 distinct locks. I say it's a red herring because they don't know 1996 each other well enough to use the same lock but they do know each 1997 other well enough to not step on each other. This seems unlikely. 1998 As does the managing a compatibility matrix and getting all the 1999 entities to abide by it. OTOH I see another more common problem that 2000 is being overlooked. I see a class of folks whose purpose is to not 2001 actually write to a (set of) resource(s), but to simply prevent 2002 others from writing to it while they are looking at it. Shared write 2003 locks do not necessarily do that because with a shared write lock. 2004 someone else could grab a shared lock and go ahead and write. The 2005 only way to block that is to get an exclusive write lock. But doing 2006 that prevents anyone else from doing what you're doing despite it 2007 being pretty benign. An expedient solution is to say that a shared 2008 write lock should not necessarily give one the right to modify a 2009 resource. All it should do is prevent others from writing. And then 2010 the purpose of an exclusive write lock is just to insure that others 2011 can't get a lock and block you from writing. Now is this the right 2012 solution? Probably not. There probably should be something called a 2013 read lock that actually prevents writes as a side effect.... and 2014 would tend to get used in shared mode. Anyway, as it is, I think the 2015 shared write locks are a red herring and we're missing something we 2016 are more likely to need... shared read locks. 2018 julian.reschke@greenbytes.de (2004-04-24): Agreement that the 2019 rational for shared locks either needs to be rewritten or deleted. 2020 However shared locks are a fact, and we shouldn't change the 2021 semantics given in RFC2518. 2023 G.19 040_LOCK_ISSUES_03 2025 Type: change 2027 2029 ccjason@us.ibm.com (1999-06-07): Section 7.1 Write lock. I believe 2030 this definition of a write lock is not right... or not complete... 2031 judging from what I read elsewhere. I believe one can do these 2032 operations without a write lock... as long as someone else doesn't 2033 have a write lock on the resources effected. I also believe it 2034 doesn't prevent LOCK requests in the case of shared locks. 2036 julian.reschke@greenbytes.de (2004-04-24): Clarify as part of 2037 rewriting the general semantics. The point about shared locks is 2038 correct, though. 2040 G.20 040_LOCK_ISSUES_04 2042 Type: change 2044 2046 ccjason@us.ibm.com (1999-06-07): Section 7.5 Write Locks and 2047 Collections. It says that if members are locked in a conflicting 2048 manner, then their collection can't be locked. That seems 2049 ambiguously safe to say, but I suspect that text should mention depth 2050 since if the parent lock request is depth 0, I don't think we let the 2051 members lock state effect the success of the LOCK request. The 2052 possible exception is what we said about protecting a URI that was 2053 used to perform a lock (of a member of the collection). I'm not sure 2054 what we'd like to say for that. In the advanced collection meetings 2055 we refered to these being "protected" and avoided speaking about 2056 "lock"ing the URI. This creates an odd situation though. 2058 julian.reschke@greenbytes.de (2004-05-24): Clarify that this only 2059 applies to the attempt to depth-infinity lock the collection. 2061 G.21 053_LOCK_INHERITANCE 2063 Type: change 2065 2067 jrd3@alum.mit.edu (1999-11-26): Section 7.5 states, "If a lock owner 2068 causes the URI of a resource to be added as an internal member URI of 2069 a locked collection then the new resource MUST be automatically added 2070 to the lock." However, though this is the intent, the specification 2071 does not explicitly state that this behavior only applies to depth 2072 infinity locked collections. The words "Depth infinity" should be 2073 added before the word "locked" in this sentence. 2075 julian.reschke@greenbytes.de (2004-04-25): Clarify as part of 2076 integrating GULP. 2078 G.22 015_MOVE_SECTION_6.4.1_TO_APPX 2080 Type: change 2082 2083 mda@discerning.com (1998-11-24): The discussion of generating UUID 2084 node fields without using the IEEE 802 address in section 6.4.1 can 2085 be moved to an appendix. 2087 julian.reschke@greenbytes.de (2004-04-31): Plan: get rid of the 2088 section altogether and refer to draft-mealling-uuid-urn. In the 2089 meantime, move the whole opaquelocktoken discussion into an appendix. 2091 Index 2093 4 2094 423 Locked (status code) 16 2096 D 2097 DAV header 2098 compliance class '2' 16 2099 compliance class 'locking' 16 2100 DAV:lockdiscovery property 6 2101 DAV:supportedlock property 8 2103 H 2104 Headers 2105 Lock-Token 29 2106 Timeout 30 2108 L 2109 LOCK method 9 2110 lock creation 9 2111 lock refresh 13 2112 Lock-Token header 29 2113 lockinfo 2114 XML element 31 2116 M 2117 Methods 2118 LOCK (lock creation) 9 2119 LOCK (lock refresh) 13 2120 LOCK 9 2121 UNLOCK 15 2123 O 2124 opaquelocktoken (URI scheme) 32 2126 P 2127 Properties 2128 DAV:lockdiscovery 6 2129 DAV:supportedlock 8 2131 S 2132 Status Codes 2133 423 Locked 16 2135 T 2136 Timeout header 30 2138 U 2139 UNLOCK method 15 2140 URI schemes 2141 opaquelocktoken 32 2143 Intellectual Property Statement 2145 The IETF takes no position regarding the validity or scope of any 2146 Intellectual Property Rights or other rights that might be claimed to 2147 pertain to the implementation or use of the technology described in 2148 this document or the extent to which any license under such rights 2149 might or might not be available; nor does it represent that it has 2150 made any independent effort to identify any such rights. Information 2151 on the procedures with respect to rights in RFC documents can be 2152 found in BCP 78 and BCP 79. 2154 Copies of IPR disclosures made to the IETF Secretariat and any 2155 assurances of licenses to be made available, or the result of an 2156 attempt made to obtain a general license or permission for the use of 2157 such proprietary rights by implementers or users of this 2158 specification can be obtained from the IETF on-line IPR repository at 2159 http://www.ietf.org/ipr. 2161 The IETF invites any interested party to bring to its attention any 2162 copyrights, patents or patent applications, or other proprietary 2163 rights that may cover technology that may be required to implement 2164 this standard. Please address the information to the IETF at 2165 ietf-ipr@ietf.org. 2167 Disclaimer of Validity 2169 This document and the information contained herein are provided on an 2170 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2171 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2172 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2173 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2174 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2175 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2177 Copyright Statement 2179 Copyright (C) The Internet Society (2004). This document is subject 2180 to the rights, licenses and restrictions contained in BCP 78, and 2181 except as set forth therein, the authors retain all their rights. 2183 Acknowledgment 2185 Funding for the RFC Editor function is currently provided by the 2186 Internet Society.