idnits 2.17.1 draft-reschke-webdav-locking-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2377. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2393), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 52 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 379: '... Lock token URIs MUST be unique across...' RFC 2119 keyword, line 391: '... Locks MUST be enforced based upon w...' RFC 2119 keyword, line 401: '... All resources MUST recognize the op...' RFC 2119 keyword, line 413: '...g the extensions MUST guarantee that t...' RFC 2119 keyword, line 431: '... address. WebDAV servers MAY use this...' (66 more instances...) -- 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 (May 21, 2004) is 7280 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 416, but not defined == Unused Reference: 'RFC3253' is defined on line 252, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 256, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11578' ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Updates: 2518 (if approved) May 21, 2004 5 Expires: November 19, 2004 7 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol 8 draft-reschke-webdav-locking-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 19, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document specifies a set of methods and headers ancillary to 42 HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, 43 RFC2518) for the management of resource locking (collision 44 avoidance). It updates those sections from RFC2518 that specify 45 WebDAV's locking features. 47 [[anchor1: Note that this document is not a product of the WebDAV 48 working group. 49 It is just an experiment to study the 50 feasability of extracing the 51 locking feature into a separate 53 specification. --reschke]][[anchor2: This version of this document 54 doesn't yet contain any new or 55 rewritten text - it only 56 contains text copied verbatim fro RFC2518 57 and GULP. It's 58 sole purpose is be a reference point for 59 all future changes. 60 --reschke]] 62 Distribution of this document is unlimited. Please send comments to 63 the WebDAV working group at , which may 64 be joined by sending a message with subject "subscribe" to 65 . 67 Discussions of the WEBDAV working group are archived at URL: . 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . 5 74 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 5 76 5. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . 5 77 6. Additional status codes . . . . . . . . . . . . . . . . . . 5 78 7. Additional method semantics for other Methods . . . . . . . 5 79 8. Capability discovery . . . . . . . . . . . . . . . . . . . . 5 80 9. Security considerations . . . . . . . . . . . . . . . . . . 5 81 10. Internationalization Considerations . . . . . . . . . . . . 5 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 84 13. Normative References . . . . . . . . . . . . . . . . . . . . 6 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 86 A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . 6 87 A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 6 88 A.2 Additional features features . . . . . . . . . . . . . . . 6 89 A.3 Compatibility considerations . . . . . . . . . . . . . . . 6 90 B. Text to be integrated from RFC2518 . . . . . . . . . . . . . 6 91 B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 92 B.2 Locking . . . . . . . . . . . . . . . . . . . . . . . . . 7 93 B.2.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . 7 94 B.2.2 Required Support . . . . . . . . . . . . . . . . . . . 8 95 B.2.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . 8 96 B.2.4 opaquelocktoken Lock Token URI Scheme . . . . . . . . 9 97 B.2.5 Lock Capability Discovery . . . . . . . . . . . . . . 11 98 B.2.6 Active Lock Discovery . . . . . . . . . . . . . . . . 12 99 B.2.7 Usage Considerations . . . . . . . . . . . . . . . . . 12 100 B.3 Write Lock . . . . . . . . . . . . . . . . . . . . . . . . 13 101 B.3.1 Methods Restricted by Write Locks . . . . . . . . . . 13 102 B.3.2 Write Locks and Lock Tokens . . . . . . . . . . . . . 13 103 B.3.3 Write Locks and Properties . . . . . . . . . . . . . . 13 104 B.3.4 Write Locks and Null Resources . . . . . . . . . . . . 13 105 B.3.5 Write Locks and Collections . . . . . . . . . . . . . 14 106 B.3.6 Write Locks and the If Request Header . . . . . . . . 14 107 B.3.7 Write Locks and COPY/MOVE . . . . . . . . . . . . . . 15 108 B.3.8 Refreshing Write Locks . . . . . . . . . . . . . . . . 16 109 B.4 HTTP Headers for Distributed Authoring . . . . . . . . . . 16 110 B.4.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 16 111 B.4.2 UNLOCK Method . . . . . . . . . . . . . . . . . . . . 23 112 B.5 HTTP Headers for Distributed Authoring . . . . . . . . . . 24 113 B.5.1 DAV Header . . . . . . . . . . . . . . . . . . . . . . 24 114 B.5.2 Depth Header . . . . . . . . . . . . . . . . . . . . . 24 115 B.5.3 If Header . . . . . . . . . . . . . . . . . . . . . . 24 116 B.5.4 Lock-Token Header . . . . . . . . . . . . . . . . . . 24 117 B.5.5 Timeout Request Header . . . . . . . . . . . . . . . . 24 118 B.6 Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . 25 119 B.6.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . 25 120 B.7 XML Element Definitions . . . . . . . . . . . . . . . . . 26 121 B.7.1 activelock XML Element . . . . . . . . . . . . . . . . 26 122 B.7.2 lockentry XML Element . . . . . . . . . . . . . . . . 27 123 B.7.3 lockinfo XML Element . . . . . . . . . . . . . . . . . 27 124 B.7.4 lockscope XML Element . . . . . . . . . . . . . . . . 27 125 B.7.5 locktype XML Element . . . . . . . . . . . . . . . . . 28 126 B.7.6 owner XML Element . . . . . . . . . . . . . . . . . . 29 127 B.8 DAV Properties . . . . . . . . . . . . . . . . . . . . . . 29 128 B.8.1 lockdiscovery Property . . . . . . . . . . . . . . . . 29 129 B.8.2 supportedlock Property . . . . . . . . . . . . . . . . 31 130 B.9 DAV Compliance Classes . . . . . . . . . . . . . . . . . . 32 131 B.9.1 Class 2 . . . . . . . . . . . . . . . . . . . . . . . 32 132 B.10 Security Considerations . . . . . . . . . . . . . . . . 32 133 B.10.1 Authentication of Clients . . . . . . . . . . . . . 32 134 B.10.2 Privacy Issues Connected to Locks . . . . . . . . . 33 135 B.11 IANA Considerations . . . . . . . . . . . . . . . . . . 33 136 C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 137 D. Resolved issues (to be removed by RFC Editor before 138 publication) . . . . . . . . . . . . . . . . . . . . . . . . 34 139 D.1 040_LOCK_ISSUES . . . . . . . . . . . . . . . . . . . . . 34 140 D.2 058_LOCK_SEIZURE . . . . . . . . . . . . . . . . . . . . . 34 141 D.3 093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK . . . . 35 142 D.4 096_SHARED_LOCKS_INTEROP_NOT_TESTED . . . . . . . . . . . 35 143 E. Open issues (to be removed by RFC Editor prior to 144 publication) . . . . . . . . . . . . . . . . . . . . . . . . 35 145 E.1 extract-locking . . . . . . . . . . . . . . . . . . . . . 35 146 E.2 updated-rfc2068 . . . . . . . . . . . . . . . . . . . . . 35 147 E.3 import-rfc3253-stuff . . . . . . . . . . . . . . . . . . . 36 148 E.4 008_URI_URL . . . . . . . . . . . . . . . . . . . . . . . 36 149 E.5 015_MOVE_SECTION_6.4.1_TO_APPX . . . . . . . . . . . . . . 36 150 E.6 022_COPY_OVERWRITE_LOCK_NULL . . . . . . . . . . . . . . . 36 151 E.7 025_LOCK_REFRESH_BY_METHODS . . . . . . . . . . . . . . . 37 152 E.8 037_DEEP_LOCK_ERROR_STATUS . . . . . . . . . . . . . . . . 37 153 E.9 039_MISSING_LOCK_TOKEN . . . . . . . . . . . . . . . . . . 37 154 E.10 040_LOCK_ISSUES_01 . . . . . . . . . . . . . . . . . . . 38 155 E.11 040_LOCK_ISSUES_02 . . . . . . . . . . . . . . . . . . . 38 156 E.12 040_LOCK_ISSUES_03 . . . . . . . . . . . . . . . . . . . 38 157 E.13 040_LOCK_ISSUES_04 . . . . . . . . . . . . . . . . . . . 39 158 E.14 040_LOCK_ISSUES_05 . . . . . . . . . . . . . . . . . . . 39 159 E.15 040_LOCK_ISSUES_06 . . . . . . . . . . . . . . . . . . . 40 160 E.16 040_LOCK_ISSUES_07 . . . . . . . . . . . . . . . . . . . 40 161 E.17 040_LOCK_ISSUES_08 . . . . . . . . . . . . . . . . . . . 41 162 E.18 043_NULL_LOCK_SLASH_URL . . . . . . . . . . . . . . . . 42 163 E.19 044_REPORT_OTHER_RESOURCE_LOCKED . . . . . . . . . . . . 42 164 E.20 052_LOCK_BODY_SHOULD_BE_MUST . . . . . . . . . . . . . . 43 165 E.21 053_LOCK_INHERITANCE . . . . . . . . . . . . . . . . . . 43 166 E.22 054_IF_AND_AUTH . . . . . . . . . . . . . . . . . . . . 44 167 E.23 056_DEPTH_LOCK_AND_IF . . . . . . . . . . . . . . . . . 44 168 E.24 057_LOCK_SEMANTICS . . . . . . . . . . . . . . . . . . . 44 169 E.25 060_LOCK_REFRESH_BODY . . . . . . . . . . . . . . . . . 44 170 E.26 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY . . . . 45 171 E.27 065_UNLOCK_WHAT_URL . . . . . . . . . . . . . . . . . . 45 172 E.28 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . 46 173 E.29 067_UNLOCK_NEEDS_IF_HEADER . . . . . . . . . . . . . . . 46 174 E.30 068_UNLOCK_WITHOUT_GOOD_TOKEN . . . . . . . . . . . . . 46 175 E.31 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER . . . . . . . 46 176 E.32 072_LOCK_URL_WITH_NO_PARENT_COLLECTION . . . . . . . . . 47 177 E.33 073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE . . . . . . . . . 47 178 E.34 077_LOCK_NULL_STATUS_CREATION . . . . . . . . . . . . . 48 179 E.35 079_UNLOCK_BY_NON_LOCK_OWNER . . . . . . . . . . . . . . 48 180 E.36 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC . . . . . . . . . 48 181 E.37 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED . . . . . . . . . 49 182 E.38 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK . . . . . . . . . . 49 183 E.39 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . 49 184 E.40 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . 49 185 E.41 101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS . . . 50 186 E.42 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK . . . . . . . . . . . 50 187 E.43 111_MULTIPLE_TOKENS_PER_LOCK . . . . . . . . . . . . . . 50 188 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 189 Intellectual Property and Copyright Statements . . . . . . . 54 191 1. Introduction 193 2. Overview of Locking 195 3. Properties 197 4. LOCK Method 199 5. UNLOCK Method 201 6. Additional status codes 203 7. Additional method semantics for other Methods 205 8. Capability discovery 207 9. Security considerations 209 10. Internationalization Considerations 211 All internationalization considerations mentioned in [RFC2518] also 212 apply to this document. 214 11. IANA Considerations 216 All IANA considerations mentioned in [RFC2518] also apply to this 217 document. 219 12. Acknowledgements 221 This document is the collaborative product of 223 o the authors, 225 o the maintainers of the RFC2518bis - Jason Crawford and Lisa 226 Dusseault - and 228 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron 229 Goland, Del Jensen and Jim Whitehead. 231 This document has also benefited from thoughtful discussion by Mark 232 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, 233 Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias 234 Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV 235 working group. 237 13 Normative References 239 [ISO-11578] 240 International Organization for Standardization, "ISO/IEC 241 11578:1996. Information technology - Open Systems 242 Interconnection - Remote Procedure Call (RPC)", 1996. 244 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. 245 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 246 RFC 2068, January 1997. 248 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 249 Jensen, "HTTP Extensions for Distributed Authoring -- 250 WEBDAV", RFC 2518, February 1999. 252 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 253 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 254 March 2002. 256 [3] 258 Author's Address 260 Julian F. Reschke 261 greenbytes GmbH 262 Salzmannstrasse 152 263 Muenster, NW 48159 264 Germany 266 Phone: +49 251 2807760 267 Fax: +49 251 2807761 268 EMail: julian.reschke@greenbytes.de 269 URI: http://greenbytes.de/tech/webdav/ 271 Appendix A. Changes to RFC2518 273 A.1 Removed/Deprecated features 275 A.2 Additional features features 277 A.3 Compatibility considerations 279 Appendix B. Text to be integrated from RFC2518 281 B.1 Introduction 283 Locking: The ability to keep more than one person from working on a 284 document at the same time. This prevents the "lost update problem," 285 in which modifications are lost as first one author then another 286 writes changes without merging the other author's changes. 288 B.2 Locking 290 The ability to lock a resource provides a mechanism for serializing 291 access to that resource. Using a lock, an authoring client can 292 provide a reasonable guarantee that another principal will not modify 293 a resource while it is being edited. In this way, a client can 294 prevent the "lost update" problem. 296 This specification allows locks to vary over two client-specified 297 parameters, the number of principals involved (exclusive vs. shared) 298 and the type of access to be granted. This document defines locking 299 for only one access type, write. However, the syntax is extensible, 300 and permits the eventual specification of locking for other access 301 types. 303 B.2.1 Exclusive Vs. Shared Locks 305 The most basic form of lock is an exclusive lock. This is a lock 306 where the access right in question is only granted to a single 307 principal. The need for this arbitration results from a desire to 308 avoid having to merge results. 310 However, there are times when the goal of a lock is not to exclude 311 others from exercising an access right but rather to provide a 312 mechanism for principals to indicate that they intend to exercise 313 their access rights. Shared locks are provided for this case. A 314 shared lock allows multiple principals to receive a lock. Hence any 315 principal with appropriate access can get the lock. 317 With shared locks there are two trust sets that affect a resource. 318 The first trust set is created by access permissions. Principals who 319 are trusted, for example, may have permission to write to the 320 resource. Among those who have access permission to write to the 321 resource, the set of principals who have taken out a shared lock also 322 must trust each other, creating a (typically) smaller trust set 323 within the access permission write set. 325 Starting with every possible principal on the Internet, in most 326 situations the vast majority of these principals will not have write 327 access to a given resource. Of the small number who do have write 328 access, some principals may decide to guarantee their edits are free 329 from overwrite conflicts by using exclusive write locks. Others may 330 decide they trust their collaborators will not overwrite their work 331 (the potential set of collaborators being the set of principals who 332 have write permission) and use a shared lock, which informs their 333 collaborators that a principal may be working on the resource. 335 The WebDAV extensions to HTTP do not need to provide all of the 336 communications paths necessary for principals to coordinate their 337 activities. When using shared locks, principals may use any out of 338 band communication channel to coordinate their work (e.g., 339 face-to-face interaction, written notes, post-it notes on the screen, 340 telephone conversation, Email, etc.) The intent of a shared lock is 341 to let collaborators know who else may be working on a resource. 343 Shared locks are included because experience from web distributed 344 authoring systems has indicated that exclusive locks are often too 345 rigid. An exclusive lock is used to enforce a particular editing 346 process: take out an exclusive lock, read the resource, perform 347 edits, write the resource, release the lock. This editing process 348 has the problem that locks are not always properly released, for 349 example when a program crashes, or when a lock owner leaves without 350 unlocking a resource. While both timeouts and administrative action 351 can be used to remove an offending lock, neither mechanism may be 352 available when needed; the timeout may be long or the administrator 353 may not be available. 355 B.2.2 Required Support 357 A WebDAV compliant server is not required to support locking in any 358 form. If the server does support locking it may choose to support 359 any combination of exclusive and shared locks for any access types. 361 The reason for this flexibility is that locking policy strikes to the 362 very heart of the resource management and versioning systems employed 363 by various storage repositories. These repositories require control 364 over what sort of locking will be made available. For example, some 365 repositories only support shared write locks while others only 366 provide support for exclusive write locks while yet others use no 367 locking at all. As each system is sufficiently different to merit 368 exclusion of certain locking features, this specification leaves 369 locking as the sole axis of negotiation within WebDAV. 371 B.2.3 Lock Tokens 373 A lock token is a type of state token, represented as a URI, which 374 identifies a particular lock. A lock token is returned by every 375 successful LOCK operation in the lockdiscovery property in the 376 response body, and can also be found through lock discovery on a 377 resource. 379 Lock token URIs MUST be unique across all resources for all time. 381 This uniqueness constraint allows lock tokens to be submitted across 382 resources and servers without fear of confusion. 384 This specification provides a lock token URI scheme called 385 opaquelocktoken that meets the uniqueness requirements. However 386 resources are free to return any URI scheme so long as it meets the 387 uniqueness requirements. 389 Having a lock token provides no special access rights. Anyone can 390 find out anyone else's lock token by performing lock discovery. 391 Locks MUST be enforced based upon whatever authentication mechanism 392 is used by the server, not based on the secrecy of the token values. 394 B.2.4 opaquelocktoken Lock Token URI Scheme 396 The opaquelocktoken URI scheme is designed to be unique across all 397 resources for all time. Due to this uniqueness quality, a client may 398 submit an opaque lock token in an If header on a resource other than 399 the one that returned it. 401 All resources MUST recognize the opaquelocktoken scheme and, at 402 minimum, recognize that the lock token does not refer to an 403 outstanding lock on the resource. 405 In order to guarantee uniqueness across all resources for all time 406 the opaquelocktoken requires the use of the Universal Unique 407 Identifier (UUID) mechanism, as described in [ISO-11578]. 409 Opaquelocktoken generators, however, have a choice of how they create 410 these tokens. They can either generate a new UUID for every lock 411 token they create or they can create a single UUID and then add 412 extension characters. If the second method is selected then the 413 program generating the extensions MUST guarantee that the same 414 extension will never be used twice with the associated UUID. 416 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID 417 production is the string representation of a UUID, as defined in 418 [ISO-11578]. Note that white space (LWS) is not allowed between 419 elements of this production. 421 Extension = path ; path is defined in section 3.2.1 of RFC 2068 422 [RFC2068] 424 B.2.4.1 Node Field Generation Without the IEEE 802 Address 426 UUIDs, as defined in [ISO-11578], contain a "node" field that 427 contains one of the IEEE 802 addresses for the server machine. As 428 noted in Appendix B.10.2, there are several security risks associated 429 with exposing a machine's IEEE 802 address. This section provides an 430 alternate mechanism for generating the "node" field of a UUID which 431 does not employ an IEEE 802 address. WebDAV servers MAY use this 432 algorithm for creating the node field when generating UUIDs. The 433 text in this section is originally from an Internet-Draft by Paul 434 Leach and Rich Salz, who are noted here to properly attribute their 435 work. 437 The ideal solution is to obtain a 47 bit cryptographic quality random 438 number, and use it as the low 47 bits of the node ID, with the most 439 significant bit of the first octet of the node ID set to 1. This bit 440 is the unicast/multicast bit, which will never be set in IEEE 802 441 addresses obtained from network cards; hence, there can never be a 442 conflict between UUIDs generated by machines with and without network 443 cards. 445 If a system does not have a primitive to generate cryptographic 446 quality random numbers, then in most systems there are usually a 447 fairly large number of sources of randomness available from which one 448 can be generated. Such sources are system specific, but often 449 include: 451 o the percent of memory in use 453 o the size of main memory in bytes 455 o the amount of free main memory in bytes 457 o the size of the paging or swap file in bytes 459 o free bytes of paging or swap file 461 o the total size of user virtual address space in bytes 463 o the total available user address space bytes 465 o the size of boot disk drive in bytes 467 o the free disk space on boot drive in bytes 469 o the current time 471 o the amount of time since the system booted 473 o the individual sizes of files in various system directories 475 o the creation, last read, and modification times of files in 476 various system directories 478 o the utilization factors of various system resources (heap, etc.) 480 o current mouse cursor position 482 o current caret position 484 o current number of running processes, threads 486 o handles or IDs of the desktop window and the active window 488 o the value of stack pointer of the caller 490 o the process and thread ID of caller 492 o various processor architecture specific performance counters 493 (instructions executed, cache misses, TLB misses) 495 (Note that it is precisely the above kinds of sources of randomness 496 that are used to seed cryptographic quality random number generators 497 on systems without special hardware for their construction.) 499 In addition, items such as the computer's name and the name of the 500 operating system, while not strictly speaking random, will help 501 differentiate the results from those obtained by other systems. 503 The exact algorithm to generate a node ID using these data is system 504 specific, because both the data available and the functions to obtain 505 them are often very system specific. However, assuming that one can 506 concatenate all the values from the randomness sources into a buffer, 507 and that a cryptographic hash function such as MD5 is available, then 508 any 6 bytes of the MD5 hash of the buffer, with the multicast bit 509 (the high bit of the first byte) set will be an appropriately random 510 node ID. 512 Other hash functions, such as SHA-1, can also be used. The only 513 requirement is that the result be suitably random _ in the sense that 514 the outputs from a set uniformly distributed inputs are themselves 515 uniformly distributed, and that a single bit change in the input can 516 be expected to cause half of the output bits to change. 518 B.2.5 Lock Capability Discovery 520 Since server lock support is optional, a client trying to lock a 521 resource on a server can either try the lock and hope for the best, 522 or perform some form of discovery to determine what lock capabilities 523 the server supports. This is known as lock capability discovery. 524 Lock capability discovery differs from discovery of supported access 525 control types, since there may be access control types without 526 corresponding lock types. A client can determine what lock types the 527 server supports by retrieving the supportedlock property. 529 Any DAV compliant resource that supports the LOCK method MUST support 530 the supportedlock property. 532 B.2.6 Active Lock Discovery 534 If another principal locks a resource that a principal wishes to 535 access, it is useful for the second principal to be able to find out 536 who the first principal is. For this purpose the lockdiscovery 537 property is provided. This property lists all outstanding locks, 538 describes their type, and where available, provides their lock token. 540 Any DAV compliant resource that supports the LOCK method MUST support 541 the lockdiscovery property. 543 B.2.7 Usage Considerations 545 Although the locking mechanisms specified here provide some help in 546 preventing lost updates, they cannot guarantee that updates will 547 never be lost. Consider the following scenario: 549 Two clients A and B are interested in editing the resource ' 550 index.html'. Client A is an HTTP client rather than a WebDAV client, 551 and so does not know how to perform locking. 553 Client A doesn't lock the document, but does a GET and begins 554 editing. 556 Client B does LOCK, performs a GET and begins editing. 558 Client B finishes editing, performs a PUT, then an UNLOCK. 560 Client A performs a PUT, overwriting and losing all of B's changes. 562 There are several reasons why the WebDAV protocol itself cannot 563 prevent this situation. First, it cannot force all clients to use 564 locking because it must be compatible with HTTP clients that do not 565 comprehend locking. Second, it cannot require servers to support 566 locking because of the variety of repository implementations, some of 567 which rely on reservations and merging rather than on locking. 568 Finally, being stateless, it cannot enforce a sequence of operations 569 like LOCK / GET / PUT / UNLOCK. 571 WebDAV servers that support locking can reduce the likelihood that 572 clients will accidentally overwrite each other's changes by requiring 573 clients to lock resources before modifying them. Such servers would 574 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying 575 resources. 577 WebDAV clients can be good citizens by using a lock / retrieve / 578 write /unlock sequence of operations (at least by default) whenever 579 they interact with a WebDAV server that supports locking. 581 HTTP 1.1 clients can be good citizens, avoiding overwriting other 582 clients' changes, by using entity tags in If-Match headers with any 583 requests that would modify resources. 585 Information managers may attempt to prevent overwrites by 586 implementing client-side procedures requiring locking before 587 modifying WebDAV resources. 589 B.3 Write Lock 591 This section describes the semantics specific to the write lock type. 592 The write lock is a specific instance of a lock type, and is the only 593 lock type described in this specification. 595 B.3.1 Methods Restricted by Write Locks 597 A write lock MUST prevent a principal without the lock from 598 successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, 599 DELETE, or MKCOL on the locked resource. All other current methods, 600 GET in particular, function independently of the lock. 602 Note, however, that as new methods are created it will be necessary 603 to specify how they interact with a write lock. 605 B.3.2 Write Locks and Lock Tokens 607 A successful request for an exclusive or shared write lock MUST 608 result in the generation of a unique lock token associated with the 609 requesting principal. Thus if five principals have a shared write 610 lock on the same resource there will be five lock tokens, one for 611 each principal. 613 B.3.3 Write Locks and Properties 615 While those without a write lock may not alter a property on a 616 resource it is still possible for the values of live properties to 617 change, even while locked, due to the requirements of their schemas. 618 Only dead properties and live properties defined to respect locks are 619 guaranteed not to change while write locked. 621 B.3.4 Write Locks and Null Resources 623 It is possible to assert a write lock on a null resource in order to 624 lock the name. 626 A write locked null resource, referred to as a lock-null resource, 627 MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to 628 any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, 629 LOCK, and UNLOCK. A lock-null resource MUST appear as a member of 630 its parent collection. Additionally the lock-null resource MUST have 631 defined on it all mandatory DAV properties. Most of these 632 properties, such as all the get* properties, will have no value as a 633 lock-null resource does not support the GET method. Lock-Null 634 resources MUST have defined values for lockdiscovery and 635 supportedlock properties. 637 Until a method such as PUT or MKCOL is successfully executed on the 638 lock-null resource the resource MUST stay in the lock-null state. 639 However, once a PUT or MKCOL is successfully executed on a lock-null 640 resource the resource ceases to be in the lock-null state. 642 If the resource is unlocked, for any reason, without a PUT, MKCOL, or 643 similar method having been successfully executed upon it then the 644 resource MUST return to the null state. 646 B.3.5 Write Locks and Collections 648 A write lock on a collection, whether created by a "Depth: 0" or 649 "Depth: infinity" lock request, prevents the addition or removal of 650 member URIs of the collection by non-lock owners. As a consequence, 651 when a principal issues a PUT or POST request to create a new 652 resource under a URI which needs to be an internal member of a write 653 locked collection to maintain HTTP namespace consistency, or issues a 654 DELETE to remove a resource which has a URI which is an existing 655 internal member URI of a write locked collection, this request MUST 656 fail if the principal does not have a write lock on the collection. 658 However, if a write lock request is issued to a collection containing 659 member URIs identifying resources that are currently locked in a 660 manner which conflicts with the write lock, the request MUST fail 661 with a 423 (Locked) status code. 663 If a lock owner causes the URI of a resource to be added as an 664 internal member URI of a locked collection then the new resource MUST 665 be automatically added to the lock. This is the only mechanism that 666 allows a resource to be added to a write lock. Thus, for example, if 667 the collection /a/b/ is write locked and the resource /c is moved to 668 /a/b/c then resource /a/b/c will be added to the write lock. 670 B.3.6 Write Locks and the If Request Header 672 If a user agent is not required to have knowledge about a lock when 673 requesting an operation on a locked resource, the following scenario 674 might occur. Program A, run by User A, takes out a write lock on a 675 resource. Program B, also run by User A, has no knowledge of the 676 lock taken out by Program A, yet performs a PUT to the locked 677 resource. In this scenario, the PUT succeeds because locks are 678 associated with a principal, not a program, and thus program B, 679 because it is acting with principal A's credential, is allowed to 680 perform the PUT. However, had program B known about the lock, it 681 would not have overwritten the resource, preferring instead to 682 present a dialog box describing the conflict to the user. Due to 683 this scenario, a mechanism is needed to prevent different programs 684 from accidentally ignoring locks taken out by other programs with the 685 same authorization. 687 In order to prevent these collisions a lock token MUST be submitted 688 by an authorized principal in the If header for all locked resources 689 that a method may interact with or the method MUST fail. For 690 example, if a resource is to be moved and both the source and 691 destination are locked then two lock tokens must be submitted, one 692 for the source and the other for the destination. 694 B.3.6.1 Example - Write Lock 696 >>Request 698 COPY /~fielding/index.html HTTP/1.1 699 Host: www.ics.uci.edu 700 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 701 If: 702 () 704 >>Response 706 HTTP/1.1 204 No Content 708 In this example, even though both the source and destination are 709 locked, only one lock token must be submitted, for the lock on the 710 destination. This is because the source resource is not modified by 711 a COPY, and hence unaffected by the write lock. In this example, 712 user agent authentication has previously occurred via a mechanism 713 outside the scope of the HTTP protocol, in the underlying transport 714 layer. 716 B.3.7 Write Locks and COPY/MOVE 718 A COPY method invocation MUST NOT duplicate any write locks active on 719 the source. However, as previously noted, if the COPY copies the 720 resource into a collection that is locked with "Depth: infinity", 721 then the resource will be added to the lock. 723 A successful MOVE request on a write locked resource MUST NOT move 724 the write lock with the resource. However, the resource is subject 725 to being added to an existing lock at the destination, as specified 726 in Appendix B.3.5. For example, if the MOVE makes the resource a 727 child of a collection that is locked with "Depth: infinity", then the 728 resource will be added to that collection's lock. Additionally, if a 729 resource locked with "Depth: infinity" is moved to a destination that 730 is within the scope of the same lock (e.g., within the namespace tree 731 covered by the lock), the moved resource will again be a added to the 732 lock. In both these examples, as specified in Appendix B.3.6, an If 733 header must be submitted containing a lock token for both the source 734 and destination. 736 B.3.8 Refreshing Write Locks 738 A client MUST NOT submit the same write lock request twice. Note 739 that a client is always aware it is resubmitting the same lock 740 request because it must include the lock token in the If header in 741 order to make the request for a resource that is already locked. 743 However, a client may submit a LOCK method with an If header but 744 without a body. This form of LOCK MUST only be used to "refresh" a 745 lock. Meaning, at minimum, that any timers associated with the lock 746 MUST be re-set. 748 A server may return a Timeout header with a lock refresh that is 749 different than the Timeout header returned when the lock was 750 originally requested. Additionally clients may submit Timeout 751 headers of arbitrary value with their lock refresh requests. 752 Servers, as always, may ignore Timeout headers submitted by the 753 client. 755 If an error is received in response to a refresh LOCK request the 756 client SHOULD assume that the lock was not refreshed. 758 B.4 HTTP Headers for Distributed Authoring 760 B.4.1 LOCK Method 762 The following sections describe the LOCK method, which is used to 763 take out a lock of any access type. These sections on the LOCK 764 method describe only those semantics that are specific to the LOCK 765 method and are independent of the access type of the lock being 766 requested. 768 Any resource which supports the LOCK method MUST, at minimum, support 769 the XML request and response formats defined herein. 771 B.4.1.1 Operation 773 A LOCK method invocation creates the lock specified by the lockinfo 774 XML element on the Request-URI. Lock method requests SHOULD have a 775 XML request body which contains an owner XML element for this lock 776 request, unless this is a refresh request. The LOCK request may have 777 a Timeout header. 779 Clients MUST assume that locks may arbitrarily disappear at any time, 780 regardless of the value given in the Timeout header. The Timeout 781 header only indicates the behavior of the server if "extraordinary" 782 circumstances do not occur. For example, an administrator may remove 783 a lock at any time or the system may crash in such a way that it 784 loses the record of the lock's existence. The response MUST contain 785 the value of the lockdiscovery property in a prop XML element. 787 In order to indicate the lock token associated with a newly created 788 lock, a Lock-Token response header MUST be included in the response 789 for every successful LOCK request for a new lock. Note that the 790 Lock-Token header would not be returned in the response for a 791 successful refresh LOCK request because a new lock was not created. 793 B.4.1.2 The Effect of Locks on Properties and Collections 795 The scope of a lock is the entire state of the resource, including 796 its body and associated properties. As a result, a lock on a 797 resource MUST also lock the resource's properties. 799 For collections, a lock also affects the ability to add or remove 800 members. The nature of the effect depends upon the type of access 801 control involved. 803 B.4.1.3 Locking Replicated Resources 805 A resource may be made available through more than one URI. However 806 locks apply to resources, not URIs. Therefore a LOCK request on a 807 resource MUST NOT succeed if can not be honored by all the URIs 808 through which the resource is addressable. 810 B.4.1.4 Depth and Locking 812 The Depth header may be used with the LOCK method. Values other than 813 0 or infinity MUST NOT be used with the Depth header on a LOCK 814 method. All resources that support the LOCK method MUST support the 815 Depth header. 817 A Depth header of value 0 means to just lock the resource specified 818 by the Request-URI. 820 If the Depth header is set to infinity then the resource specified in 821 the Request-URI along with all its internal members, all the way down 822 the hierarchy, are to be locked. A successful result MUST return a 823 single lock token which represents all the resources that have been 824 locked. If an UNLOCK is successfully executed on this token, all 825 associated resources are unlocked. If the lock cannot be granted to 826 all resources, a 409 (Conflict) status code MUST be returned with a 827 response entity body containing a multistatus XML element describing 828 which resource(s) prevented the lock from being granted. Hence, 829 partial success is not an option. Either the entire hierarchy is 830 locked or no resources are locked. 832 If no Depth header is submitted on a LOCK request then the request 833 MUST act as if a "Depth:infinity" had been submitted. 835 B.4.1.5 Interaction with other Methods 837 The interaction of a LOCK with various methods is dependent upon the 838 lock type. However, independent of lock type, a successful DELETE of 839 a resource MUST cause all of its locks to be removed. 841 B.4.1.6 Lock Compatibility Table 843 The table below describes the behavior that occurs when a lock 844 request is made on a resource. 846 +-------------------------+--------------------+--------------------+ 847 | Current lock state / | Shared Lock | Exclusive Lock | 848 | Lock request | | | 849 +-------------------------+--------------------+--------------------+ 850 | None | True | True | 851 | Shared Lock | True | False | 852 | Exclusive Lock | False | False* | 853 +-------------------------+--------------------+--------------------+ 855 Legend: True = lock may be granted. False = lock MUST NOT be 856 granted. *=It is illegal for a principal to request the same lock 857 twice. 859 The current lock state of a resource is given in the leftmost column, 860 and lock requests are listed in the first row. The intersection of a 861 row and column gives the result of a lock request. For example, if a 862 shared lock is held on a resource, and an exclusive lock is 863 requested, the table entry is "false", indicating the lock must not 864 be granted. 866 B.4.1.7 Status Codes 868 200 (OK) - The lock request succeeded and the value of the 869 lockdiscovery property is included in the body. 871 412 (Precondition Failed) - The included lock token was not 872 enforceable on this resource or the server could not satisfy the 873 request in the lockinfo XML element. 875 423 (Locked) - The resource is locked, so the method has been 876 rejected. 878 B.4.1.8 Example - Simple Lock Request 880 >>Request 882 LOCK /workspace/webdav/proposal.doc HTTP/1.1 883 Host: webdav.sb.aol.com 884 Timeout: Infinite, Second-4100000000 885 Content-Type: text/xml; charset="utf-8" 886 Content-Length: xxxx 887 Authorization: Digest username="ejw", 888 realm="ejw@webdav.sb.aol.com", nonce="...", 889 uri="/workspace/webdav/proposal.doc", 890 response="...", opaque="..." 892 893 894 895 896 897 http://www.ics.uci.edu/~ejw/contact.html 898 899 901 >>Response 903 HTTP/1.1 200 OK 904 Content-Type: text/xml; charset="utf-8" 905 Content-Length: xxxx 907 908 909 910 911 912 913 Infinity 914 915 916 http://www.ics.uci.edu/~ejw/contact.html 917 918 919 Second-604800 920 921 922 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 923 924 925 926 927 929 This example shows the successful creation of an exclusive write lock 930 on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. 931 The resource http://www.ics.uci.edu/~ejw/contact.html contains 932 contact information for the owner of the lock. The server has an 933 activity-based timeout policy in place on this resource, which causes 934 the lock to automatically be removed after 1 week (604800 seconds). 935 Note that the nonce, response, and opaque fields have not been 936 calculated in the Authorization request header. 938 B.4.1.9 Example - Refreshing a Write Lock 940 >>Request 942 LOCK /workspace/webdav/proposal.doc HTTP/1.1 943 Host: webdav.sb.aol.com 944 Timeout: Infinite, Second-4100000000 945 If: () 946 Authorization: Digest username="ejw", 947 realm="ejw@webdav.sb.aol.com", nonce="...", 948 uri="/workspace/webdav/proposal.doc", 949 response="...", opaque="..." 951 >>Response 953 HTTP/1.1 200 OK 954 Content-Type: text/xml; charset="utf-8" 955 Content-Length: xxxx 957 958 959 960 961 962 963 Infinity 964 965 966 http://www.ics.uci.edu/~ejw/contact.html 967 968 969 Second-604800 970 971 972 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 973 974 975 976 977 979 This request would refresh the lock, resetting any time outs. Notice 980 that the client asked for an infinite time out but the server choose 981 to ignore the request. In this example, the nonce, response, and 982 opaque fields have not been calculated in the Authorization request 983 header. 985 B.4.1.10 Example - Multi-Resource Lock Request 987 >>Request 989 LOCK /webdav/ HTTP/1.1 990 Host: webdav.sb.aol.com 991 Timeout: Infinite, Second-4100000000 992 Depth: infinity 993 Content-Type: text/xml; charset="utf-8" 994 Content-Length: xxxx 995 Authorization: Digest username="ejw", 996 realm="ejw@webdav.sb.aol.com", nonce="...", 997 uri="/workspace/webdav/proposal.doc", 998 response="...", opaque="..." 1000 1001 1002 1003 1004 1005 http://www.ics.uci.edu/~ejw/contact.html 1006 1007 1009 >>Response 1011 HTTP/1.1 207 Multi-Status 1012 Content-Type: text/xml; charset="utf-8" 1013 Content-Length: xxxx 1015 1016 1017 1018 http://webdav.sb.aol.com/webdav/secret 1019 HTTP/1.1 403 Forbidden 1020 1021 1022 http://webdav.sb.aol.com/webdav/ 1023 1024 1025 HTTP/1.1 424 Failed Dependency 1026 1027 1028 1030 This example shows a request for an exclusive write lock on a 1031 collection and all its children. In this request, the client has 1032 specified that it desires an infinite length lock, if available, 1033 otherwise a timeout of 4.1 billion seconds, if available. The 1034 request entity body contains the contact information for the 1035 principal taking out the lock, in this case a web page URL. 1037 The error is a 403 (Forbidden) response on the resource 1038 http://webdav.sb.aol.com/webdav/secret. Because this resource could 1039 not be locked, none of the resources were locked. Note also that the 1040 lockdiscovery property for the Request-URI has been included as 1041 required. In this example the lockdiscovery property is empty which 1042 means that there are no outstanding locks on the resource. 1044 In this example, the nonce, response, and opaque fields have not been 1045 calculated in the Authorization request header. 1047 B.4.2 UNLOCK Method 1049 The UNLOCK method removes the lock identified by the lock token in 1050 the Lock-Token request header from the Request-URI, and all other 1051 resources included in the lock. If all resources which have been 1052 locked under the submitted lock token can not be unlocked then the 1053 UNLOCK request MUST fail. 1055 Any DAV compliant resource which supports the LOCK method MUST 1056 support the UNLOCK method. 1058 B.4.2.1 Example - UNLOCK 1060 >>Request 1062 UNLOCK /workspace/webdav/info.doc HTTP/1.1 1063 Host: webdav.sb.aol.com 1064 Lock-Token: 1065 Authorization: Digest username="ejw", 1066 realm="ejw@webdav.sb.aol.com", nonce="...", 1067 uri="/workspace/webdav/proposal.doc", 1068 response="...", opaque="..." 1070 >>Response 1072 HTTP/1.1 204 No Content 1074 In this example, the lock identified by the lock token 1075 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 1076 successfully removed from the resource 1077 http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock 1078 included more than just one resource, the lock is removed from all 1079 resources included in the lock. The 204 (No Content) status code is 1080 used instead of 200 (OK) because there is no response entity body. 1082 In this example, the nonce, response, and opaque fields have not been 1083 calculated in the Authorization request header. 1085 B.5 HTTP Headers for Distributed Authoring 1087 B.5.1 DAV Header 1089 [[anchor47: Add description of compliance class "2". --reschke]] 1091 B.5.2 Depth Header 1093 [[anchor48: Add "Depth" header considerations: --reschke]] 1095 If a resource, source or destination, within the scope of the method 1096 with a Depth header is locked in such a way as to prevent the 1097 successful execution of the method, then the lock token for that 1098 resource MUST be submitted with the request in the If request header. 1100 B.5.3 If Header 1102 [[anchor49: Add "If" header considerations: --reschke]] 1104 B.5.4 Lock-Token Header 1106 Lock-Token = "Lock-Token" ":" Coded-URL 1108 The Lock-Token request header is used with the UNLOCK method to 1109 identify the lock to be removed. The lock token in the Lock-Token 1110 request header MUST identify a lock that contains the resource 1111 identified by Request-URI as a member. 1113 The Lock-Token response header is used with the LOCK method to 1114 indicate the lock token created as a result of a successful LOCK 1115 request to create a new lock. 1117 B.5.5 Timeout Request Header 1119 TimeOut = "Timeout" ":" 1#TimeType 1120 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) 1121 DAVTimeOutVal = 1*digit 1122 Other = "Extend" field-value ; See section 4.2 of [RFC2068] 1124 Clients may include Timeout headers in their LOCK requests. However, 1125 the server is not required to honor or even consider these requests. 1126 Clients MUST NOT submit a Timeout request header with any method 1127 other than a LOCK method. 1129 A Timeout request header MUST contain at least one TimeType and may 1130 contain multiple TimeType entries. The purpose of listing multiple 1131 TimeType entries is to indicate multiple different values and value 1132 types that are acceptable to the client. The client lists the 1133 TimeType entries in order of preference. 1135 Timeout response values MUST use a Second value, Infinite, or a 1136 TimeType the client has indicated familiarity with. The server may 1137 assume a client is familiar with any TimeType submitted in a Timeout 1138 header. 1140 The "Second" TimeType specifies the number of seconds that will 1141 elapse between granting of the lock at the server, and the automatic 1142 removal of the lock. The timeout value for TimeType "Second" MUST 1143 NOT be greater than 2^32-1. 1145 The timeout counter SHOULD be restarted any time an owner of the lock 1146 sends a method to any member of the lock, including unsupported 1147 methods, or methods which are unsuccessful. However the lock MUST be 1148 refreshed if a refresh LOCK method is successfully received. 1150 If the timeout expires then the lock may be lost. Specifically, if 1151 the server wishes to harvest the lock upon time-out, the server 1152 SHOULD act as if an UNLOCK method was executed by the server on the 1153 resource using the lock token of the timed-out lock, performed with 1154 its override authority. Thus logs should be updated with the 1155 disposition of the lock, notifications should be sent, etc., just as 1156 they would be for an UNLOCK request. 1158 Servers are advised to pay close attention to the values submitted by 1159 clients, as they will be indicative of the type of activity the 1160 client intends to perform. For example, an applet running in a 1161 browser may need to lock a resource, but because of the instability 1162 of the environment within which the applet is running, the applet may 1163 be turned off without warning. As a result, the applet is likely to 1164 ask for a relatively small timeout value so that if the applet dies, 1165 the lock can be quickly harvested. However, a document management 1166 system is likely to ask for an extremely long timeout because its 1167 user may be planning on going off-line. 1169 A client MUST NOT assume that just because the time-out has expired 1170 the lock has been lost. 1172 B.6 Status Code Extensions to HTTP/1.1 1174 B.6.1 423 Locked 1176 The 423 (Locked) status code means the source or destination resource 1177 of a method is locked. 1179 B.7 XML Element Definitions 1181 B.7.1 activelock XML Element 1183 Name: activelock 1185 Namespace: DAV: 1187 Purpose: Describes a lock on a resource. 1189 1192 B.7.1.1 depth XML Element 1194 Name: depth 1196 Namespace: DAV: 1198 Purpose: The value of the Depth header. 1200 Value: "0" | "1" | "infinity" 1202 1204 B.7.1.2 locktoken XML Element 1206 Name: locktoken 1208 Namespace: DAV: 1210 Purpose: The lock token associated with a lock. Description: The 1211 href contains one or more opaque lock token URIs which all refer 1212 to the same lock (i.e., the OpaqueLockToken-URI production in 1213 Appendix B.2.4). 1215 1217 B.7.1.3 timeout XML Element 1218 Name: timeout 1220 Namespace: DAV: 1222 Purpose: The timeout associated with a lock 1224 Value: TimeType ;Defined in Appendix B.5.5 1226 1228 B.7.2 lockentry XML Element 1230 Name: lockentry 1232 Namespace: DAV: 1234 Purpose: Defines the types of locks that can be used with the 1235 resource. 1237 1239 B.7.3 lockinfo XML Element 1241 Name: lockinfo 1243 Namespace: DAV: 1245 Purpose: The lockinfo XML element is used with a LOCK method to 1246 specify the type of lock the client wishes to have created. 1248 1250 B.7.4 lockscope XML Element 1252 Name: lockscope 1254 Namespace: DAV: 1256 Purpose: Specifies whether a lock is an exclusive lock, or a shared 1257 lock. 1259 1261 B.7.4.1 exclusive XML Element 1263 Name: exclusive 1265 Namespace: DAV: 1267 Purpose: Specifies an exclusive lock 1269 1271 B.7.4.2 shared XML Element 1273 Name: shared 1275 Namespace: DAV: 1277 Purpose: Specifies a shared lock 1279 1281 B.7.5 locktype XML Element 1283 Name: locktype 1285 Namespace: DAV: 1287 Purpose: Specifies the access type of a lock. At present, this 1288 specification only defines one lock type, the write lock. 1290 1292 B.7.5.1 write XML Element 1294 Name: write 1296 Namespace: DAV: 1298 Purpose: Specifies a write lock. 1300 1302 B.7.6 owner XML Element 1304 Name: owner 1306 Namespace: DAV: 1308 Purpose: Provides information about the principal taking out a lock. 1310 Description: The owner XML element provides information sufficient 1311 for either directly contacting a principal (such as a telephone 1312 number or Email URI), or for discovering the principal (such as 1313 the URL of a homepage) who owns a lock. 1315 1317 B.8 DAV Properties 1319 B.8.1 lockdiscovery Property 1321 Name: lockdiscovery 1323 Namespace: DAV: 1325 Purpose: Describes the active locks on a resource 1327 Description: The lockdiscovery property returns a listing of who has 1328 a lock, what type of lock he has, the timeout type and the time 1329 remaining on the timeout, and the associated lock token. The 1330 server is free to withhold any or all of this information if the 1331 requesting principal does not have sufficient access rights to see 1332 the requested data. 1334 1336 B.8.1.1 Example - Retrieving the lockdiscovery Property 1338 >>Request 1340 PROPFIND /container/ HTTP/1.1 1341 Host: www.foo.bar 1342 Content-Length: xxxx 1343 Content-Type: text/xml; charset="utf-8" 1345 1346 1347 1348 1350 >>Response 1352 HTTP/1.1 207 Multi-Status 1353 Content-Type: text/xml; charset="utf-8" 1354 Content-Length: xxxx 1356 1357 1358 1359 http://www.foo.bar/container/ 1360 1361 1362 1363 1364 1365 1366 0 1367 Jane Smith 1368 Infinite 1369 1370 1371 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 1372 1373 1374 1375 1376 1377 HTTP/1.1 200 OK 1378 1379 1380 1382 This resource has a single exclusive write lock on it, with an 1383 infinite timeout. 1385 B.8.2 supportedlock Property 1387 Name: supportedlock 1389 Namespace: DAV: 1391 Purpose: To provide a listing of the lock capabilities supported by 1392 the resource. 1394 Description: The supportedlock property of a resource returns a 1395 listing of the combinations of scope and access types which may be 1396 specified in a lock request on the resource. Note that the actual 1397 contents are themselves controlled by access controls so a server 1398 is not required to provide information the client is not 1399 authorized to see. 1401 1403 B.8.2.1 Example - Retrieving the supportedlock Property 1405 >>Request 1407 PROPFIND /container/ HTTP/1.1 1408 Host: www.foo.bar 1409 Content-Length: xxxx 1410 Content-Type: text/xml; charset="utf-8" 1412 1413 1414 1415 1417 >>Response 1419 HTTP/1.1 207 Multi-Status 1420 Content-Type: text/xml; charset="utf-8" 1421 Content-Length: xxxx 1423 1424 1425 1426 http://www.foo.bar/container/ 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 HTTP/1.1 200 OK 1441 1442 1443 1445 B.9 DAV Compliance Classes 1447 B.9.1 Class 2 1449 A class 2 compliant resource MUST meet all class 1 requirements and 1450 support the LOCK method, the supportedlock property, the 1451 lockdiscovery property, the Time-Out response header and the 1452 Lock-Token request header. A class "2" compliant resource SHOULD 1453 also support the Time-Out request header and the owner XML element. 1455 Class 2 compliant resources MUST return, at minimum, the values "1" 1456 and "2" in the DAV header on all responses to the OPTIONS method. 1458 B.10 Security Considerations 1460 B.10.1 Authentication of Clients 1462 Furthermore, the introduction of locking functionality requires 1463 support for authentication. 1465 B.10.2 Privacy Issues Connected to Locks 1467 When submitting a lock request a user agent may also submit an owner 1468 XML field giving contact information for the person taking out the 1469 lock (for those cases where a person, rather than a robot, is taking 1470 out the lock). This contact information is stored in a lockdiscovery 1471 property on the resource, and can be used by other collaborators to 1472 begin negotiation over access to the resource. However, in many 1473 cases this contact information can be very private, and should not be 1474 widely disseminated. Servers SHOULD limit read access to the 1475 lockdiscovery property as appropriate. Furthermore, user agents 1476 SHOULD provide control over whether contact information is sent at 1477 all, and if contact information is sent, control over exactly what 1478 information is sent. 1480 B.11 IANA Considerations 1482 This specification also defines a URI scheme for the encoding of lock 1483 tokens, the opaquelocktoken URI scheme described in Appendix B.2.4. 1485 Appendix C. GULP 1487 *Copied from *[3]. 1489 o A lock either directly or indirectly locks a resource. 1491 o A LOCK request with a non-empty body creates a new lock, and the 1492 resource identified by the request-URL is directly locked by that 1493 lock. The "lock-root" of the new lock is the request-URL. If at 1494 the time of the request, the request-URL is not mapped to a 1495 resource, a new resource with no content MUST be created by the 1496 request. 1498 o If a collection is directly locked by a depth:infinity lock, all 1499 members of that collection (other than the collection itself) are 1500 indirectly locked by that lock. In particular, if an internal 1501 member resource is added to a collection that is locked by a 1502 depth:infinity lock, and if the resource is not locked by that 1503 lock, then the resource becomes indirectly locked by that lock. 1504 Conversely, if a resource is indirectly locked with a 1505 depth:infinity lock, and if the result of deleting an internal 1506 member URI is that the resource is no longer a member of the 1507 collection that is directly locked by that lock, then the resource 1508 is no longer locked by that lock. 1510 o An UNLOCK request deletes the lock with the specified lock token. 1511 The request-URL of the request MUST identify the resource that is 1512 directly locked by that lock. After a lock is deleted, no 1513 resource is locked by that lock. 1515 o A lock token is "submitted" in a request when it appears in an If 1516 header. 1518 o If a request would modify the content for a locked resource, a 1519 dead property of a locked resource, a live property that is 1520 defined to be lockable for a locked resource, or an internal 1521 member URI of a locked collection, the request MUST fail unless 1522 the lock-token for that lock is submitted in the request. An 1523 internal member URI of a collection is considered to be modified 1524 if it is added, removed, or identifies a different resource. 1526 o If a request causes a directly locked resource to no longer be 1527 mapped to the lock-root of that lock, then the request MUST fail 1528 unless the lock-token for that lock is submitted in the request. 1529 If the request succeeds, then that lock MUST have been deleted by 1530 that request. 1532 o If a request would cause a resource to be locked by two different 1533 exclusive locks, the request MUST fail. 1535 Appendix D. Resolved issues (to be removed by RFC Editor before 1536 publication) 1538 Issues that were either rejected or resolved in this version of this 1539 document. 1541 D.1 040_LOCK_ISSUES 1543 Type: change 1545 1547 ccjason@us.ibm.com (1999-06-07): Jason Crawford's list of lock issues 1548 sent to the list. 1550 Resolution: Replace with list of distinct issues 040_LOCK_ISSUES_??. 1552 D.2 058_LOCK_SEIZURE 1554 Type: change 1556 (): Should it be possible to seize a lock, or for any principal to 1557 unlock a lock, thus making it easier for another client to begin 1558 working on a locked resource. 1560 Resolution: Duplicated by UNLOCK_BY_NON_LOCK_OWNER issue. 1562 D.3 093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK 1564 Type: change 1566 1568 dbrotsky@adobe.com (): How does a client determine if a given lock 1569 was created by it? 1571 Resolution: It was resolved that this type of info would not be 1572 provided by the server. The client creating the lock could store 1573 owner info in the DAV:owner field (or some field defined in the 1574 future) if it wishes. The querying client can also check ACL's to 1575 get similar info. 1577 D.4 096_SHARED_LOCKS_INTEROP_NOT_TESTED 1579 Type: change 1581 1583 lisa@xythos.com (): There might not be any implementations of shared 1584 locks. If so, remove them. 1586 Resolution: The thread did conclude that shared locks interoperate 1587 although it doesn't look like they get used much. Also see: 1588 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0139.html. 1590 Appendix E. Open issues (to be removed by RFC Editor prior to 1591 publication) 1593 E.1 extract-locking 1595 Type: change 1597 julian.reschke@greenbytes.de (2004-04-14): Locking extracted from 1598 RFC2518. 1600 E.2 updated-rfc2068 1602 Type: change 1604 julian.reschke@greenbytes.de (2004-04-25): Update references of 1605 RFC2068 to either RFC2396 or RFC2616. 1607 E.3 import-rfc3253-stuff 1609 Type: change 1611 julian.reschke@greenbytes.de (2004-04-25): Import error marshalling 1612 and terminology from RFC3253. 1614 E.4 008_URI_URL 1616 Type: change 1618 1620 masinter@parc.xerox.com (1998-11-09): Perform a thorough review of 1621 the specification to ensure that URI and URL are used correctly, and 1622 consistently throughout. 1624 Resolution: Seems to have been deferred: 1625 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html, 1626 but there is some follow on discussion on what exactly needs to be 1627 clarified: 1628 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html, 1629 but no specific action was concluded besides the fact that we don't 1630 need to wait for RFC2396 to be updated or request any changes/ 1631 clarifications to that. 1633 E.5 015_MOVE_SECTION_6.4.1_TO_APPX 1635 Type: change 1637 1639 mda@discerning.com (1998-11-24): The discussion of generating UUID 1640 node fields without using the IEEE 802 address in section 6.4.1 can 1641 be moved to an appendix. 1643 julian.reschke@greenbytes.de (2004-04-24): Plan: get rid of the 1644 section altogether and refer to draft-mealling-uuid-urn. 1646 E.6 022_COPY_OVERWRITE_LOCK_NULL 1648 Type: change 1650 1651 jdavis@parc.xerox.com (1998-11-29): If URL Ub is locked, creating a 1652 lock-null resource, then if a COPY is performed listing Ub as the 1653 destination, COPY will remove the lock-null resource, removing the 1654 lock, then perform the copy. A note needs to be added stating that 1655 the delete performed by the Overwrite header is atomic with the rest 1656 of the operation. 1658 Resolution: LNRs removed. See discussions preceding conclusion: 1659 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html. 1661 E.7 025_LOCK_REFRESH_BY_METHODS 1663 Type: change 1665 (): Jim Amsden: The specification requires a lock to be refreshed if 1666 any method is executed, by anybody, on a locked resource. This can 1667 cause some performance problems. More importantly, the semantics of 1668 this refresh do not seem to be right -- why should a random GET by a 1669 third party cause all locks to be refreshed? 1671 Resolution: We should remove the mention of this behavior in 2518: 1672 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0137.html 1674 E.8 037_DEEP_LOCK_ERROR_STATUS 1676 Type: change 1678 1680 wiggs@wiggenout.com (1999-05-18): Section 8.10.4 states that if a 1681 lock cannot be granted to all resources in a hierarchy, a 409 status 1682 response must be issued. Yet, the example in section 8.10.10 which 1683 demonstrates this uses a 207. 1685 julian.reschke@greenbytes.de (2004-04-24): Comment: 207 is correct, 1686 fix the bad spec text. 1688 E.9 039_MISSING_LOCK_TOKEN 1690 Type: change 1692 1693 (1999-06-15): Keith Wannamaker: Section 8.10.1 explicitly states that 1694 the response from a successful lock request MUST include the 1695 Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10 1696 aren't compliant with this requirement, and should be updated. 1698 Resolution: Make obvious editing changes to the examples: 1699 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0229.html 1701 E.10 040_LOCK_ISSUES_01 1703 Type: change 1705 1707 ccjason@us.ibm.com (1999-06-07): Section 6.3: ""Having a lock token 1708 provides no special access rights..." I suggest that the phrase 1709 "owned by another party" be added in this first sentence to 1710 distinguish between owning and having. It speaks of "having" in this 1711 sentence but not subsequently. In fact "submitting" might be an even 1712 better word than having. 1714 julian.reschke@greenbytes.de (2004-04-24): Agreed, use "submitting". 1716 E.11 040_LOCK_ISSUES_02 1718 Type: change 1720 1722 ccjason@us.ibm.com (1999-06-07): Section 6.3: "... However resource 1723 are free to return any URI scheme so long as it meets the uniqueness 1724 requirements." This is technically correct, but it might also be 1725 useful to say that the scheme should make the URI be readily 1726 recognizable as a *LOCK* state token in the event that other types of 1727 state tokens exist. I mention this because we seem to have created 1728 the possibility of other types of state tokens. -- Your call. :-) 1730 julian.reschke@greenbytes.de (2004-04-24): Disagreement: any URI 1731 scheme can be used as a lock token. Specifications that define other 1732 types of state tokens will have to take care of distinguishing them 1733 inside an "If" header. 1735 E.12 040_LOCK_ISSUES_03 1737 Type: change 1738 1740 ccjason@us.ibm.com (1999-06-07): Section 7.1 Write lock. I believe 1741 this definition of a write lock is not right... or not complete... 1742 judging from what I read elsewhere. I believe one can do these 1743 operations without a write lock... as long as someone else doesn't 1744 have a write lock on the resources effected. I also believe it 1745 doesn't prevent LOCK requests in the case of shared locks. 1747 julian.reschke@greenbytes.de (2004-04-24): Clarify as part of 1748 rewriting the general semantics. The point about shared locks is 1749 correct, though. 1751 E.13 040_LOCK_ISSUES_04 1753 Type: change 1755 1757 ccjason@us.ibm.com (1999-06-07): Section 7.5 Write Locks and 1758 Collections. It says that if members are locked in a conflicting 1759 manner, then their collection can't be locked. That seems 1760 ambiguously safe to say, but I suspect that text should mention depth 1761 since if the parent lock request is depth 0, I don't think we let the 1762 members lock state effect the success of the LOCK request. The 1763 possible exception is what we said about protecting a URI that was 1764 used to perform a lock (of a member of the collection). I'm not sure 1765 what we'd like to say for that. In the advanced collection meetings 1766 we refered to these being "protected" and avoided speaking about 1767 "lock"ing the URI. This creates an odd situation though. 1769 E.14 040_LOCK_ISSUES_05 1771 Type: change 1773 1775 ccjason@us.ibm.com (1999-06-07): 7.7 Write Locks and COPY/MOVE It 1776 says that a lock doesn't move with a moved resource. Of course if 1777 the lock is on the resource, not the URI, it should move with the 1778 resource. But then we have the caveat that we are also protecting 1779 the LOCK'd URI. I think the rule should be that if we submit the 1780 locktoken with the MOVE request, we are allowed to have the LOCK move 1781 with the resource and the lock will now protect a different URI. 1782 Also, ALL locks in the subtree must be submitted or the MOVE must 1783 fail because otherwise it would break our URI protection rule. 1785 julian.reschke@greenbytes.de (2004-04-24): Clarify as part of 1786 incorporating GULP (locks do not MOVE). 1788 E.15 040_LOCK_ISSUES_06 1790 Type: change 1792 1794 ccjason@us.ibm.com (1999-06-07): Upon cursory reading of the rfc 2518 1795 sec 8.10.4 through 8.11 I was confused by the plethoria of error 1796 codes. Nothing seems to unify them. 8.10.4 speaks of a return code 1797 of 409 Conflict if a lock can't be granted. - Firstly, I can't tell 1798 if it is saying that the 409 is within the multistatus body... or in 1799 the response header. - Secondly, later text seems to use a different 1800 status codes and never mentions this one again. 8.10.7 lists status 1801 codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed, 1802 but 409 Conflict (mentioned above) is not. - In the case of 412 1803 Precondition Failed, the description the follows doesn't seem to 1804 describe a "precondition failed". And it sounds like it's talking 1805 about an access request that includes a "locktoken", not a LOCK 1806 request that generates one. - The 423 Locked condition also sort of 1807 sounds like it's talking about an access request rather than a LOCK 1808 request. 8.10.10 lists LOCK status codes - 207 Multistatus which was 1809 not mentioned above - 403 Forbidden which was not mentioned above. 1810 - 424 Failed dependency which was not mentioned above. 8.11 UNLOCK 1811 - we don't mention what the failure response should look like. - 1812 comment: 200 OK seems like a better response than 204 No Content. 1813 The brief explanation isn't persuasive and seems to say that the 1814 response code should serve the purpose of the Content-Length. 1815 header. - we should probably explicitly say if an UNLOCK can only be 1816 done on the original resource... and will fail even if the resource 1817 specified is locked by virtue of being a child of the original 1818 resource. Or is this too obvious? I know it's something easy to 1819 goof up in an implementation. 1821 E.16 040_LOCK_ISSUES_07 1823 Type: change 1825 1827 ccjason@us.ibm.com (1999-06-07): 9.4 If header - BNF suggests that 1828 IF's content must be all tagged or all untagged. - doesn't say if 1829 there can be two If headers in a request. Might we want a tagged one 1830 and an untagged one? - I must be misunderstanding this, but it sounds 1831 to me like that state of a resource(s) must match one of the 1832 locktokens listed in the request. But what if some of the resources 1833 are locked and others are not. The unlocked resources definitely 1834 won't contain state that's listed. Are we precluding operations on 1835 regions that might not be entirely locked? -- Is this a valid 1836 observation or a red herring? 9.4.1.1 If header - untagged example - 1837 See my comment about regions that are not entirely locked. 9.4.2 If 1838 header -tagged state - So if we've applied a lock with depth.... and 1839 now we're doing a DELETE on a subtree of that tree and we've tagged 1840 the locktoken we've submitted, will this prevent that locktoken from 1841 apply'ing to ALL the resources of the subtree... and thus prevent 1842 the COPY from succeeding? Or are we supposed to tag the lock token 1843 with the root of the LOCK even if that is not part of what we are 1844 deleting? Or should the request use untagged locktokens? 9.4.3 If 1845 header - NOT operator - Why do we want this? of course... why not? 1846 :-) Overall, the If header seems backwards for locktokens. It's 1847 client driven rather than server semantics driven. The only feature 1848 it seems to provide is perhaps the ability for the client to request 1849 that the request be aborted if the resource no longer is locked. 1850 Other than that it seems to complicate the simple process of letting 1851 the server know what tokens you hold. I'd think we'd just want a 1852 different header to declare what lock tokens we hold and let the 1853 server (not the client) decide how they affect the success of the 1854 request. 1856 julian.reschke@greenbytes.de (2004-04-24): This issue needs to be 1857 handled in the base protocol. 1859 E.17 040_LOCK_ISSUES_08 1861 Type: change 1863 1865 ccjason@us.ibm.com (1999-06-07): Shared locks... read locks... Our 1866 justifcation for shared locks ("Shared locks are included 1867 because....") seems faulty. It's not a mechansim for dealing with 1868 programs that forget to release their locks. That remains a problem 1869 with shared locks. In this case they'd forget to release a shared 1870 lock and block exclusive lock users. Timeouts and administrative 1871 action are the solutions to this problem... not shared locks. BTW, 1872 I'd think that the use of exclusive locks is just fine. I do have a 1873 problem with shared locks though... or at least shared write locks. 1874 Although they were relatively easy to define, I see them as solving a 1875 red herring problem of multiple entites cooperatively writing using 1876 distinct locks. I say it's a red herring because they don't know 1877 each other well enough to use the same lock but they do know each 1878 other well enough to not step on each other. This seems unlikely. 1879 As does the managing a compatibility matrix and getting all the 1880 entities to abide by it. OTOH I see another more common problem that 1881 is being overlooked. I see a class of folks whose purpose is to not 1882 actually write to a (set of) resource(s), but to simply prevent 1883 others from writing to it while they are looking at it. Shared write 1884 locks do not necessarily do that because with a shared write lock. 1885 someone else could grab a shared lock and go ahead and write. The 1886 only way to block that is to get an exclusive write lock. But doing 1887 that prevents anyone else from doing what you're doing despite it 1888 being pretty benign. An expedient solution is to say that a shared 1889 write lock should not necessarily give one the right to modify a 1890 resource. All it should do is prevent others from writing. And then 1891 the purpose of an exclusive write lock is just to insure that others 1892 can't get a lock and block you from writing. Now is this the right 1893 solution? Probably not. There probably should be something called a 1894 read lock that actually prevents writes as a side effect.... and 1895 would tend to get used in shared mode. Anyway, as it is, I think the 1896 shared write locks are a red herring and we're missing something we 1897 are more likely to need... shared read locks. 1899 julian.reschke@greenbytes.de (2004-04-24): Agreement that the 1900 rational for shared locks either needs to be rewritten or deleted. 1901 However shared locks are a fact, and we shouldn't change the 1902 semantics given in RFC2518. 1904 E.18 043_NULL_LOCK_SLASH_URL 1906 Type: change 1908 1910 wiggs@xythos.com (1999-07-23): If a URL ending in a slash is null 1911 locked, is it legal to do a PUT to it? That is, does the URL ending 1912 in slash set the resource type to a collection, or does the first 1913 PUT/MKCOL set the resource to a ordinary, or collection resource. 1915 Resolution: LNRs removed. See discussions preceding conclusion: 1916 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html 1918 E.19 044_REPORT_OTHER_RESOURCE_LOCKED 1920 Type: change 1921 1923 wiggs@xythos.com (1999-07-23): In some cases, such as when the parent 1924 collection of a resource is locked, a 423 (Locked) status code is 1925 returned even though the resource identified by the Request-URI is 1926 not locked. This can be confusing, since it is not possible for a 1927 client to easily discover which resource is causing the locked status 1928 code to be returned. An improved status report would indicate the 1929 resource causing the lock message. 1931 julian.reschke@greenbytes.de (2004-04-25): Proposal to define a 1932 specific precondition element plus specific child elements similar to 1933 ACL, section 7.1.1. 1935 E.20 052_LOCK_BODY_SHOULD_BE_MUST 1937 Type: change 1939 1941 gstein@lyra.org (1999-11-23): Section 8.10.1 states that a LOCK 1942 method request SHOULD have an XML request body. This SHOULD should 1943 instead be MUST. 1945 julian.reschke@greenbytes.de (2004-04-25): Clarify that for creating 1946 LOCKs, it MUST have a request body which SHOULD have the DAV:owner 1947 element. For LOCK refreshes, no body is required. 1949 E.21 053_LOCK_INHERITANCE 1951 Type: change 1953 1955 jrd3@alum.mit.edu (1999-11-26): Section 7.5 states, "If a lock owner 1956 causes the URI of a resource to be added as an internal member URI of 1957 a locked collection then the new resource MUST be automatically added 1958 to the lock." However, though this is the intent, the specification 1959 does not explicitly state that this behavior only applies to depth 1960 infinity locked collections. The words "Depth infinity" should be 1961 added before the word "locked" in this sentence. 1963 julian.reschke@greenbytes.de (2004-04-25): Clarify as part of 1964 integrating GULP. 1966 E.22 054_IF_AND_AUTH 1968 Type: change 1970 1972 geoffrey.clemm@rational.com (2000-01-27): The fact that use of 1973 authentication credentials with submission of lock tokens is required 1974 should be strengthened in the document. 1976 julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token 1977 in an If header (usages != UNLOCK) SHOULD be restricted to whatever 1978 the server thinks the "owner" of the lock is. 1980 E.23 056_DEPTH_LOCK_AND_IF 1982 Type: change 1984 1986 joe@orton.demon.co.uk (2000-03-04): The specification is currently 1987 silent on how to use the If header for submitting a locktoken when 1988 performing a DELETE in a Depth infinity locked collection. Should 1989 the If header have both the collection URL and the Request-URI, or 1990 just the Request-URI? An example of this is needed. 1992 julian.reschke@greenbytes.de (2004-04-25): Clarify as part of 1993 integrating GULP. May need to test interop with existing 1994 implementations. 1996 E.24 057_LOCK_SEMANTICS 1998 Type: change 2000 (): At present, the WebDAV specification is not excruciatingly 2001 explicit that writing to a locked resource requires the combination 2002 of the lock token, plus an authentication principal. At one point, 2003 the spec. discusses an "authorized" principal, but "authorized" is 2004 never explicitly defined. 2006 julian.reschke@greenbytes.de (2004-05-02): Submitting the lock token 2007 in an If header (usages != UNLOCK) SHOULD be restricted to whatever 2008 the server thinks the "owner" of the lock is. 2010 E.25 060_LOCK_REFRESH_BODY 2012 Type: change 2013 2015 rickard.falk@excosoft.se (2000-07-11): Section 7.8 of RFC 2518 2016 indicates that clients may submit a lock refresh without a body. 2017 However, it implies that clients could submit a lock refresh with a 2018 body. Server implementations have been disallowing a lock refresh 2019 with a body. It might make sense to codify this practice, and 2020 disallow submission of a body on a lock refresh. 2022 julian.reschke@greenbytes.de (2004-04-25): Clarify that LOCK refresh 2023 MUST NOT have a request body. Also clarify Lock-Token header vs If 2024 header. 2026 E.26 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY 2028 Type: change 2030 jrd3@alum.mit.edu (): Is the complexity of the IF header appropriate 2031 for the simple task o verifying that a client knowingly owns a lock? 2032 The IF header seems to serve a different purpose. One of those 2033 purposes is for the server to verify that you have the lock token 2034 (and that you know the root of it?). Another is for the client to 2035 check some preconditions before doing an action. Another seems to be 2036 to specify what lock to refresh in a lock refresh request. This 2037 seems to create ambiguity in our definition of the semantics of the 2038 IF: header. 2040 ccjason@us.ibm.com (): It is felt by the group that it's important 2041 that the client not just own and hold the lock token, but that it 2042 also know where the lock is rooted before it does tasks related to 2043 that lock. This still leaves the lock referesh issue unresolved. 2045 julian.reschke@greenbytes.de (2004-04-25): Need Lock-Token header to 2046 indicate the lock to be refreshed. 2048 E.27 065_UNLOCK_WHAT_URL 2050 Type: change 2052 2054 Juergen.Pill@softwareag.com (): What do you return if the unlock 2055 request specifies a URL on which the lock does not reside? What if 2056 it's on a URL that is locked by the lock, but it's not the resource 2057 where the lock is rooted? 2058 Resolution: Resolved that you can specify any URL locked by the lock 2059 you want to unlock. 2060 (http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html) 2061 We should resolve the issue of UNLOCK'ing other URLs in a few days. 2063 E.28 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL 2065 Type: change 2067 (): Right now the server uses the IF: header to verify that a client 2068 knows what locks it has that are affected by an operation before it 2069 allows the operation. Must the client provide the root URL of a 2070 lock, any URL for a pertainent loc, or some specific URL in the IF: 2071 header. 2073 ccjason@us.ibm.com (): It is felt by the group that it's important 2074 that the client not just own and hold the lock token, but that it 2075 also know where the lock is rooted before it does tasks related to 2076 that lock. This is just a point of info. The issue itself still 2077 needs to be brought up and answered.still 2079 E.29 067_UNLOCK_NEEDS_IF_HEADER 2081 Type: change 2083 2085 dbrotsky@Adobe.COM (): Shouldn't we be using an IF header to do an 2086 UNLOCK seeing as you need to prove you are holding a lock before you 2087 can remove it? (This might be contingent on 2088 LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) 2090 E.30 068_UNLOCK_WITHOUT_GOOD_TOKEN 2092 Type: change 2094 2096 dbrotsky@Adobe.COM (): What should UNLOCK return if a bad token is 2097 provided or no token. (This might be contingent on 2098 UNLOCK_NEEDS_IF_HEADER.) 2100 E.31 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER 2102 Type: change 2103 2105 dbrotsky@Adobe.COM (): The LOCK renewal request should not us an IF 2106 header to specify what lock is being renewed. This limits the use of 2107 the IF header. 2109 julian.reschke@greenbytes.de (2004-04-25): Need Lock-Token header to 2110 indicate the lock to be refreshed. 2112 E.32 072_LOCK_URL_WITH_NO_PARENT_COLLECTION 2114 Type: change 2116 2118 dbrotsky@Adobe.COM (): If a LOCK request is submitted to a URL that 2119 doesn't have a parent collection, what should be the correct 2120 response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409 2121 response in this case. Seems like LOCK should have this requirement 2122 as well. 2124 Resolution: Resolved that since LNRs no longer exist (see 2125 NULL_RESOURCE_CLARIFY) the server should return 409. We should 2126 insure that the new text we add to replace LNRs does not create an 2127 ambiguity: 2128 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html 2130 E.33 073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE 2132 Type: change 2134 2136 hwarncke@Adobe.COM (): If the DAV:lockdiscovery property is requested 2137 from an unlocked resource, what is the correct response? Apache 2138 mod_dav responds with an empty mod_dav sends an empty lockdiscovery 2139 element () while IIS sends an empty prop element 2140 (), that is, it sends no lockdiscovery element at all. 2142 julian.reschke@greenbytes.de (2004-04-25): The difference shouldn't 2143 matter for clients, and they need to expect both. In general, 2144 servers that DO support locks on that resource should return an empty 2145 element. 2147 E.34 077_LOCK_NULL_STATUS_CREATION 2149 Type: change 2151 2153 lisa@xythos.com (): What status code should be returned when a lock 2154 null resource is created - 200 OK or 201 Created? A related issue is 2155 what status code should be returned by a PUT or MKCOL on a lock-null 2156 resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201 2157 seems like a slightly better choice). 2159 Resolution: Resolved via the proposal to remove LNR and replace them 2160 with ordinary resources and by the following wording: 2161 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html. 2163 E.35 079_UNLOCK_BY_NON_LOCK_OWNER 2165 Type: change 2167 lisa@xythos.com (): At present, the specification is not explicit 2168 about who might be capable of grabbing a lock token via lock 2169 discovery and the submitting it in UNLOCK (and/or for a subsequent 2170 write operation). It is OK for the resource owner to grab the lock 2171 token and do UNLOCK/write? Is it OK to have a "grab lock token" 2172 privilege that can be assigned to anyone? 2174 Resolution: Resolved in part by putting it under ACL control: http:// 2175 lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html and 2176 the response that follows it. 2178 E.36 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC 2180 Type: change 2182 (): Proposal to remove lock null resources from the spec until we are 2183 motivated to have them or something equivalent. In the meantime, 2184 keep the spec silent on the topic in order to avoid precluding LNR or 2185 the equivalent in a future version of WebDAV. 2187 Resolution: LNRs removed. See discussions preceding conclusion: 2188 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html and 2190 http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html. 2192 E.37 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED 2194 Type: change 2196 (): The DAV:owner field of a lock is controlled by the locking client 2197 and should not be manipulated by the server. This is the only place 2198 the client can store info. The roundtrip details should match what 2199 we resolve for the PROP_ROUNDTRIP issue. Examples should also be 2200 checked. 2202 Resolution: Resolved by repeated statement and no disagreement. 2204 E.38 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK 2206 Type: change 2208 2210 gclemm@rational.com (): It would be good if a client could look at a 2211 locked resource that it was planning to unlock and also find out if 2212 it's depth locked and where the depth lock is rooted. 2214 Resolution: Proposed solution: 2215 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html 2216 approved. 2218 E.39 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION 2220 Type: change 2222 2224 ccjason@us.ibm.com (): What resource should be flagged in the 2225 multistatus response to locking issues in COPY/MOVE requests? 2227 Resolution: Resolved to flag the locking errors at the source 2228 resource that was affected by the problem. The details of how to 2229 describe the error was deferred to a subsequent version of WebDAV. - 2230 6/15/02 - 2518bis does not reflect this. 2232 E.40 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION 2234 Type: change 2236 2237 (): The method of describing the details of (beyond what resolved by 2238 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of 2239 various locking and ACL COPY/MOVE problems is deferred. Two 2240 proposals were outlined in the discussion, but interest was not great 2241 and we clearly don't have interoperability to take these proposals 2242 forward. 2244 E.41 101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS 2246 Type: change 2248 2250 julian.reschke@greenbytes.de (): There is some confusion on how a 2251 PROPFIND response should express the fact that a resource has 2252 multiple shared locks on it. It was suggested that the spec become 2253 clearer. 2255 Resolution: Resolved trivially that it's probably worthwhile to 2256 demonstrate a correc response for this situation in one of the 2257 examples. 2259 E.42 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK 2261 Type: change 2263 2265 julian.reschke@greenbytes.de (): If one finds a locked resource, it 2266 might be one of several resource locked by a depth lock. How does 2267 one determine the root of the lock? 2269 Resolution: Resolved to support a dav:lockroot element in the lock 2270 discovery property: 2271 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html 2273 E.43 111_MULTIPLE_TOKENS_PER_LOCK 2275 Type: change 2277 2279 julian.reschke@greenbytes.de (): 12.1.2 states that a dav:locktoken 2280 tag can have multiple tags in it. Is this right? And is 2281 it trying to suggest that a single (shared) lock might have multiple 2282 locktokens? 2284 Resolution: It is resolved that section 12.1.2 was incorrect and that 2285 only a single lock token URI should be allowed there. Also it is 2286 resolved that a lock only has a single lock token. 2288 Index 2290 A 2291 activelock 2292 XML element 26 2294 D 2295 DAV header 2296 compliance class '2' 32 2297 DAV:lockdiscovery property 29 2298 DAV:supportedlock property 31 2299 depth 2300 XML element 26 2302 E 2303 exclusive 2304 XML element 28 2306 H 2307 Headers 2308 Lock-Token 24 2309 Timeout 24 2311 L 2312 LOCK method 16 2313 Lock-Token header 24 2314 lockentry 2315 XML element 27 2316 lockinfo 2317 XML element 27 2318 lockscope 2319 XML element 27 2320 locktoken 2321 XML element 26 2322 locktype 2323 XML element 28 2325 M 2326 Methods 2327 LOCK 16 2328 UNLOCK 23 2330 O 2331 owner 2332 XML element 29 2334 P 2335 Properties 2336 DAV:lockdiscovery 29 2337 DAV:supportedlock 31 2339 S 2340 shared 2341 XML element 28 2343 T 2344 Timeout header 24 2345 timeout 2346 XML element 26 2348 U 2349 UNLOCK method 23 2351 W 2352 write 2353 XML element 28 2355 Intellectual Property Statement 2357 The IETF takes no position regarding the validity or scope of any 2358 Intellectual Property Rights or other rights that might be claimed to 2359 pertain to the implementation or use of the technology described in 2360 this document or the extent to which any license under such rights 2361 might or might not be available; nor does it represent that it has 2362 made any independent effort to identify any such rights. Information 2363 on the procedures with respect to rights in RFC documents can be 2364 found in BCP 78 and BCP 79. 2366 Copies of IPR disclosures made to the IETF Secretariat and any 2367 assurances of licenses to be made available, or the result of an 2368 attempt made to obtain a general license or permission for the use of 2369 such proprietary rights by implementers or users of this 2370 specification can be obtained from the IETF on-line IPR repository at 2371 http://www.ietf.org/ipr. 2373 The IETF invites any interested party to bring to its attention any 2374 copyrights, patents or patent applications, or other proprietary 2375 rights that may cover technology that may be required to implement 2376 this standard. Please address the information to the IETF at 2377 ietf-ipr@ietf.org. 2379 Disclaimer of Validity 2381 This document and the information contained herein are provided on an 2382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2384 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2385 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2386 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2389 Copyright Statement 2391 Copyright (C) The Internet Society (2004). This document is subject 2392 to the rights, licenses and restrictions contained in BCP 78, and 2393 except as set forth therein, the authors retain all their rights. 2395 Acknowledgment 2397 Funding for the RFC Editor function is currently provided by the 2398 Internet Society.