idnits 2.17.1 draft-reschke-webdav-locking-06.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 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1940. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- -- 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 (December 6, 2004) is 7081 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 1571, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11578' ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Reschke 2 Internet-Draft greenbytes 3 Updates: 2518 (if approved) December 6, 2004 4 Expires: June 6, 2005 6 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol 7 draft-reschke-webdav-locking-06 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 6, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document specifies a set of methods and headers ancillary to 43 HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, 44 RFC2518) for the management of resource locking (collision 45 avoidance). It updates those sections from RFC2518 that specify 46 WebDAV's locking features. 48 Editorial Note (to be removed by RFC Editor before publication) 50 [[anchor1: Note that this document is not a product of the WebDAV 51 working group. It is just an experiment to study the feasability of 52 extracing the locking feature into a separate specification. 53 --reschke]] 55 Distribution of this document is unlimited. Please send comments to 56 the WebDAV working group at , which may 57 be joined by sending a message with subject "subscribe" to 58 . Discussions of the WEBDAV 59 working group are archived at 60 . 62 An issues list and XML and HTML versions of this draft are available 63 from 64 . 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.2 Method Preconditions and Postconditions . . . . . . . . . 6 71 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 7 72 2.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . . 7 73 2.1.1 Lock Compatibility Table . . . . . . . . . . . . . . . 8 74 2.2 Required Support . . . . . . . . . . . . . . . . . . . . . 9 75 2.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . . . 9 76 2.4 Lock Capability Discovery . . . . . . . . . . . . . . . . 10 77 2.5 Status of a lock . . . . . . . . . . . . . . . . . . . . . 10 78 2.5.1 Lock Access Type . . . . . . . . . . . . . . . . . . . 10 79 2.5.2 Lock Scope . . . . . . . . . . . . . . . . . . . . . . 10 80 2.5.3 Lock Root . . . . . . . . . . . . . . . . . . . . . . 10 81 2.5.4 Lock Depth . . . . . . . . . . . . . . . . . . . . . . 10 82 2.5.5 Lock Owner . . . . . . . . . . . . . . . . . . . . . . 11 83 2.5.6 Lock Timeout . . . . . . . . . . . . . . . . . . . . . 11 84 2.6 Active Lock Discovery . . . . . . . . . . . . . . . . . . 12 85 2.7 Usage Considerations . . . . . . . . . . . . . . . . . . . 12 86 3. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 3.1 Methods Restricted by Write Locks . . . . . . . . . . . . 13 88 3.2 Write Locks and Properties . . . . . . . . . . . . . . . . 13 89 3.3 Write Locks and Collections . . . . . . . . . . . . . . . 13 90 3.4 Write Locks and the If Request Header . . . . . . . . . . 14 91 3.4.1 Example - Write Lock . . . . . . . . . . . . . . . . . 15 92 3.5 Write Locks and COPY/MOVE . . . . . . . . . . . . . . . . 15 93 4. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 4.1 Common XML elements used in property values . . . . . . . 16 95 4.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 16 96 4.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 16 97 4.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 16 98 4.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 17 99 4.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 18 100 4.3.1 Examples for the DAV:supportedlock property . . . . . 18 101 5. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 5.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 19 103 5.1.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 19 104 5.1.2 Postconditions . . . . . . . . . . . . . . . . . . . . 19 105 5.1.3 Example - Simple Lock Request . . . . . . . . . . . . 20 106 5.1.4 Example - Multi-Resource Lock Request . . . . . . . . 22 107 5.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 23 108 5.2.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 23 109 5.2.2 Preconditions . . . . . . . . . . . . . . . . . . . . 23 110 5.2.3 Postconditions . . . . . . . . . . . . . . . . . . . . 23 111 5.2.4 Example - Refreshing a Write Lock . . . . . . . . . . 24 112 6. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 25 113 6.1 Marshalling . . . . . . . . . . . . . . . . . . . . . . . 25 114 6.2 Preconditions . . . . . . . . . . . . . . . . . . . . . . 25 115 6.2.1 DAV:lock-token-matches precondition . . . . . . . . . 25 116 6.2.2 DAV:lock-removal-allowed precondition . . . . . . . . 25 117 6.3 Postconditions . . . . . . . . . . . . . . . . . . . . . . 26 118 6.3.1 DAV:lock-removed postcondition . . . . . . . . . . . . 26 119 6.4 Example - UNLOCK . . . . . . . . . . . . . . . . . . . . . 26 120 7. Additional status codes . . . . . . . . . . . . . . . . . . . 26 121 7.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . . . 26 122 8. Additional marshalling and method semantics for other 123 methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 124 8.1 Additional marshalling . . . . . . . . . . . . . . . . . . 26 125 8.1.1 DAV:name-allowed precondition . . . . . . . . . . . . 27 126 8.1.2 DAV:parent-resource-must-be-non-null precondition . . 27 127 8.2 Additional method semantics . . . . . . . . . . . . . . . 27 128 8.2.1 DAV:lock-token-submission-allowed precondition . . . . 27 129 8.2.2 DAV:need-lock-token precondition . . . . . . . . . . . 27 130 9. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 131 9.1 Lock-Token request/response header . . . . . . . . . . . . 28 132 9.2 Timeout request header . . . . . . . . . . . . . . . . . . 29 133 10. Capability discovery . . . . . . . . . . . . . . . . . . . . 29 134 10.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 29 135 11. Security considerations . . . . . . . . . . . . . . . . . . 30 136 11.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 30 137 12. Internationalization Considerations . . . . . . . . . . . . 30 138 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 139 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 140 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 141 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 142 15.2 Informative References . . . . . . . . . . . . . . . . . . . 31 143 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32 144 A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 32 145 A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 32 146 A.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 32 147 A.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 32 148 A.2 Additional features . . . . . . . . . . . . . . . . . . . 33 149 A.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 33 150 A.2.2 Error Marshalling . . . . . . . . . . . . . . . . . . 33 151 B. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 33 152 B.1 HTTP Methods for Distributed Authoring . . . . . . . . . . 33 153 B.1.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 33 154 B.2 HTTP Headers for Distributed Authoring . . . . . . . . . . 34 155 B.2.1 If Header . . . . . . . . . . . . . . . . . . . . . . 34 156 C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 157 C.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 34 158 C.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 34 159 C.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 34 160 C.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 35 161 C.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 35 162 C.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 35 163 C.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 35 164 C.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 35 165 D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 35 166 D.1 Node Field Generation Without the IEEE 802 Address . . . . 36 167 E. Change Log (to be removed by RFC Editor before publication) . 38 168 E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 38 169 E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 38 170 E.3 Since draft-reschke-webdav-locking-02 . . . . . . . . . . 39 171 E.4 Since draft-reschke-webdav-locking-03 . . . . . . . . . . 39 172 E.5 Since draft-reschke-webdav-locking-04 . . . . . . . . . . 39 173 E.6 Since draft-reschke-webdav-locking-05 . . . . . . . . . . 39 174 F. Resolved issues (to be removed by RFC Editor before 175 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39 176 F.1 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 39 177 F.2 5.2.1-depth_header_vs_lock_refresh . . . . . . . . . . . . 40 178 G. Open issues (to be removed by RFC Editor prior to 179 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 40 180 G.1 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 40 181 G.2 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 182 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 40 183 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 41 184 G.5 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . . 41 185 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 186 Intellectual Property and Copyright Statements . . . . . . . . 44 188 1. Introduction 190 This document describes the "locking" extension to the Web 191 Distributed Authoring and Versioning (WebDAV) protocol that allows to 192 keep more than one person from working on a document at the same 193 time. This helps preventing the "lost update problem," in which 194 modifications are lost as first one author then another writes 195 changes without merging the other author's changes. 197 1.1 Terminology 199 The terminology used here follows and extends that in the WebDAV 200 Distributed Authoring Protocol specification [RFC2518]. 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 This document uses XML DTD fragments ([XML]) as a purely notational 207 convention. WebDAV request and response bodies cannot be validated 208 due to the specific extensibility rules defined in section 23 of 209 [RFC2518] and due to the fact that all XML elements defined by this 210 specification use the XML namespace name "DAV:". In particular: 212 o Element names use the "DAV:" namespace. 214 o Element ordering is irrelevant. 216 o Extension elements/attributes (elements/attributes not already 217 defined as valid child elements) may be added anywhere, except 218 when explicitly stated otherwise. 220 1.2 Method Preconditions and Postconditions 222 A "precondition" of a method describes the state on the server that 223 must be true for that method to be performed. A "postcondition" of a 224 method describes the state on the server that must be true after that 225 method has completed. If a method precondition or postcondition for 226 a request is not satisfied and unless a more specific HTTP status 227 code applies, the response status of the request MUST be either 403 228 (Forbidden) if the request should not be repeated because it will 229 always fail, or 409 (Conflict) if it is expected that the user might 230 be able to resolve the conflict and resubmit the request. 232 In order to allow better client handling of error responses, a 233 distinct XML element type is associated with each method precondition 234 and postcondition of a request. When a particular precondition is 235 not satisfied or a particular postcondition cannot be achieved, the 236 appropriate XML element MUST be returned as the child of a top-level 237 DAV:error element in the response body, unless otherwise negotiated 238 by the request. In a 207 Multi-Status response, the DAV:error 239 element would appear in the appropriate DAV:responsedescription 240 element. 242 2. Overview of Locking 244 The ability to lock a resource provides a mechanism for serializing 245 access to that resource. Using a lock, an authoring client can 246 provide a reasonable guarantee that another principal will not modify 247 a resource while it is being edited. In this way, a client can 248 prevent the "lost update" problem. 250 This specification allows locks to vary over two client-specified 251 parameters, the number of principals involved (exclusive vs. shared) 252 and the type of access to be granted. This document defines locking 253 for only one access type, write. However, the syntax is extensible, 254 and permits the eventual specification of locking for other access 255 types. 257 2.1 Exclusive Vs. Shared Locks 259 The most basic form of lock is an exclusive lock. This is a lock 260 where the access right in question is only granted to a single 261 principal. The need for this arbitration results from a desire to 262 avoid having to merge results. 264 However, there are times when the goal of a lock is not to exclude 265 others from exercising an access right but rather to provide a 266 mechanism for principals to indicate that they intend to exercise 267 their access rights. Shared locks are provided for this case. A 268 shared lock allows multiple principals to receive a lock. Hence any 269 principal with appropriate access can get the lock. 271 With shared locks there are two trust sets that affect a resource. 272 The first trust set is created by access permissions. Principals who 273 are trusted, for example, may have permission to write to the 274 resource. Among those who have access permission to write to the 275 resource, the set of principals who have taken out a shared lock also 276 must trust each other, creating a (typically) smaller trust set 277 within the access permission write set. 279 Starting with every possible principal on the Internet, in most 280 situations the vast majority of these principals will not have write 281 access to a given resource. Of the small number who do have write 282 access, some principals may decide to guarantee their edits are free 283 from overwrite conflicts by using exclusive write locks. Others may 284 decide they trust their collaborators will not overwrite their work 285 (the potential set of collaborators being the set of principals who 286 have write permission) and use a shared lock, which informs their 287 collaborators that a principal may be working on the resource. 289 This specification does not need to provide all of the communications 290 paths necessary for principals to coordinate their activities. When 291 using shared locks, principals may use any out of band communication 292 channel to coordinate their work (e.g., face-to-face interaction, 293 written notes, post-it notes on the screen, telephone conversation, 294 Email, etc.) The intent of a shared lock is to let collaborators 295 know who else may be working on a resource. 297 Shared locks are included because experience from web distributed 298 authoring systems has indicated that exclusive locks are often too 299 rigid. An exclusive lock is used to enforce a particular editing 300 process: take out an exclusive lock, read the resource, perform 301 edits, write the resource, release the lock. This editing process 302 has the problem that locks are not always properly released, for 303 example when a program crashes, or when a lock owner leaves without 304 unlocking a resource. While both timeouts and administrative action 305 can be used to remove an offending lock, neither mechanism may be 306 available when needed; the timeout may be long or the administrator 307 may not be available. With a shared lock, another user can at least 308 take out another shared lock and start modifying the resource. 310 2.1.1 Lock Compatibility Table 312 The table below describes the behavior that occurs when a lock 313 request is made on a resource. 315 +-------------------------+--------------------+--------------------+ 316 | Current lock state / | Shared Lock | Exclusive Lock | 317 | Lock request | | | 318 +-------------------------+--------------------+--------------------+ 319 | None | True | True | 320 | Shared Lock | True | False | 321 | Exclusive Lock | False | False* | 322 +-------------------------+--------------------+--------------------+ 324 Legend: True = lock may be granted. False = lock MUST NOT be 325 granted. *=It is illegal for a principal to request the same lock 326 twice. 328 The current lock state of a resource is given in the leftmost column, 329 and lock requests are listed in the first row. The intersection of a 330 row and column gives the result of a lock request. For example, if a 331 shared lock is held on a resource, and an exclusive lock is 332 requested, the table entry is "false", indicating the lock must not 333 be granted. 335 2.2 Required Support 337 A WebDAV compliant server is not required to support locking in any 338 form. If the server does support locking it may choose to support 339 any combination of exclusive and shared locks for any access types. 341 The reason for this flexibility is that locking policy strikes to the 342 very heart of the resource management and versioning systems employed 343 by various storage repositories. These repositories require control 344 over what sort of locking will be made available. For example, some 345 repositories only support shared write locks while others only 346 provide support for exclusive write locks while yet others use no 347 locking at all. As each system is sufficiently different to merit 348 exclusion of certain locking features, this specification leaves 349 locking as the sole axis of negotiation within WebDAV. 351 2.3 Lock Tokens 353 A lock token is a type of state token, represented as a URI, which 354 identifies a particular lock (see [RFC2518], section 9.4, for a 355 definition of state tokens). A lock token is returned by every 356 successful LOCK operation in the Lock-Token response header. The 357 lock token also appears in the value of the DAV:lockdiscovery 358 property, the value of which is returned in the body of the response 359 to a successful LOCK operation (note that this property also includes 360 the tokens of other current locks on the resource). 362 Lock token URIs MUST be unique across all resources for all time. 363 This uniqueness constraint allows lock tokens to be submitted across 364 resources and servers without fear of confusion. 366 This specification provides a lock token URI scheme called 367 "opaquelocktoken" that meets the uniqueness requirements. However 368 servers are free to return any URI scheme so long as it meets the 369 uniqueness requirements. Note that only URI schemes registered by 370 the IETF can ensure uniqueness. 372 Submitting a lock token provides no special access rights. Anyone 373 can find out anyone else's lock token by performing lock discovery. 374 Locks MUST be enforced based upon whatever authentication mechanism 375 is used by the server, not based on the secrecy of the token values. 377 2.4 Lock Capability Discovery 379 Since server lock support is optional, a client trying to lock a 380 resource on a server can either try the lock and hope for the best, 381 or perform some form of discovery to determine what lock capabilities 382 the server supports. This is known as lock capability discovery. 383 Lock capability discovery differs from discovery of supported access 384 control types, since there may be access control types without 385 corresponding lock types. A client can determine what lock types the 386 server supports by retrieving the DAV:supportedlock property defined 387 in Section 4.3. 389 2.5 Status of a lock 391 A lock is identified by a URI (the lock token URI) but in general, it 392 does not have a HTTP URL, and thus can not be directly manipulated 393 using HTTP methods. Instead, this specification defines the new 394 methods LOCK (creating and refreshing locks, see Section 5) and 395 UNLOCK (removing locks, see Section 6) that act indirectly on locks. 397 A lock has state that can be indirectly observed by using the 398 DAV:lockdiscovery property defined in Section 4.2. At a minimum, the 399 state of a lock consists of the items defined in the sections below. 400 After lock creation, all parts of the state with the exception of the 401 timeout value are immutable. 403 2.5.1 Lock Access Type 405 At present, this specification only defines one lock access type, the 406 "write" lock defined in Section 3. 408 2.5.2 Lock Scope 410 A lock has either exclusive or shared scope (see Section 2.1). 412 2.5.3 Lock Root 414 A lock is created as effect of a LOCK (creation) method request. The 415 lock root is the URL to which this request was adressed. 417 2.5.4 Lock Depth 419 A "depth 0" lock only affects the resource to which the LOCK request 420 was adressed to (the lock root). This resource is said to be 421 "directly locked" by the lock. 423 On the other hand, a "depth infinity" lock on a collection 424 additionally affects all members of that collection. These resources 425 are said to be "indirectly locked" by the lock. A "depth infinity" 426 lock on a non-collection resource behaves exactly the same way as a 427 "depth 0" lock. 429 2.5.5 Lock Owner 431 Clients can submit information about the lock owner when creating a 432 lock. This information should be sufficient for either directly 433 contacting a principal (such as a telephone number or email URI), or 434 for discovering the principal (such as the URL of a homepage). 436 Owner information is kept with the lock so that it can be returned in 437 the DAV:lockdiscovery property upon request. Note that this 438 information is entirely client-controlled, thus a server MUST store 439 the information faithfully just like if it appeared in a WebDAV dead 440 property (see [RFC2518], section 4). 442 2.5.6 Lock Timeout 444 In general, a lock expires after a certain amount of time. This time 445 can be specified in the LOCK creation request (however servers are 446 not required to honor this request). 448 If the timeout expires then the lock may be lost. Specifically, if 449 the server wishes to harvest the lock upon time-out, the server 450 SHOULD act as if an UNLOCK method was executed by the server on the 451 resource using the lock token of the timed-out lock, performed with 452 its override authority. Thus logs should be updated with the 453 disposition of the lock, notifications should be sent, etc., just as 454 they would be for an UNLOCK request. 456 The timers used for timeout expiry can be reset by the client by 457 submitting a LOCK refresh request. 459 Servers are advised to pay close attention to the values submitted by 460 clients, as they will be indicative of the type of activity the 461 client intends to perform. For example, an applet running in a 462 browser may need to lock a resource, but because of the instability 463 of the environment within which the applet is running, the applet may 464 be turned off without warning. As a result, the applet is likely to 465 ask for a relatively small timeout value so that if the applet dies, 466 the lock can be quickly harvested. However, a document management 467 system is likely to ask for an extremely long timeout because its 468 user may be planning on going off-line. 470 A client MUST NOT assume that just because the time-out has expired 471 the lock has been lost. Clients MUST assume that locks may 472 arbitrarily disappear at any time, regardless of the value given in 473 the Timeout header. The Timeout header only indicates the behavior 474 of the server if "extraordinary" circumstances do not occur. For 475 example, an administrator may remove a lock at any time or the system 476 may crash in such a way that it loses the record of the lock's 477 existence. 479 2.6 Active Lock Discovery 481 If another principal locks a resource that a principal wishes to 482 access, it is useful for the second principal to be able to find out 483 who the first principal is. For this purpose the DAV:lockdiscovery 484 property is provided. This property lists all outstanding locks, 485 describes their type, and where available, provides their lock token. 487 2.7 Usage Considerations 489 Although the locking mechanisms specified here provide some help in 490 preventing lost updates, they cannot guarantee that updates will 491 never be lost. Consider the following scenario: 493 o Two clients A and B are interested in editing the resource 494 'index.html'. Client A is an HTTP client rather than a WebDAV 495 client, and so does not know how to perform locking. 497 o Client A doesn't lock the document, but does a GET and begins 498 editing. 500 o Client B does LOCK, performs a GET and begins editing. 502 o Client B finishes editing, performs a PUT, then an UNLOCK. 504 o Client A performs a PUT, overwriting and losing all of B's 505 changes. 507 There are several reasons why the WebDAV protocol itself cannot 508 prevent this situation. First, it cannot force all clients to use 509 locking because it must be compatible with HTTP clients that do not 510 comprehend locking. Second, it cannot require servers to support 511 locking because of the variety of repository implementations, some of 512 which rely on reservations and merging rather than on locking. 513 Finally, being stateless, it cannot enforce a sequence of operations 514 like LOCK / GET / PUT / UNLOCK. 516 WebDAV servers that support locking can reduce the likelihood that 517 clients will accidentally overwrite each other's changes by requiring 518 clients to lock resources before modifying them. Such servers would 519 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying 520 resources. 522 WebDAV clients can be good citizens by using a lock / retrieve / 523 write /unlock sequence of operations (at least by default) whenever 524 they interact with a WebDAV server that supports locking. 526 HTTP 1.1 clients can be good citizens, avoiding overwriting other 527 clients' changes, by using entity tags in If-Match headers with any 528 requests that would modify resources. 530 Information managers may attempt to prevent overwrites by 531 implementing client-side procedures requiring locking before 532 modifying WebDAV resources. 534 3. Write Lock 536 This section describes the semantics specific to the write lock type. 537 The write lock is a specific instance of a lock type, and is the only 538 lock type described in this specification. 540 3.1 Methods Restricted by Write Locks 542 If a request would modify the content for a locked resource, a dead 543 property of a locked resource, a live property that is defined to be 544 lockable for a locked resource, or an internal member URI of a locked 545 collection, the request MUST fail unless the lock-token for that lock 546 is submitted in the request. An internal member URI of a collection 547 is considered to be modified if it is added, removed, or identifies a 548 different resource. [[anchor14: Copy of GULP, "Locked State". 549 --reschke]] 551 3.2 Write Locks and Properties 553 While those without a write lock may not alter a property on a 554 resource it is still possible for the values of live properties to 555 change, even while locked, due to the requirements of their schemas. 556 Only dead properties and live properties defined to respect locks are 557 guaranteed not to change while write locked. 559 3.3 Write Locks and Collections 561 A write lock on a collection, whether created by a "Depth: 0" or 562 "Depth: infinity" lock request, prevents the addition or removal of 563 member URIs of the collection by non-lock owners. As a consequence, 564 when a principal issues a PUT or POST request to create a new 565 resource under a URI which needs to be an internal member of a write 566 locked collection to maintain HTTP namespace consistency, or issues a 567 DELETE to remove an internal member URI of a write locked collection, 568 this request MUST fail if the principal does not have a write lock on 569 the collection. 571 However, if a write lock request is issued to a collection containing 572 member URIs identifying resources that are currently locked in a 573 manner which conflicts with the write lock, the request MUST fail 574 with a 423 (Locked) status code (Note that this can only occur for a 575 request of a "Depth: infinity" write lock). 577 If a lock owner causes the URI of a resource to be added as an 578 internal member URI of a "Depth: infinity" locked collection then 579 the new resource MUST be automatically added to the lock. This is 580 the only mechanism that allows a resource to be added to a write 581 lock. Thus, for example, if the collection /a/b/ is write locked and 582 the resource /c is moved to /a/b/c then resource /a/b/c will be added 583 to the write lock. 585 3.4 Write Locks and the If Request Header 587 If a user agent is not required to have knowledge about a lock when 588 requesting an operation on a locked resource, the following scenario 589 might occur. Program A, run by User A, takes out a write lock on a 590 resource. Program B, also run by User A, has no knowledge of the 591 lock taken out by Program A, yet performs a PUT to the locked 592 resource. In this scenario, the PUT succeeds because locks are 593 associated with a principal, not a program, and thus program B, 594 because it is acting with principal A's credential, is allowed to 595 perform the PUT. However, had program B known about the lock, it 596 would not have overwritten the resource, preferring instead to 597 present a dialog box describing the conflict to the user. Due to 598 this scenario, a mechanism is needed to prevent different programs 599 from accidentally ignoring locks taken out by other programs with the 600 same authorization. 602 In order to prevent these collisions a lock token MUST be submitted 603 in the If header for all locked resources that a method may interact 604 with or the method MUST fail. For example, if a resource is to be 605 moved and both the source and destination are locked then two lock 606 tokens must be submitted, one for the source and the other for the 607 destination. 609 Servers SHOULD restrict usage of the lock token to exactly the 610 authenticated principal who created the lock. 612 3.4.1 Example - Write Lock 614 >>Request 616 COPY /~fielding/index.html HTTP/1.1 617 Host: example.com 618 Destination: http://example.com/users/f/fielding/index.html 619 If: 620 () 622 >>Response 624 HTTP/1.1 204 No Content 626 In this example, even though both the source and destination are 627 locked, only one lock token must be submitted, for the lock on the 628 destination. This is because the source resource is not modified by 629 a COPY, and hence unaffected by the write lock. In this example, 630 user agent authentication has previously occurred via a mechanism 631 outside the scope of the HTTP protocol, in the underlying transport 632 layer. 634 3.5 Write Locks and COPY/MOVE 636 A COPY method invocation MUST NOT duplicate any write locks active on 637 the source. However, as previously noted, if the COPY copies the 638 resource into a collection that is locked with "Depth: infinity", 639 then the resource will be added to the lock. 641 A successful MOVE request on a write locked resource MUST NOT move 642 the write lock with the resource. However, the resource is subject 643 to being added to an existing lock at the destination, as specified 644 in Section 3.3. For example, if the MOVE makes the resource a child 645 of a collection that is locked with "Depth: infinity", then the 646 resource will be added to that collection's lock. Additionally, if a 647 resource locked with "Depth: infinity" is moved to a destination that 648 is within the scope of the same lock (e.g., within the namespace tree 649 covered by the lock), the moved resource will again be a added to the 650 lock. In both these examples, as specified in Section 3.4, an If 651 header must be submitted containing a lock token for both the source 652 and destination. 654 4. Properties 656 Any DAV compliant resource that supports the LOCK method MUST support 657 the DAV:activelock and DAV:lockdiscovery properties defined below. 659 4.1 Common XML elements used in property values 661 4.1.1 Lock Scopes 663 664 665 667 4.1.2 Lock Types 669 670 672 4.2 DAV:lockdiscovery property 674 The DAV:lockdiscovery property returns a listing of who has a lock, 675 what type of lock he has, the timeout type, the time remaining on the 676 timeout, the associated lock token and the root of the lock. The 677 server is free to withhold any or all of this information if the 678 requesting principal does not have sufficient access rights to see 679 the requested data. 681 683 686 depth: the value of the Depth header (see Section 2.5.4; takes the 687 values "0" or "infinity"). 689 691 owner: provides information about the principal taking out a lock 692 (see Section 2.5.5). 694 696 timeout: the time remaining until timeout of a lock (see Section 697 2.5.6). 699 701 locktoken: the lock token associated with a lock; the href element 702 contains the lock token. 704 706 lockroot: the URL that was specified as Request-URI in the LOCK 707 creation request; the href element contains the URL(see Section 708 2.5.3). 710 712 href: defined in [RFC2518], section 12.3. 714 716 4.2.1 Examples for the DAV:lockdiscovery 718 DAV:lockdiscovery property for a resource that has two shared write 719 locks on it, with infinite timeouts: 721 722 723 724 725 0 726 Jane Smith 727 Infinite 728 729 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 731 732 733 http://example.com/container/ 735 736 > 737 738 739 740 0 741 John Doe 742 Infinite 743 744 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77 746 747 748 http://example.com/container/ 750 752 753 755 DAV:lockdiscovery property for a resource with no locks on it: 757 759 4.3 DAV:supportedlock property 761 The DAV:supportedlock property of a resource returns a listing of the 762 combinations of scope and access types which may be specified in a 763 lock request on the resource. Note that the actual contents are 764 themselves controlled by access controls so a server is not required 765 to provide information the client is not authorized to see. 767 768 770 4.3.1 Examples for the DAV:supportedlock property 772 DAV:supportedlock property for a resource that supports both 773 exclusive and shares write locks: 775 776 777 778 779 780 781 782 783 784 786 DAV:supportedlock property for a resource that doesn't support any 787 locks at all: 789 791 5. LOCK Method 793 The following sections describe the LOCK method, which is used to 794 take out a lock of any access type or to refresh an existing lock. 796 5.1 Creating Locks 798 A LOCK method invocation with non-empty request body creates the lock 799 specified by the lockinfo XML element on the resource identified by 800 the Request-URI. If the Request-URI identifies a null resource, the 801 invocation MUST create a new resource with empty content. 803 5.1.1 Marshalling 805 The request MAY include a "Timeout" header to be used as the timeout 806 value for the lock to be created (see Section 9.2). However, the 807 server is not required to honor or even consider this request. 809 The request MAY include a "Depth" header specifying either "0" or 810 "infinity" (see [RFC2518], section 9.2). If no "Depth" header is 811 submitted then the request MUST act as if a "Depth:infinity" had been 812 specified. 814 The request body MUST be a DAV:lockinfo element: 816 818 DAV:lockscope, DAV:locktype and DAV:owner are defined in Section 4. 820 The response body for a successful request MUST be a DAV:prop XML 821 element, containing the new value for the DAV:lockdiscovery property 822 defined in Section 4.2. The lock token URI for the new lock MUST be 823 returned in the "Lock-Token" response header (see Section 9.1). 825 [[anchor25: Add preconditions for the validy of various parts of the 826 request body? --reschke]] 828 5.1.2 Postconditions 830 5.1.2.1 DAV:create-lock postcondition 832 The request MUST have created a new lock on the resource identified 833 by the Request-URI. The request MUST have allocated a distinct new 834 lock token URI for the new lock, and that URI MUST NOT ever identify 835 anything other than that lock. [[anchor28: Say what parts of the 836 request lock criteria must be followed. --reschke]] 838 5.1.2.2 DAV:create-resource postcondition 840 If the Request-URI identified a null resource, the method MUST have 841 created a new resource with empty content. 843 5.1.3 Example - Simple Lock Request 845 >>Request 847 LOCK /workspace/webdav/proposal.doc HTTP/1.1 848 Host: example.com 849 Timeout: Infinite, Second-4100000000 850 Content-Type: text/xml; charset="utf-8" 851 Content-Length: xxxx 852 Authorization: Digest username="ejw", 853 realm="ejw@example.com", nonce="...", 854 uri="/workspace/webdav/proposal.doc", 855 response="...", opaque="..." 857 858 859 860 861 862 http://example.org/~ejw/contact.html 863 864 866 >>Response 868 HTTP/1.1 200 OK 869 Lock-Token: 870 Content-Type: text/xml; charset="utf-8" 871 Content-Length: xxxx 873 874 875 876 877 878 879 Infinity 880 881 http://example.org/~ejw/contact.html 883 884 Second-604800 885 886 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 888 889 890 http://example.com/workspace/webdav/proposal.doc 892 893 894 895 897 This example shows the successful creation of an exclusive write lock 898 on resource http://example.com/workspace/webdav/proposal.doc. The 899 resource http:/example.org/~ejw/contact.html contains contact 900 information for the owner of the lock. The server has an 901 activity-based timeout policy in place on this resource, which causes 902 the lock to automatically be removed after 1 week (604800 seconds). 904 5.1.4 Example - Multi-Resource Lock Request 906 >>Request 908 LOCK /webdav/ HTTP/1.1 909 Host: example.com 910 Timeout: Infinite, Second-4100000000 911 Depth: infinity 912 Content-Type: text/xml; charset="utf-8" 913 Content-Length: xxxx 914 Authorization: Digest username="ejw", 915 realm="ejw@example.com", nonce="...", 916 uri="/workspace/webdav/proposal.doc", 917 response="...", opaque="..." 919 920 921 922 923 924 http://example.org/~ejw/contact.html 925 926 928 >>Response 930 HTTP/1.1 207 Multi-Status 931 Content-Type: text/xml; charset="utf-8" 932 Content-Length: xxxx 934 935 936 937 /webdav/secret 938 HTTP/1.1 403 Forbidden 939 940 941 /webdav/ 942 HTTP/1.1 424 Failed Dependency 943 944 946 This example shows a request for an exclusive write lock on a 947 collection and all its children. In this request, the client has 948 specified that it desires an infinite length lock, if available, 949 otherwise a timeout of 4.1 billion seconds, if available. The 950 request entity body contains the contact information for the 951 principal taking out the lock, in this case a web page URL. 953 The error is a 403 (Forbidden) response on the resource 954 http://example.com/webdav/secret. Because this resource could not be 955 locked, none of the resources were locked. 957 5.2 Refreshing Locks 959 A LOCK request with no request body is a "LOCK refresh" request. 960 It's purpose is to restart all timers associated with a lock. 962 If an error is received in response to a refresh LOCK request the 963 client SHOULD assume that the lock was not refreshed. [[anchor32: 964 This fact is so obvious that it should be removed. --reschke]] 966 5.2.1 Marshalling 968 The request MUST include an "If" header that contains the lock tokens 969 of the locks to be refreshed (note there may be multiple in the case 970 of shared locks). 972 The request MAY include a "Timeout" header to be used as the new 973 timeout value for the lock(s) to be refreshed (see Section 9.2). 975 The request MAY include a "Depth" header specifying either "0" or 976 "infinity" (see [RFC2518], section 9.2) which MUST be ignored when 977 present. 979 The response to a successful lock refresh request MUST contain the 980 value of the current DAV:lockdiscovery property in a prop XML 981 element. 983 5.2.2 Preconditions 985 5.2.2.1 DAV:lock-submission-allowed precondition 987 See Section 8.2.1. 989 5.2.3 Postconditions 991 5.2.3.1 DAV:locks-refreshed postcondition 993 Timers associated with the those locks submitted in the "If" request 994 header whose lock root is the resource identified by the Request-URI 995 MUST be reset to their original value (or alternatively to the new 996 value given in the "Timeout" request header). 998 5.2.4 Example - Refreshing a Write Lock 1000 >>Request 1002 LOCK /workspace/webdav/proposal.doc HTTP/1.1 1003 Host: example.com 1004 Timeout: Infinite, Second-4100000000 1005 If: () 1006 Authorization: Digest username="ejw", 1007 realm="ejw@example.com", nonce="...", 1008 uri="/workspace/webdav/proposal.doc", 1009 response="...", opaque="..." 1011 >>Response 1013 HTTP/1.1 200 OK 1014 Content-Type: text/xml; charset="utf-8" 1015 Content-Length: xxxx 1017 1018 1019 1020 1021 1022 1023 Infinity 1024 1025 http://example.org/~ejw/contact.html 1027 1028 Second-604800 1029 1030 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 1032 1033 1034 http://example.com/workspace/webdav/proposal.doc 1036 1037 1038 1039 1041 This request would refresh the lock, resetting any time outs. Notice 1042 that the client asked for an infinite time out but the server choose 1043 to ignore the request. 1045 6. UNLOCK Method 1047 The UNLOCK method removes the lock identified by the lock token in 1048 the Lock-Token request header from the resource identified by the 1049 Request-URI, and all other resources included in the lock. Note that 1050 the UNLOCK request may be submitted to any resource locked by that 1051 lock (even those that are locked indirectly). 1053 If all resources which have been locked under the submitted lock 1054 token can not be unlocked then the UNLOCK request MUST fail. 1056 Any DAV compliant resource which supports the LOCK method MUST 1057 support the UNLOCK method. 1059 A server MAY allow principals other than a lock owner to unlock a 1060 resource. In this case, this capability SHOULD be under access 1061 control (see [RFC3744], section 3.5). Note that there is a tradeoff 1062 in allowing non-owners of a lock to unlock a resource. It can be 1063 beneficial to allow non-lock owners to perform UNLOCK requests 1064 because it allows the adminstrator of the server to configure the 1065 server to grant longer lock timeouts because the administrator knows 1066 that there is a process in place to allow users to deal with 1067 forgotten locks left by other users. On the other hand, a 1068 disadvantage of unlocking someone else's lock is that can create a 1069 situation where two users are working on modifications to the same 1070 resource at the same time which can result in a client having to 1071 perform an merge that wasn't previously planned. 1073 6.1 Marshalling 1075 The request MUST include a "Lock-Token" header (see Section 9.1) that 1076 identifies the lock to be removed. 1078 [[anchor40: Specify optional request body? --reschke]] 1080 6.2 Preconditions 1082 6.2.1 DAV:lock-token-matches precondition 1084 The lock identified by the "Lock-Token" request header exists, and 1085 the resource identified by the Request-URI indeed is directly locked 1086 by the specified lock. 1088 6.2.2 DAV:lock-removal-allowed precondition 1090 As dicussed above, the principal authenticated for the UNLOCK request 1091 MUST be allowed to remove the identified lock (note that servers that 1092 support the "WebDAV Access Control Protocol" should use the 1093 DAV:need-privileges precondition defined in section 7.1.1 of 1094 [RFC3744]). 1096 6.3 Postconditions 1098 6.3.1 DAV:lock-removed postcondition 1100 The lock MUST have been removed from all resources included in the 1101 lock. 1103 6.4 Example - UNLOCK 1105 >>Request 1107 UNLOCK /workspace/webdav/info.doc HTTP/1.1 1108 Host: example.com 1109 Lock-Token: 1110 Authorization: Digest username="ejw", 1111 realm="ejw@example.com", nonce="...", 1112 uri="/workspace/webdav/proposal.doc", 1113 response="...", opaque="..." 1115 >>Response 1117 HTTP/1.1 204 No Content 1119 In this example, the lock identified by the lock token 1120 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 1121 successfully removed from the resource 1122 http://example.com/workspace/webdav/info.doc. If this lock included 1123 more than just one resource, the lock is removed from all resources 1124 included in the lock. Note that clients MUST interpret any of the 1125 success status codes defined in [RFC2616], section 10.2 as success 1126 codes. 204 (No Content) was used here merely for consistency with 1127 the example in [RFC2518], section 8.11.1). 1129 7. Additional status codes 1131 7.1 423 Locked 1133 The 423 (Locked) status code means the source or destination resource 1134 of a method is locked. 1136 8. Additional marshalling and method semantics for other methods 1138 8.1 Additional marshalling 1140 This section defines additional condition names (see Section 1.2) 1141 that apply to all methods. 1143 8.1.1 DAV:name-allowed precondition 1145 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1146 create a new internal member URI inside a collection resource, the 1147 last path segment of that URI must specify a name that is available 1148 as a resource name (for instance, servers may disallow path segments 1149 that -- after being URI-unescaped -- aren't valid UTF-8 octet 1150 sequences). [[anchor50: Copied from 1151 draft-ietf-webdav-redirectref-protocol. --reschke]] 1153 8.1.2 DAV:parent-resource-must-be-non-null precondition 1155 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1156 create a new internal member URI inside a collection resource, that 1157 collection resource must be non-null. [[anchor52: Copied from 1158 draft-ietf-webdav-redirectref-protocol. --reschke]] 1160 8.2 Additional method semantics 1162 This section defines names (see Section 1.2) for new conditions 1163 introduced by locking semantics. Otherwise noted otherwise, they 1164 apply to all methods. 1166 8.2.1 DAV:lock-token-submission-allowed precondition 1168 If the server restricts usage of the lock token inside an "If" 1169 request header to specific principals, the authenticated principal 1170 for this request MUST be one of them. 1172 8.2.2 DAV:need-lock-token precondition 1174 If a request would modify the content for a locked resource, a dead 1175 property of a locked resource, a live property that is defined to be 1176 lockable for a locked resource, or an internal member URI of a locked 1177 collection, the request MUST fail unless the lock-token for that lock 1178 is submitted in the request. An internal member URI of a collection 1179 is considered to be modified if it is added, removed, or identifies a 1180 different resource. [[anchor55: Copied from GULP. --reschke]] 1182 1184 Servers SHOULD insert DAV:href elements for the URLs of each root of 1185 a lock for which a lock token was needed, unless that URL identies 1186 the same resource to that the request was sent. 1188 8.2.2.1 Example 1190 In the example below, a client unaware of a "Depth: infinity" lock on 1191 the parent collection "/workspace/webdav/" attempts to modify the 1192 collection member "/workspace/webdav/proposal.doc". 1194 >>Request 1196 PUT /workspace/webdav/proposal.doc HTTP/1.1 1197 Host: example.com 1199 >>Response 1201 HTTP/1.1 423 Locked 1202 Content-Type: text/xml; charset="utf-8" 1203 Content-Length: xxxx 1205 1206 1207 1208 /workspace/webdav/ 1209 1210 1212 9. Headers 1214 9.1 Lock-Token request/response header 1216 Lock-Token = "Lock-Token" ":" Coded-URL 1218 Note that the "Coded-URL" production is defined in [RFC2518], section 1219 9.4. 1221 The Lock-Token request header is used with the UNLOCK method to 1222 identify the lock to be removed. The lock token in the Lock-Token 1223 request header MUST identify a lock that contains the resource 1224 identified by Request-URI as a member. 1226 The Lock-Token response header is used with the LOCK method to 1227 indicate the lock token created as a result of a successful LOCK 1228 request to create a new lock. 1230 Note that the "Lock-Token" request header does not contribute to the 1231 precondition checks defined for the HTTP status 412 (see [RFC2616], 1232 section 10.4.13). 1234 9.2 Timeout request header 1236 TimeOut = "Timeout" ":" 1#TimeType 1237 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) 1238 DAVTimeOutVal = 1*digit 1239 Other = "Extend" field-value ; See section 4.2 of [RFC2616] 1241 Clients MUST NOT submit a Timeout request header with any method 1242 other than a LOCK method. 1244 A Timeout request header MUST contain at least one TimeType and may 1245 contain multiple TimeType entries. The purpose of listing multiple 1246 TimeType entries is to indicate multiple different values and value 1247 types that are acceptable to the client. The client lists the 1248 TimeType entries in order of preference. 1250 Timeout response values MUST use a Second value, Infinite, or a 1251 TimeType the client has indicated familiarity with. The server may 1252 assume a client is familiar with any TimeType submitted in a Timeout 1253 header. 1255 The "Second" TimeType specifies the number of seconds that will 1256 elapse between granting of the lock at the server, and the automatic 1257 removal of the lock. The timeout value for TimeType "Second" MUST 1258 NOT be greater than 2^32-1. 1260 10. Capability discovery 1262 10.1 OPTIONS method 1264 If the server supports locking, it MUST return both the compliance 1265 class names "2" and "locking" as fields in the "DAV" response header 1266 (see [RFC2518], section 9.1) from an OPTIONS request on any resource 1267 implemented by that server. A value of "2" or "locking" in the "DAV" 1268 response header MUST indicate that the server meets all class "1" 1269 requirements defined in [RFC2518] and supports all MUST level 1270 requirements and REQUIRED features specified in this document, 1271 including: 1273 o LOCK and UNLOCK methods, 1275 o DAV:lockdiscovery and DAV:supportedlock properties, 1277 o "Time-Out" request header, "Lock-Token" request and response 1278 header. 1280 Note that for servers implementing this specification, the compliance 1281 classes "2" and "locking" are synonymous. However, new clients can 1282 take advantage of the new "locking" compliance class to detect server 1283 support for changes introduced by this specification (see Appendix 1284 A). 1286 11. Security considerations 1288 All security considerations mentioned in [RFC2518] also apply to this 1289 document. Additionally, lock tokens introduce new privacy issues 1290 discussed below. 1292 11.1 Privacy Issues Connected to Locks 1294 When submitting a lock request a user agent may also submit an owner 1295 XML field giving contact information for the person taking out the 1296 lock (for those cases where a person, rather than a robot, is taking 1297 out the lock). This contact information is stored in a 1298 DAV:lockdiscovery property on the resource, and can be used by other 1299 collaborators to begin negotiation over access to the resource. 1300 However, in many cases this contact information can be very private, 1301 and should not be widely disseminated. Servers SHOULD limit read 1302 access to the DAV:lockdiscovery property as appropriate. 1303 Furthermore, user agents SHOULD provide control over whether contact 1304 information is sent at all, and if contact information is sent, 1305 control over exactly what information is sent. 1307 12. Internationalization Considerations 1309 All internationalization considerations mentioned in [RFC2518] also 1310 apply to this document. 1312 13. IANA Considerations 1314 This specification updates the definition of the "opaquelocktoken" 1315 URI scheme described in Appendix D, registered my means of [RFC2518], 1316 section 6.4. There are no additional IANA considerations. 1318 14. Acknowledgements 1320 This document is the collaborative product of 1322 o the authors, 1324 o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault 1325 - and 1327 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron 1328 Goland, Del Jensen and Jim Whitehead. 1330 This document has also benefited from thoughtful discussion by Mark 1331 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, 1332 Rickard Falk, Eric Glass, Stanley Guan, Larry Masinter, Joe Orton, 1333 Juergen Pill, Elias Sinderson, Greg Stein, Kevin Wiggen, and other 1334 members of the WebDAV working group. 1336 15. References 1338 15.1 Normative References 1340 [ISO-11578] 1341 International Organization for Standardization, "ISO/IEC 1342 11578:1996. Information technology - Open Systems 1343 Interconnection - Remote Procedure Call (RPC)", 1996. 1345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1346 Requirement Levels", BCP 14, RFC 2119, March 1997. 1348 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1349 Jensen, "HTTP Extensions for Distributed Authoring -- 1350 WEBDAV", RFC 2518, February 1999. 1352 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1353 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1354 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1356 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 1357 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1358 Edition)", W3C REC-xml-20040204, February 2004, 1359 . 1361 [draft-fielding-rfc2396bis] 1362 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1363 Resource Identifier (URI): Generic Syntax", ID 1364 draft-fielding-rfc2396bis-07, September 2004. 1366 15.2 Informative References 1368 [RFC3744] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web 1369 Distributed Authoring and Versioning (WebDAV) Access 1370 Control Protocol", RFC 3744, May 2004. 1372 Author's Address 1374 Julian F. Reschke 1375 greenbytes GmbH 1376 Salzmannstrasse 152 1377 Muenster, NW 48159 1378 Germany 1380 Phone: +49 251 2807760 1381 Fax: +49 251 2807761 1382 EMail: julian.reschke@greenbytes.de 1383 URI: http://greenbytes.de/tech/webdav/ 1385 Appendix A. Changes to RFC2518 1387 See Section 10 for a description about how clients can discover 1388 support for this version of the WebDAV Locking protocol. 1390 A.1 Removed/Deprecated features 1392 A.1.1 Implicit lock refresh 1394 In section 9.8, [RFC2518] specifies that locks should be refreshed 1395 implicitly every time "...any time an owner of the lock sends a 1396 method to any member of the lock, including unsupported methods, or 1397 methods which are unsuccessful." This features has been removed 1398 (locks need to be refreshed explicitly using the LOCK method). 1400 Compatibility consideration: clients historically have never relied 1401 on this feature as it was never implemented in widely deployed WebDAV 1402 servers. 1404 A.1.2 Lock-null resources 1406 In section 7.4, [RFC2518] specifies a special resource type called 1407 "lock-null resource" that's being created when a LOCK method request 1408 is applied to a null resource. In practice, no real interoperability 1409 was achieved because many servers failed to implement this feature 1410 properly and few clients (if any) ever relied on that particular 1411 functionality. 1413 Removing this feature also means that there is no atomic way to 1414 create a collection in locked state, but in practice, this doesn't 1415 seem to be a problem. 1417 Compatibility consideration: there do not seem to be any widely 1418 deployed clients that actually relied on "lock-null resources". 1420 A.2 Additional features 1422 A.2.1 DAV:lockroot element in DAV:activelock 1424 Clients can take advantage of the new DAV:lockroot element to 1425 discover the URL to which the LOCK request (that created the lock) 1426 was applied. 1428 Compatibility consideration: clients will have to fail gracefully 1429 when communicating with older servers that do not support the new 1430 element. 1432 A.2.2 Error Marshalling 1434 Clients can take advantage of additional, detailed error information 1435 using the DAV:error element defined in Section 1.2. 1437 Compatibility consideration: old clients should not even notice the 1438 additional informations. New clients SHOULD handle absence of 1439 additional error information gracefully. 1441 Appendix B. Text to be integrated from RFC2518 1443 B.1 HTTP Methods for Distributed Authoring 1445 B.1.1 LOCK Method 1447 B.1.1.1 Locking Replicated Resources 1449 A resource may be made available through more than one URI. However 1450 locks apply to resources, not URIs. Therefore a LOCK request on a 1451 resource MUST NOT succeed if can not be honored by all the URIs 1452 through which the resource is addressable. 1454 B.1.1.2 Depth and Locking 1456 A Depth header of value 0 means to just lock the resource specified 1457 by the Request-URI. 1459 If the Depth header is set to infinity then the resource specified in 1460 the Request-URI along with all its internal members, all the way down 1461 the hierarchy, are to be locked. A successful result MUST return a 1462 single lock token which represents all the resources that have been 1463 locked. If an UNLOCK is successfully executed on this token, all 1464 associated resources are unlocked. If the lock cannot be granted to 1465 all resources, a 207 (Multistatus) status code MUST be returned with 1466 a response entity body containing a multistatus XML element 1467 describing which resource(s) prevented the lock from being granted. 1469 Hence, partial success is not an option. Either the entire hierarchy 1470 is locked or no resources are locked. 1472 B.1.1.3 Interaction with other Methods 1474 The interaction of a LOCK with various methods is dependent upon the 1475 lock type. However, independent of lock type, a successful DELETE of 1476 a resource MUST cause all of its locks to be removed. 1478 B.2 HTTP Headers for Distributed Authoring 1480 B.2.1 If Header 1482 [[anchor72: Add "If" header considerations: --reschke]] 1484 Appendix C. GULP 1486 *Copied from 1487 *. 1490 C.1 Directly vs Indirectly 1492 A lock either directly or indirectly locks a resource. 1494 C.2 Creating Locks 1496 A LOCK request with a non-empty body creates a new lock, and the 1497 resource identified by the Request-URI is directly locked by that 1498 lock. The "lock-root" of the new lock is the Request-URI. If at the 1499 time of the request, the Request-URI is not mapped to a resource, a 1500 new resource with empty content MUST be created by the request. 1502 C.3 Lock Inheritance 1504 If a collection is directly locked by a depth:infinity lock, all 1505 members of that collection (other than the collection itself) are 1506 indirectly locked by that lock. In particular, if an internal member 1507 resource is added to a collection that is locked by a depth:infinity 1508 lock, and if the resource is not locked by that lock, then the 1509 resource becomes indirectly locked by that lock. Conversely, if a 1510 resource is indirectly locked with a depth:infinity lock, and if the 1511 result of deleting an internal member URI is that the resource is no 1512 longer a member of the collection that is directly locked by that 1513 lock, then the resource is no longer locked by that lock. 1515 C.4 Removing Locks 1517 An UNLOCK request deletes the lock with the specified lock token. 1518 The Request-URI of the request MUST identify a resource that is 1519 either directly or indirectly locked by that lock. After a lock is 1520 deleted, no resource is locked by that lock. 1522 C.5 Submitting Lock Tokens 1524 A lock token is "submitted" in a request when it appears in an "If" 1525 request header. 1527 C.6 Locked State 1529 If a request would modify the content for a locked resource, a dead 1530 property of a locked resource, a live property that is defined to be 1531 lockable for a locked resource, or an internal member URI of a locked 1532 collection, the request MUST fail unless the lock-token for that lock 1533 is submitted in the request. An internal member URI of a collection 1534 is considered to be modified if it is added, removed, or identifies a 1535 different resource. 1537 C.7 URL protection 1539 If a request causes a directly locked resource to no longer be mapped 1540 to the lock-root of that lock, then the request MUST fail unless the 1541 lock-token for that lock is submitted in the request. If the request 1542 succeeds, then that lock MUST have been deleted by that request. 1544 C.8 Exclusive vs Shared 1546 If a request would cause a resource to be locked by two different 1547 exclusive locks, the request MUST fail. 1549 Appendix D. 'opaquelocktoken' URI Scheme 1551 The opaquelocktoken URI scheme is designed to be unique across all 1552 resources for all time. Due to this uniqueness quality, a client may 1553 submit an opaque lock token in an If header on a resource other than 1554 the one that returned it. 1556 All resources MUST recognize the opaquelocktoken scheme and, at 1557 minimum, recognize that the lock token does not refer to an 1558 outstanding lock on the resource. 1560 In order to guarantee uniqueness across all resources for all time 1561 the opaquelocktoken requires the use of the Universal Unique 1562 Identifier (UUID) mechanism, as described in [ISO-11578]. 1564 Opaquelocktoken generators, however, have a choice of how they create 1565 these tokens. They can either generate a new UUID for every lock 1566 token they create or they can create a single UUID and then add 1567 extension characters. If the second method is selected then the 1568 program generating the extensions MUST guarantee that the same 1569 extension will never be used twice with the associated UUID. 1571 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID 1572 production is the string representation of a UUID, as defined in 1573 [ISO-11578]. Note that white space (LWS) is not allowed between 1574 elements of this production. 1576 Extension = path ; path is defined in [draft-fielding-rfc2396bis], 1577 section 3.3. 1579 D.1 Node Field Generation Without the IEEE 802 Address 1581 UUIDs, as defined in [ISO-11578], contain a "node" field that 1582 contains one of the IEEE 802 addresses for the server machine. As 1583 noted in Section 11.1, there are several security risks associated 1584 with exposing a machine's IEEE 802 address. This section provides an 1585 alternate mechanism for generating the "node" field of a UUID which 1586 does not employ an IEEE 802 address. WebDAV servers MAY use this 1587 algorithm for creating the node field when generating UUIDs. The 1588 text in this section is originally from an Internet-Draft by Paul 1589 Leach and Rich Salz, who are noted here to properly attribute their 1590 work. 1592 The ideal solution is to obtain a 47 bit cryptographic quality random 1593 number, and use it as the low 47 bits of the node ID, with the most 1594 significant bit of the first octet of the node ID set to 1. This bit 1595 is the unicast/multicast bit, which will never be set in IEEE 802 1596 addresses obtained from network cards; hence, there can never be a 1597 conflict between UUIDs generated by machines with and without network 1598 cards. 1600 If a system does not have a primitive to generate cryptographic 1601 quality random numbers, then in most systems there are usually a 1602 fairly large number of sources of randomness available from which one 1603 can be generated. Such sources are system specific, but often 1604 include: 1606 o the percent of memory in use 1608 o the size of main memory in bytes 1610 o the amount of free main memory in bytes 1611 o the size of the paging or swap file in bytes 1613 o free bytes of paging or swap file 1615 o the total size of user virtual address space in bytes 1617 o the total available user address space bytes 1619 o the size of boot disk drive in bytes 1621 o the free disk space on boot drive in bytes 1623 o the current time 1625 o the amount of time since the system booted 1627 o the individual sizes of files in various system directories 1629 o the creation, last read, and modification times of files in 1630 various system directories 1632 o the utilization factors of various system resources (heap, etc.) 1634 o current mouse cursor position 1636 o current caret position 1638 o current number of running processes, threads 1640 o handles or IDs of the desktop window and the active window 1642 o the value of stack pointer of the caller 1644 o the process and thread ID of caller 1646 o various processor architecture specific performance counters 1647 (instructions executed, cache misses, TLB misses) 1649 (Note that it is precisely the above kinds of sources of randomness 1650 that are used to seed cryptographic quality random number generators 1651 on systems without special hardware for their construction.) 1653 In addition, items such as the computer's name and the name of the 1654 operating system, while not strictly speaking random, will help 1655 differentiate the results from those obtained by other systems. 1657 The exact algorithm to generate a node ID using these data is system 1658 specific, because both the data available and the functions to obtain 1659 them are often very system specific. However, assuming that one can 1660 concatenate all the values from the randomness sources into a buffer, 1661 and that a cryptographic hash function such as MD5 is available, then 1662 any 6 bytes of the MD5 hash of the buffer, with the multicast bit 1663 (the high bit of the first byte) set will be an appropriately random 1664 node ID. 1666 Other hash functions, such as SHA-1, can also be used. The only 1667 requirement is that the result be suitably random in the sense that 1668 the outputs from a set uniformly distributed inputs are themselves 1669 uniformly distributed, and that a single bit change in the input can 1670 be expected to cause half of the output bits to change. 1672 Appendix E. Change Log (to be removed by RFC Editor before publication) 1674 E.1 Since draft-reschke-webdav-locking-00 1676 Add and resolve issue "rfc2606-compliance". Resolve issues 1677 "extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL", 1678 "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS", 1679 "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02", 1680 "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL", 1681 "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION", 1682 "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC", 1683 "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK", 1684 "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS", 1685 "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and 1686 "111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work 1687 on moving text from RFC2518 excerpts into new sections. Define new 1688 compliance class "locking" (similar to "bis" in RFC2518bis, but only 1689 relevant to locking). Reformatted "GULP" into separate subsections 1690 for easier reference. 1692 E.2 Since draft-reschke-webdav-locking-01 1694 Update "008_URI_URL", "040_LOCK_ISSUES_06", 1695 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY", 1696 "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN". 1697 Re-opened "065_UNLOCK_WHAT_URL". Close 1698 "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK 1699 refresh method descriptions. Fix page title (TXT version). Close 1700 "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH", 1701 "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and 1702 resolve "8.10.1_lockdiscovery_on_failure". Started attempt to 1703 clarify status code. 1705 E.3 Since draft-reschke-webdav-locking-02 1707 Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04", 1708 "040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS", 1709 "067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN". 1710 Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version 1711 (5.7). Add and resolve new issue "7.5_DELETE_vs_URIs". Start work 1712 on "additional marshalling" and "introduction". Update issues 1713 "044_REPORT_OTHER_RESOURCE_LOCKED" and 1714 "066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL". 1716 E.4 Since draft-reschke-webdav-locking-03 1718 Close issues "import-rfc3253-stuff", "008_URI_URL", 1719 "015_MOVE_SECTION_6.4.1_TO_APPX", "044_REPORT_OTHER_RESOURCE_LOCKED", 1720 "056_DEPTH_LOCK_AND_IF" and "072_LOCK_URL_WITH_NO_PARENT_COLLECTION". 1721 Reformat condition name descriptions. Add mention of condition 1722 failure signalling to "Changes" appendix. Start edit of header 1723 descriptions (Depth, Timeout) and LOCK creation description. Open 1724 and close issue "3.2_lockdiscovery_depth". Start work on intro. 1726 E.5 Since draft-reschke-webdav-locking-04 1728 Add description of the lock as a resource and it's state (merging in 1729 Timeout semantics from old headers section). Close issues 1730 "040_LOCK_ISSUES_06", 1731 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY" and 1732 "088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED". Move edited version of 1733 "Write Lock" chapter. 1735 E.6 Since draft-reschke-webdav-locking-05 1737 Add and close issues "rfc2396bis" and 1738 "5.2.1-depth_header_vs_lock_refresh". Fixed DAV:lockdiscovery 1739 example. 1741 Appendix F. Resolved issues (to be removed by RFC Editor before 1742 publication) 1744 Issues that were either rejected or resolved in this version of this 1745 document. 1747 F.1 rfc2396bis 1749 Type: edit 1751 julian.reschke@greenbytes.de (2004-12-04): Update references to 1752 RFC2396 with draft-fielding-uri-rfc2396bis-07. 1754 Resolution (2004-12-04): Done. 1756 F.2 5.2.1-depth_header_vs_lock_refresh 1758 Type: change 1760 1763 stanley.guan@oracle.com (2003-12-18): Under the topic of "Refreshing 1764 Locks", it hints that Client may include a Timeout header. But, 1765 Depth header has not being mentioned. Under the topic of "Depth and 1766 Locking", it discussed what will happen if "Depth" header is 1767 specified for creating a new lock. But, nothing was mentioned on 1768 what's its implication on a lock refreshing command. 1770 Resolution (2004-07-17): Clarify that servers MUST ignore the Depth 1771 header upon LOCK refresh. See 1772 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0059.htm 1773 l. 1775 Appendix G. Open issues (to be removed by RFC Editor prior to 1776 publication) 1778 G.1 import-gulp 1780 Type: change 1782 julian.reschke@greenbytes.de (2004-05-25): Make specification text 1783 compatible with GULP where it isn't. Integrate GULP as normative 1784 specification of the locking behaviour. 1786 G.2 edit 1788 Type: edit 1790 julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for 1791 editorial fixes/enhancements. 1793 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION 1795 Type: change 1797 1800 ccjason@us.ibm.com (): What resource should be flagged in the 1801 multistatus response to locking issues in COPY/MOVE requests? 1802 Resolution: Resolved to flag the locking errors at the source 1803 resource that was affected by the problem. The details of how to 1804 describe the error was deferred to a subsequent version of WebDAV. - 1805 6/15/02 - 2518bis does not reflect this. 1807 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION 1809 Type: change 1811 1814 (): The method of describing the details of (beyond what resolved by 1815 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of 1816 various locking and ACL COPY/MOVE problems is deferred. Two 1817 proposals were outlined in the discussion, but interest was not great 1818 and we clearly don't have interoperability to take these proposals 1819 forward. 1821 G.5 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL 1823 Type: change 1825 (): Right now the server uses the IF: header to verify that a client 1826 knows what locks it has that are affected by an operation before it 1827 allows the operation. Must the client provide the root URL of a 1828 lock, any URL for a pertainent loc, or some specific URL in the IF: 1829 header. 1831 ccjason@us.ibm.com (): It is felt by the group that it's important 1832 that the client not just own and hold the lock token, but that it 1833 also know where the lock is rooted before it does tasks related to 1834 that lock. This is just a point of info. The issue itself still 1835 needs to be brought up and answered.still 1837 julian.reschke@greenbytes.de (): Summary: current implementations do 1838 not seem to care (see 1839 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0190.htm 1840 l). Suggestion to require clients to specify the lock root anyway, 1841 because this is what the WG agreed upon earlier. 1843 Index 1845 4 1846 423 Locked (status code) 26 1848 C 1849 Condition Names 1850 DAV:create-lock (post) 19 1851 DAV:create-resource (post) 19 1852 DAV:lock-removal-allowed (pre) 25 1853 DAV:lock-removed (post) 26 1854 DAV:lock-submission-allowed (pre) 23 1855 DAV:lock-token-matches (pre) 25 1856 DAV:lock-token-submission-allowed (pre) 27 1857 DAV:locks-refreshed (post) 23 1858 DAV:name-allowed (pre) 27 1859 DAV:need-lock-token (pre) 27 1860 DAV:parent-resource-must-be-non-null (pre) 27 1862 D 1863 DAV header 1864 compliance class '2' 29 1865 compliance class 'locking' 29 1866 DAV:create-lock postcondition 19 1867 DAV:create-resource postcondition 19 1868 DAV:lock-removal-allowed precondition 25 1869 DAV:lock-removed postcondition 26 1870 DAV:lock-submission-allowed precondition 23 1871 DAV:lock-token-matches precondition 25 1872 DAV:lock-token-submission-allowed precondition 27 1873 DAV:lockdiscovery property 16 1874 DAV:locks-refreshed postcondition 23 1875 DAV:name-allowed precondition 27 1876 DAV:need-lock-token precondition 27 1877 DAV:parent-resource-must-be-non-null precondition 27 1878 DAV:supportedlock property 18 1880 H 1881 Headers 1882 Lock-Token 28 1883 Timeout 29 1885 L 1886 LOCK method 18 1887 lock creation 19 1888 lock refresh 23 1889 Lock-Token header 28 1891 M 1892 Methods 1893 LOCK (lock creation) 19 1894 LOCK (lock refresh) 23 1895 LOCK 18 1896 UNLOCK 25 1898 O 1899 opaquelocktoken (URI scheme) 35 1901 P 1902 Properties 1903 DAV:lockdiscovery 16 1904 DAV:supportedlock 18 1906 S 1907 Status Codes 1908 423 Locked 26 1910 T 1911 Timeout header 29 1913 U 1914 UNLOCK method 25 1915 URI schemes 1916 opaquelocktoken 35 1918 Intellectual Property Statement 1920 The IETF takes no position regarding the validity or scope of any 1921 Intellectual Property Rights or other rights that might be claimed to 1922 pertain to the implementation or use of the technology described in 1923 this document or the extent to which any license under such rights 1924 might or might not be available; nor does it represent that it has 1925 made any independent effort to identify any such rights. Information 1926 on the procedures with respect to rights in RFC documents can be 1927 found in BCP 78 and BCP 79. 1929 Copies of IPR disclosures made to the IETF Secretariat and any 1930 assurances of licenses to be made available, or the result of an 1931 attempt made to obtain a general license or permission for the use of 1932 such proprietary rights by implementers or users of this 1933 specification can be obtained from the IETF on-line IPR repository at 1934 http://www.ietf.org/ipr. 1936 The IETF invites any interested party to bring to its attention any 1937 copyrights, patents or patent applications, or other proprietary 1938 rights that may cover technology that may be required to implement 1939 this standard. Please address the information to the IETF at 1940 ietf-ipr@ietf.org. 1942 Disclaimer of Validity 1944 This document and the information contained herein are provided on an 1945 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1946 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1947 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1948 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1949 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1950 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1952 Copyright Statement 1954 Copyright (C) The Internet Society (2004). This document is subject 1955 to the rights, licenses and restrictions contained in BCP 78, and 1956 except as set forth therein, the authors retain all their rights. 1958 Acknowledgment 1960 Funding for the RFC Editor function is currently provided by the 1961 Internet Society.