idnits 2.17.1 draft-reschke-webdav-locking-08.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1870. ** 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. 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 (October 5, 2005) is 6777 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) ** 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 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) October 5, 2005 5 Expires: April 8, 2006 7 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol 8 draft-reschke-webdav-locking-08 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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 April 8, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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 Editorial Note (to be removed by RFC Editor before publication) 49 [[docstate: Note that this document is not a product of the WebDAV 50 working group. It is just an experiment to study the feasability of 51 extracing the locking feature into a separate specification. 52 --reschke]] 54 Distribution of this document is unlimited. Please send comments to 55 the WebDAV working group at , which may 56 be joined by sending a message with subject "subscribe" to 57 . Discussions of the WEBDAV 58 working group are archived at 59 . 61 An issues list and XML and HTML versions of this draft are available 62 from 63 . 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.2 Method Preconditions and Postconditions . . . . . . . . . 6 70 1.3 Document Organization . . . . . . . . . . . . . . . . . . 7 71 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 7 72 2.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . . 7 73 2.1.1 Lock Compatibility Table . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 11 79 2.5.2 Lock Scope . . . . . . . . . . . . . . . . . . . . . . 11 80 2.5.3 Lock Root . . . . . . . . . . . . . . . . . . . . . . 11 81 2.5.4 Lock Depth . . . . . . . . . . . . . . . . . . . . . . 11 82 2.5.5 Client-supplied Lock Owner Information (optional) . . 11 83 2.5.6 Lock Creator (optional) . . . . . . . . . . . . . . . 11 84 2.5.7 Lock Timeout . . . . . . . . . . . . . . . . . . . . . 12 85 2.6 Active Lock Discovery . . . . . . . . . . . . . . . . . . 12 86 2.7 Usage Considerations . . . . . . . . . . . . . . . . . . . 12 87 3. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.1 Methods Restricted by Write Locks . . . . . . . . . . . . 14 89 3.2 Write Locks and Properties . . . . . . . . . . . . . . . . 14 90 3.3 Write Locks and Collections . . . . . . . . . . . . . . . 14 91 3.4 Write Locks and the If Request Header . . . . . . . . . . 15 92 3.4.1 Example - Write Lock . . . . . . . . . . . . . . . . . 15 93 3.5 Write Locks and COPY/MOVE . . . . . . . . . . . . . . . . 16 94 4. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 4.1 Common XML elements used in property values . . . . . . . 16 96 4.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 16 97 4.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 16 98 4.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 16 99 4.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 18 100 4.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 18 101 4.3.1 Examples for the DAV:supportedlock property . . . . . 19 102 5. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 5.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 19 104 5.1.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 19 105 5.1.2 Postconditions . . . . . . . . . . . . . . . . . . . . 20 106 5.1.3 Example - Simple Lock Request . . . . . . . . . . . . 21 107 5.1.4 Example - Multi-Resource Lock Request . . . . . . . . 23 108 5.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 24 109 5.2.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 24 110 5.2.2 Preconditions . . . . . . . . . . . . . . . . . . . . 24 111 5.2.3 Postconditions . . . . . . . . . . . . . . . . . . . . 24 112 5.2.4 Example - Refreshing a Write Lock . . . . . . . . . . 25 114 6. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 26 115 6.1 Marshalling . . . . . . . . . . . . . . . . . . . . . . . 26 116 6.2 Preconditions . . . . . . . . . . . . . . . . . . . . . . 26 117 6.2.1 DAV:lock-token-matches precondition . . . . . . . . . 26 118 6.2.2 DAV:lock-removal-allowed precondition . . . . . . . . 26 119 6.3 Postconditions . . . . . . . . . . . . . . . . . . . . . . 27 120 6.3.1 DAV:lock-removed postcondition . . . . . . . . . . . . 27 121 6.4 Example - UNLOCK . . . . . . . . . . . . . . . . . . . . . 27 122 7. Additional status codes . . . . . . . . . . . . . . . . . . . 27 123 7.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . . . 27 124 8. Additional marshalling and method semantics for other 125 methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 126 8.1 Additional marshalling . . . . . . . . . . . . . . . . . . 28 127 8.1.1 DAV:name-allowed precondition . . . . . . . . . . . . 28 128 8.1.2 DAV:parent-resource-must-be-non-null precondition . . 28 129 8.2 Additional method semantics (preconditions) . . . . . . . 28 130 8.2.1 DAV:lock-token-submission-allowed precondition . . . . 28 131 8.2.2 DAV:need-lock-token precondition . . . . . . . . . . . 28 132 8.3 Additional method semantics (postconditions) . . . . . . . 29 133 8.3.1 DAV:lock-removed postcondition . . . . . . . . . . . . 29 134 9. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 135 9.1 Lock-Token request/response header . . . . . . . . . . . . 30 136 9.2 Timeout request header . . . . . . . . . . . . . . . . . . 30 137 10. Capability discovery . . . . . . . . . . . . . . . . . . . . 31 138 10.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 31 139 11. Security considerations . . . . . . . . . . . . . . . . . . 31 140 11.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 31 141 12. Internationalization Considerations . . . . . . . . . . . . 32 142 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 143 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 144 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 145 15.1 Normative References . . . . . . . . . . . . . . . . . . . 32 146 15.2 Informative References . . . . . . . . . . . . . . . . . . 33 147 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 148 A. Collected Locking Semantics . . . . . . . . . . . . . . . . . 33 149 A.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 33 150 A.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 34 151 A.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 34 152 A.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 34 153 A.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 34 154 A.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 34 155 A.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 34 156 A.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 35 157 B. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 35 158 B.1 Removed/Deprecated features . . . . . . . . . . . . . . . 35 159 B.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 35 160 B.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 35 161 B.2 Additional features . . . . . . . . . . . . . . . . . . . 35 162 B.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 36 163 B.2.2 Error Marshalling . . . . . . . . . . . . . . . . . . 36 164 C. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 36 165 C.1 HTTP Methods for Distributed Authoring . . . . . . . . . . 36 166 C.1.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 36 167 C.2 HTTP Headers for Distributed Authoring . . . . . . . . . . 36 168 C.2.1 If Header . . . . . . . . . . . . . . . . . . . . . . 36 169 D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 36 170 E. Change Log (to be removed by RFC Editor before publication) . 37 171 E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 37 172 E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 37 173 E.3 Since draft-reschke-webdav-locking-02 . . . . . . . . . . 37 174 E.4 Since draft-reschke-webdav-locking-03 . . . . . . . . . . 38 175 E.5 Since draft-reschke-webdav-locking-04 . . . . . . . . . . 38 176 E.6 Since draft-reschke-webdav-locking-05 . . . . . . . . . . 38 177 E.7 Since draft-reschke-webdav-locking-06 . . . . . . . . . . 38 178 E.8 Since draft-reschke-webdav-locking-07 . . . . . . . . . . 38 179 F. Resolved issues (to be removed by RFC Editor before 180 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 38 181 F.1 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 39 182 G. Open issues (to be removed by RFC Editor prior to 183 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39 184 G.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 185 G.2 safeness_and_idempotence . . . . . . . . . . . . . . . . . 39 186 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 39 187 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 39 188 G.5 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . . 40 189 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 190 Intellectual Property and Copyright Statements . . . . . . . . 43 192 1. Introduction 194 This document describes the "locking" extension to the Web 195 Distributed Authoring and Versioning (WebDAV) protocol that allows to 196 keep more than one person from working on a document at the same 197 time. This helps preventing the "lost update problem," in which 198 modifications are lost as first one author then another writes 199 changes without merging the other author's changes. 201 1.1 Terminology 203 The terminology used here follows and extends that in the WebDAV 204 Distributed Authoring Protocol specification [RFC2518]. 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 Since this document describes a set of extensions to the WebDAV 211 Distributed Authoring Protocol [RFC2518], itself an extension to the 212 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 213 elements is exactly the same as described in Section 2.1 of 214 [RFC2616]. Since this augmented BNF uses the basic production rules 215 provided in Section 2.2 of [RFC2616], these rules apply to this 216 document as well. 218 This document uses XML DTD fragments ([XML]) as a purely notational 219 convention. WebDAV request and response bodies cannot be validated 220 due to the specific extensibility rules defined in section 23 of 221 [RFC2518] and due to the fact that all XML elements defined by this 222 specification use the XML namespace name "DAV:". In particular: 224 o Element names use the "DAV:" namespace. 226 o Element ordering is irrelevant. 228 o Extension elements/attributes (elements/attributes not already 229 defined as valid child elements) may be added anywhere, except 230 when explicitly stated otherwise. 232 1.2 Method Preconditions and Postconditions 234 A "precondition" of a method describes the state on the server that 235 must be true for that method to be performed. A "postcondition" of a 236 method describes the state on the server that must be true after that 237 method has completed. If a method precondition or postcondition for 238 a request is not satisfied and unless a more specific HTTP status 239 code applies, the response status of the request MUST be either 403 240 (Forbidden) if the request should not be repeated because it will 241 always fail, or 409 (Conflict) if it is expected that the user might 242 be able to resolve the conflict and resubmit the request. 244 In order to allow better client handling of error responses, a 245 distinct XML element type is associated with each method precondition 246 and postcondition of a request. When a particular precondition is 247 not satisfied or a particular postcondition cannot be achieved, the 248 appropriate XML element MUST be returned as the child of a top-level 249 DAV:error element in the response body, unless otherwise negotiated 250 by the request. In a 207 Multi-Status response, the DAV:error 251 element would appear in the appropriate DAV:responsedescription 252 element. 254 1.3 Document Organization 256 Sections 2 and 3 provide an overview of the locking feature in 257 general and write locks in particular. Additional new live 258 properties for feature discovery and lock discovery are defined in 259 Section 4. Sections 5 and 6 discuss the LOCK and UNLOCK method. 260 HTTP headers, status codes and additional marshalling for existing 261 WebDAV methods are defined in Sections 7 through 9. 263 Appendix A gives a complete summary of the locking semantics defined 264 by this document. Subsequent appendices discuss changes from 265 RFC2518, and the "opaquelocktoken" URI scheme. 267 2. Overview of Locking 269 The ability to lock a resource provides a mechanism for serializing 270 access to that resource. Using a lock, an authoring client can 271 provide a reasonable guarantee that another principal will not modify 272 a resource while it is being edited. In this way, a client can 273 prevent the "lost update" problem. 275 This specification allows locks to vary over two client-specified 276 parameters, the number of principals involved (exclusive vs. shared) 277 and the type of access to be granted. This document defines locking 278 for only one access type, write. However, the syntax is extensible, 279 and permits the eventual specification of locking for other access 280 types. 282 2.1 Exclusive Vs. Shared Locks 284 The most basic form of lock is an exclusive lock. This is a lock 285 where the access right in question is only granted to a single 286 principal. The need for this arbitration results from a desire to 287 avoid having to merge results. 289 However, there are times when the goal of a lock is not to exclude 290 others from exercising an access right but rather to provide a 291 mechanism for principals to indicate that they intend to exercise 292 their access rights. Shared locks are provided for this case. A 293 shared lock allows multiple principals to receive a lock. Hence any 294 principal with appropriate access can get the lock. 296 With shared locks there are two trust sets that affect a resource. 297 The first trust set is created by access permissions. Principals who 298 are trusted, for example, may have permission to write to the 299 resource. Among those who have access permission to write to the 300 resource, the set of principals who have taken out a shared lock also 301 must trust each other, creating a (typically) smaller trust set 302 within the access permission write set. 304 Starting with every possible principal on the Internet, in most 305 situations the vast majority of these principals will not have write 306 access to a given resource. Of the small number who do have write 307 access, some principals may decide to guarantee their edits are free 308 from overwrite conflicts by using exclusive write locks. Others may 309 decide they trust their collaborators will not overwrite their work 310 (the potential set of collaborators being the set of principals who 311 have write permission) and use a shared lock, which informs their 312 collaborators that a principal may be working on the resource. 314 This specification does not need to provide all of the communications 315 paths necessary for principals to coordinate their activities. When 316 using shared locks, principals may use any out of band communication 317 channel to coordinate their work (e.g., face-to-face interaction, 318 written notes, post-it notes on the screen, telephone conversation, 319 Email, etc.) The intent of a shared lock is to let collaborators 320 know who else may be working on a resource. 322 Shared locks are included because experience from web distributed 323 authoring systems has indicated that exclusive locks are often too 324 rigid. An exclusive lock is used to enforce a particular editing 325 process: take out an exclusive lock, read the resource, perform 326 edits, write the resource, release the lock. This editing process 327 has the problem that locks are not always properly released, for 328 example when a program crashes, or when a lock owner leaves without 329 unlocking a resource. While both timeouts and administrative action 330 can be used to remove an offending lock, neither mechanism may be 331 available when needed; the timeout may be long or the administrator 332 may not be available. With a shared lock, another user can at least 333 take out another shared lock and start modifying the resource. 335 2.1.1 Lock Compatibility Table 337 The table below describes the behavior that occurs when a lock 338 request is made on a resource. 340 +-------------------------+--------------------+--------------------+ 341 | Current lock state / | Shared Lock | Exclusive Lock | 342 | Lock request | | | 343 +-------------------------+--------------------+--------------------+ 344 | None | True | True | 345 | Shared Lock | True | False | 346 | Exclusive Lock | False | False* | 347 +-------------------------+--------------------+--------------------+ 349 Legend: True = lock may be granted. False = lock MUST NOT be 350 granted. *=It is illegal for a principal to request the same lock 351 twice. 353 The current lock state of a resource is given in the leftmost column, 354 and lock requests are listed in the first row. The intersection of a 355 row and column gives the result of a lock request. For example, if a 356 shared lock is held on a resource, and an exclusive lock is 357 requested, the table entry is "false", indicating the lock must not 358 be granted. 360 2.2 Required Support 362 A WebDAV compliant server is not required to support locking in any 363 form. If the server does support locking it may choose to support 364 any combination of exclusive and shared locks for any access types. 366 The reason for this flexibility is that locking policy strikes to the 367 very heart of the resource management and versioning systems employed 368 by various storage repositories. These repositories require control 369 over what sort of locking will be made available. For example, some 370 repositories only support shared write locks while others only 371 provide support for exclusive write locks while yet others use no 372 locking at all. As each system is sufficiently different to merit 373 exclusion of certain locking features, this specification leaves 374 locking as the sole axis of negotiation within WebDAV. 376 2.3 Lock Tokens 378 A lock token is a type of state token, represented as a URI, which 379 identifies a particular lock (see [RFC2518], section 9.4, for a 380 definition of state tokens). A lock token is returned by every 381 successful LOCK operation in the Lock-Token response header. The 382 lock token also appears in the value of the DAV:lockdiscovery 383 property, the value of which is returned in the body of the response 384 to a successful LOCK operation (note that this property also includes 385 the tokens of other current locks on the resource). 387 Lock token URIs MUST be unique across all resources for all time. 388 This uniqueness constraint allows lock tokens to be submitted across 389 resources and servers without fear of confusion. 391 This specification provides a lock token URI scheme called 392 "opaquelocktoken" that meets the uniqueness requirements. However 393 servers are free to use any URI scheme so long as it meets the 394 uniqueness requirements (for example, the "urn:uuid" URN namespace 395 defined in [RFC4122]). Note that only URI schemes registered by the 396 IETF can ensure uniqueness. 398 Submitting a lock token provides no special access rights. Anyone 399 can find out anyone else's lock token by performing lock discovery. 400 Locks MUST be enforced based upon whatever authentication mechanism 401 is used by the server, not based on the secrecy of the token values. 403 2.4 Lock Capability Discovery 405 Since server lock support is optional, a client trying to lock a 406 resource on a server can either try the lock and hope for the best, 407 or perform some form of discovery to determine what lock capabilities 408 the server supports. This is known as lock capability discovery. 409 Lock capability discovery differs from discovery of supported access 410 control types, since there may be access control types without 411 corresponding lock types. A client can determine what lock types the 412 server supports by retrieving the DAV:supportedlock property defined 413 in Section 4.3. 415 2.5 Status of a lock 417 A lock is identified by a URI (the lock token URI) but in general, it 418 does not have a HTTP URL, and thus can not be directly manipulated 419 using HTTP methods. Instead, this specification defines the new 420 methods LOCK (creating and refreshing locks, see Section 5) and 421 UNLOCK (removing locks, see Section 6) that act indirectly on locks. 423 A lock has state that can be indirectly observed by using the DAV: 424 lockdiscovery property defined in Section 4.2. At a minimum, the 425 state of a lock consists of the items defined in the sections below. 426 After lock creation, all parts of the state with the exception of the 427 timeout value are immutable. 429 2.5.1 Lock Access Type 431 At present, this specification only defines one lock access type, the 432 "write" lock defined in Section 3. 434 2.5.2 Lock Scope 436 A lock has either exclusive or shared scope (see Section 2.1). 438 2.5.3 Lock Root 440 A lock is created as effect of a LOCK (creation) method request. The 441 lock root is the URL to which this request was adressed. 443 2.5.4 Lock Depth 445 A "depth 0" lock only affects the resource to which the LOCK request 446 was adressed to (the lock root). This resource is said to be 447 "directly locked" by the lock. 449 On the other hand, a "depth infinity" lock on a collection 450 additionally affects all members of that collection. These resources 451 are said to be "indirectly locked" by the lock. A "depth infinity" 452 lock on a non-collection resource behaves exactly the same way as a 453 "depth 0" lock. 455 2.5.5 Client-supplied Lock Owner Information (optional) 457 Clients can submit information about the lock owner when creating a 458 lock. This information should be sufficient for either directly 459 contacting a principal (such as a telephone number or email URI), or 460 for discovering the principal (such as the URL of a homepage). 462 Owner information is kept with the lock so that it can be returned in 463 the DAV:lockdiscovery property upon request. Note that this 464 information is entirely client-controlled, thus a server MUST store 465 the information faithfully just like if it appeared in a WebDAV dead 466 property (see [RFC2518], section 4). 468 2.5.6 Lock Creator (optional) 470 When a lock has been created by an authenticated principal, the 471 server SHOULD keep information about that principal with the lock. 472 This enables the server to subsequently check whether a lock 473 identified by a lock token submitted in a request belongs to the same 474 principal on whose behalf the lock was initially created (see 475 Section 8.2.1 below). 477 2.5.7 Lock Timeout 479 In general, a lock expires after a certain amount of time. This time 480 can be specified in the LOCK creation request (however servers are 481 not required to honor this request). 483 If the timeout expires then the lock may be lost. Specifically, if 484 the server wishes to harvest the lock upon time-out, the server 485 SHOULD act as if an UNLOCK method was executed by the server on the 486 resource using the lock token of the timed-out lock, performed with 487 its override authority. Thus logs should be updated with the 488 disposition of the lock, notifications should be sent, etc., just as 489 they would be for an UNLOCK request. 491 The timers used for timeout expiry can be reset by the client by 492 submitting a LOCK refresh request. 494 Servers are advised to pay close attention to the values submitted by 495 clients, as they will be indicative of the type of activity the 496 client intends to perform. For example, an applet running in a 497 browser may need to lock a resource, but because of the instability 498 of the environment within which the applet is running, the applet may 499 be turned off without warning. As a result, the applet is likely to 500 ask for a relatively small timeout value so that if the applet dies, 501 the lock can be quickly harvested. However, a document management 502 system is likely to ask for an extremely long timeout because its 503 user may be planning on going off-line. 505 A client MUST NOT assume that just because the time-out has expired 506 the lock has been lost. Clients MUST assume that locks may 507 arbitrarily disappear at any time, regardless of the value given in 508 the Timeout header. The Timeout header only indicates the behavior 509 of the server if "extraordinary" circumstances do not occur. For 510 example, an administrator may remove a lock at any time or the system 511 may crash in such a way that it loses the record of the lock's 512 existence. 514 2.6 Active Lock Discovery 516 If another principal locks a resource that a principal wishes to 517 access, it is useful for the second principal to be able to find out 518 who the first principal is. For this purpose the DAV:lockdiscovery 519 property is provided. This property lists all outstanding locks, 520 describes their type, and where available, provides their lock token. 522 2.7 Usage Considerations 524 Although the locking mechanisms specified here provide some help in 525 preventing lost updates, they cannot guarantee that updates will 526 never be lost. Consider the following scenario: 528 o Two clients A and B are interested in editing the resource 529 'index.html'. Client A is an HTTP client rather than a WebDAV 530 client, and so does not know how to perform locking. 532 o Client A doesn't lock the document, but does a GET and begins 533 editing. 535 o Client B does LOCK, performs a GET and begins editing. 537 o Client B finishes editing, performs a PUT, then an UNLOCK. 539 o Client A performs a PUT, overwriting and losing all of B's 540 changes. 542 There are several reasons why the WebDAV protocol itself cannot 543 prevent this situation. First, it cannot force all clients to use 544 locking because it must be compatible with HTTP clients that do not 545 comprehend locking. Second, it cannot require servers to support 546 locking because of the variety of repository implementations, some of 547 which rely on reservations and merging rather than on locking. 548 Finally, being stateless, it cannot enforce a sequence of operations 549 like LOCK / GET / PUT / UNLOCK. 551 WebDAV servers that support locking can reduce the likelihood that 552 clients will accidentally overwrite each other's changes by requiring 553 clients to lock resources before modifying them. Such servers would 554 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying 555 resources. 557 WebDAV clients can be good citizens by using a lock / retrieve / 558 write /unlock sequence of operations (at least by default) whenever 559 they interact with a WebDAV server that supports locking. 561 HTTP 1.1 clients can be good citizens, avoiding overwriting other 562 clients' changes, by using entity tags in If-Match headers with any 563 requests that would modify resources. 565 Information managers may attempt to prevent overwrites by 566 implementing client-side procedures requiring locking before 567 modifying WebDAV resources. 569 3. Write Lock 571 This section describes the semantics specific to the write lock type. 572 The write lock is a specific instance of a lock type, and is the only 573 lock type described in this specification. 575 3.1 Methods Restricted by Write Locks 577 If a request would modify the content for a locked resource, a dead 578 property of a locked resource, a live property that is defined to be 579 lockable for a locked resource, or an internal member URI of a locked 580 collection, the request MUST fail unless the lock-token for that lock 581 is submitted in the request. An internal member URI of a collection 582 is considered to be modified if it is added, removed, or identifies a 583 different resource 585 3.2 Write Locks and Properties 587 While those without a write lock may not alter a property on a 588 resource it is still possible for the values of live properties to 589 change, even while locked, due to the requirements of their schemas. 590 Only dead properties and live properties defined to respect locks are 591 guaranteed not to change while write locked. 593 3.3 Write Locks and Collections 595 A write lock on a collection, whether created by a "Depth: 0" or 596 "Depth: infinity" lock request, prevents the addition or removal of 597 member URIs of the collection by non-lock owners. As a consequence, 598 when a principal issues a PUT or POST request to create a new 599 resource under a URI which needs to be an internal member of a write 600 locked collection to maintain HTTP namespace consistency, or issues a 601 DELETE to remove an internal member URI of a write locked collection, 602 this request MUST fail if the principal does not have a write lock on 603 the collection. 605 However, if a write lock request is issued to a collection containing 606 member URIs identifying resources that are currently locked in a 607 manner which conflicts with the write lock, the request MUST fail 608 with a 423 (Locked) status code (Note that this can only occur for a 609 request of a "Depth: infinity" write lock). 611 If a lock owner causes the URI of a resource to be added as an 612 internal member URI of a "Depth: infinity" locked collection then 613 the new resource MUST be automatically added to the lock. This is 614 the only mechanism that allows a resource to be added to a write 615 lock. Thus, for example, if the collection /a/b/ is write locked and 616 the resource /c is moved to /a/b/c then resource /a/b/c will be added 617 to the write lock. 619 3.4 Write Locks and the If Request Header 621 If a user agent is not required to have knowledge about a lock when 622 requesting an operation on a locked resource, the following scenario 623 might occur. Program A, run by User A, takes out a write lock on a 624 resource. Program B, also run by User A, has no knowledge of the 625 lock taken out by Program A, yet performs a PUT to the locked 626 resource. In this scenario, the PUT succeeds because locks are 627 associated with a principal, not a program, and thus program B, 628 because it is acting with principal A's credential, is allowed to 629 perform the PUT. However, had program B known about the lock, it 630 would not have overwritten the resource, preferring instead to 631 present a dialog box describing the conflict to the user. Due to 632 this scenario, a mechanism is needed to prevent different programs 633 from accidentally ignoring locks taken out by other programs with the 634 same authorization. 636 In order to prevent these collisions a lock token MUST be submitted 637 in the If header for all locked resources that a method may interact 638 with or the method MUST fail. For example, if a resource is to be 639 moved and both the source and destination are locked then two lock 640 tokens must be submitted, one for the source and the other for the 641 destination. 643 Servers SHOULD restrict usage of the lock token to exactly the 644 authenticated principal who created the lock. 646 3.4.1 Example - Write Lock 648 >>Request 650 COPY /~fielding/index.html HTTP/1.1 651 Host: example.com 652 Destination: http://example.com/users/f/fielding/index.html 653 If: 654 () 656 >>Response 658 HTTP/1.1 204 No Content 660 In this example, even though both the source and destination are 661 locked, only one lock token must be submitted, for the lock on the 662 destination. This is because the source resource is not modified by 663 a COPY, and hence unaffected by the write lock. In this example, 664 user agent authentication has previously occurred via a mechanism 665 outside the scope of the HTTP protocol, in the underlying transport 666 layer. 668 3.5 Write Locks and COPY/MOVE 670 A COPY method invocation MUST NOT duplicate any write locks active on 671 the source. However, as previously noted, if the COPY copies the 672 resource into a collection that is locked with "Depth: infinity", 673 then the resource will be added to the lock. 675 A successful MOVE request on a write locked resource MUST NOT move 676 the write lock with the resource. However, the resource is subject 677 to being added to an existing lock at the destination, as specified 678 in Section 3.3. For example, if the MOVE makes the resource a child 679 of a collection that is locked with "Depth: infinity", then the 680 resource will be added to that collection's lock. Additionally, if a 681 resource locked with "Depth: infinity" is moved to a destination that 682 is within the scope of the same lock (e.g., within the namespace tree 683 covered by the lock), the moved resource will again be a added to the 684 lock. In both these examples, as specified in Section 3.4, an If 685 header must be submitted containing a lock token for both the source 686 and destination. 688 4. Properties 690 Any DAV compliant resource that supports the LOCK method MUST support 691 the DAV:activelock and DAV:lockdiscovery properties defined below. 693 4.1 Common XML elements used in property values 695 4.1.1 Lock Scopes 697 698 699 701 4.1.2 Lock Types 703 704 706 4.2 DAV:lockdiscovery property 708 The DAV:lockdiscovery property returns a listing of who has a lock, 709 what type of lock he has, the timeout type, the time remaining on the 710 timeout, the associated lock token and the root of the lock. The 711 server is free to withhold any or all of this information if the 712 requesting principal does not have sufficient access rights to see 713 the requested data. 715 717 720 depth: the value of the Depth header (see Section 2.5.4; takes the 721 values "0" or "infinity"). 723 725 owner: provides information about the principal taking out a lock 726 (see Section 2.5.5). 728 730 timeout: the time remaining until timeout of a lock (see 731 Section 2.5.7). 733 735 locktoken: the lock token associated with a lock; the href element 736 contains the lock token. 738 739 741 lockroot: the URL that was specified as Request-URI in the LOCK 742 creation request; the href element contains the URL (see 743 Section 2.5.3). 745 746 748 4.2.1 Examples for the DAV:lockdiscovery 750 DAV:lockdiscovery property for a resource that has two shared write 751 locks on it, with infinite timeouts: 753 754 755 756 757 0 758 Jane Smith 759 Infinite 760 761 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 763 764 765 http://example.com/container/ 767 768 > 769 770 771 772 0 773 John Doe 774 Infinite 775 776 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77 778 779 780 http://example.com/container/ 782 783 784 786 DAV:lockdiscovery property for a resource with no locks on it: 788 790 4.3 DAV:supportedlock property 792 The DAV:supportedlock property of a resource returns a listing of the 793 combinations of scope and access types which may be specified in a 794 lock request on the resource. Note that the actual contents are 795 themselves controlled by access controls so a server is not required 796 to provide information the client is not authorized to see. 798 799 801 4.3.1 Examples for the DAV:supportedlock property 803 DAV:supportedlock property for a resource that supports both 804 exclusive and shares write locks: 806 807 808 809 810 811 812 813 814 815 817 DAV:supportedlock property for a resource that doesn't support any 818 locks at all: 820 822 5. LOCK Method 824 The following sections describe the LOCK method, which is used to 825 take out a lock of any access type or to refresh an existing lock. 827 5.1 Creating Locks 829 A LOCK method invocation with non-empty request body creates the lock 830 specified by the lockinfo XML element on the resource identified by 831 the Request-URI. 833 If the Request-URI identifies a null resource, the invocation MUST 834 create a new resource with empty content. 836 5.1.1 Marshalling 838 The request MAY include a "Timeout" header to be used as the timeout 839 value for the lock to be created (see Section 9.2). However, the 840 server is not required to honor or even consider this request. 842 The request MAY include a "Depth" header specifying either "0" or 843 "infinity" (see [RFC2518], section 9.2). If no "Depth" header is 844 submitted then the request MUST act as if a "Depth:infinity" had been 845 specified. 847 The request body MUST be a DAV:lockinfo element: 849 851 DAV:lockscope, DAV:locktype and DAV:owner are defined in Section 4. 853 The response body for a successful request MUST be a DAV:prop XML 854 element, containing the new value for the DAV:lockdiscovery property 855 defined in Section 4.2. The lock token URI for the new lock MUST be 856 returned in the "Lock-Token" response header (see Section 9.1). 858 If a "Depth: infinity" lock request fails because the lock could not 859 be granted to all resource, a 207 (Multistatus) status code MUST be 860 returned with a response entity body containing a multistatus XML 861 element describing which resource(s) prevented the lock from being 862 granted. Hence, partial success is not an option. 864 5.1.2 Postconditions 866 5.1.2.1 DAV:create-lock postcondition 868 The request MUST have created a new lock on the resource identified 869 by the Request-URI, having all the lock properties specified in the 870 request (with the exception of the Timeout request header). The 871 request MUST have allocated a distinct new lock token URI for the new 872 lock, and that URI MUST NOT ever identify anything other than that 873 lock. 875 5.1.2.2 DAV:create-resource postcondition 877 If the Request-URI identified a null resource, the method MUST have 878 created a new resource with empty content. 880 5.1.3 Example - Simple Lock Request 882 >>Request 884 LOCK /workspace/webdav/proposal.doc HTTP/1.1 885 Host: example.com 886 Timeout: Infinite, Second-4100000000 887 Content-Type: text/xml; charset="utf-8" 888 Content-Length: xxxx 889 Authorization: Digest username="ejw", 890 realm="ejw@example.com", nonce="...", 891 uri="/workspace/webdav/proposal.doc", 892 response="...", opaque="..." 894 895 896 897 898 899 http://example.org/~ejw/contact.html 900 901 903 >>Response 905 HTTP/1.1 200 OK 906 Lock-Token: 907 Content-Type: text/xml; charset="utf-8" 908 Content-Length: xxxx 910 911 912 913 914 915 916 Infinity 917 918 http://example.org/~ejw/contact.html 920 921 Second-604800 922 923 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 925 926 927 http://example.com/workspace/webdav/proposal.doc 929 930 931 932 934 This example shows the successful creation of an exclusive write lock 935 on resource http://example.com/workspace/webdav/proposal.doc. The 936 resource http:/example.org/~ejw/contact.html contains contact 937 information for the owner of the lock. The server has an activity- 938 based timeout policy in place on this resource, which causes the lock 939 to automatically be removed after 1 week (604800 seconds). 941 5.1.4 Example - Multi-Resource Lock Request 943 >>Request 945 LOCK /webdav/ HTTP/1.1 946 Host: example.com 947 Timeout: Infinite, Second-4100000000 948 Depth: infinity 949 Content-Type: text/xml; charset="utf-8" 950 Content-Length: xxxx 951 Authorization: Digest username="ejw", 952 realm="ejw@example.com", nonce="...", 953 uri="/workspace/webdav/proposal.doc", 954 response="...", opaque="..." 956 957 958 959 960 961 http://example.org/~ejw/contact.html 962 963 965 >>Response 967 HTTP/1.1 207 Multi-Status 968 Content-Type: text/xml; charset="utf-8" 969 Content-Length: xxxx 971 972 973 974 /webdav/secret 975 HTTP/1.1 403 Forbidden 976 977 978 /webdav/ 979 HTTP/1.1 424 Failed Dependency 980 981 983 This example shows a request for an exclusive write lock on a 984 collection and all its children. In this request, the client has 985 specified that it desires an infinite length lock, if available, 986 otherwise a timeout of 4.1 billion seconds, if available. The 987 request entity body contains the contact information for the 988 principal taking out the lock, in this case a web page URL. 990 The error is a 403 (Forbidden) response on the resource 991 http://example.com/webdav/secret. Because this resource could not be 992 locked, none of the resources were locked. 994 5.2 Refreshing Locks 996 A LOCK request with no request body is a "LOCK refresh" request. 997 It's purpose is to restart all timers associated with a lock. 999 5.2.1 Marshalling 1001 The request MUST include an "If" header that contains the lock tokens 1002 of the locks to be refreshed (note there may be multiple in the case 1003 of shared locks). 1005 The request MAY include a "Timeout" header to be used as the new 1006 timeout value for the lock(s) to be refreshed (see Section 9.2). 1008 The request MAY include a "Depth" header specifying either "0" or 1009 "infinity" (see [RFC2518], section 9.2) which MUST be ignored when 1010 present. 1012 The response to a successful lock refresh request MUST contain the 1013 value of the current DAV:lockdiscovery property in a prop XML 1014 element. 1016 5.2.2 Preconditions 1018 5.2.2.1 DAV:lock-submission-allowed precondition 1020 See Section 8.2.1. 1022 5.2.3 Postconditions 1024 5.2.3.1 DAV:locks-refreshed postcondition 1026 Timers associated with the those locks submitted in the "If" request 1027 header whose lock root is the resource identified by the Request-URI 1028 MUST be reset to their original value (or alternatively to the new 1029 value given in the "Timeout" request header). 1031 5.2.4 Example - Refreshing a Write Lock 1033 >>Request 1035 LOCK /workspace/webdav/proposal.doc HTTP/1.1 1036 Host: example.com 1037 Timeout: Infinite, Second-4100000000 1038 If: () 1039 Authorization: Digest username="ejw", 1040 realm="ejw@example.com", nonce="...", 1041 uri="/workspace/webdav/proposal.doc", 1042 response="...", opaque="..." 1044 >>Response 1046 HTTP/1.1 200 OK 1047 Content-Type: text/xml; charset="utf-8" 1048 Content-Length: xxxx 1050 1051 1052 1053 1054 1055 1056 Infinity 1057 1058 http://example.org/~ejw/contact.html 1060 1061 Second-604800 1062 1063 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 1065 1066 1067 http://example.com/workspace/webdav/proposal.doc 1069 1070 1071 1072 1074 This request would refresh the lock, resetting any time outs. Notice 1075 that the client asked for an infinite time out but the server choose 1076 to ignore the request. 1078 6. UNLOCK Method 1080 The UNLOCK method removes the lock identified by the lock token in 1081 the Lock-Token request header from the resource identified by the 1082 Request-URI, and all other resources included in the lock. Note that 1083 the UNLOCK request may be submitted to any resource locked by that 1084 lock (even those that are locked indirectly). 1086 If all resources which have been locked under the submitted lock 1087 token can not be unlocked then the UNLOCK request MUST fail. 1089 Any DAV compliant resource which supports the LOCK method MUST 1090 support the UNLOCK method. 1092 A server MAY allow principals other than a lock owner to unlock a 1093 resource. In this case, this capability SHOULD be under access 1094 control (see [RFC3744], section 3.5). Note that there is a tradeoff 1095 in allowing non-owners of a lock to unlock a resource. It can be 1096 beneficial to allow non-lock owners to perform UNLOCK requests 1097 because it allows the adminstrator of the server to configure the 1098 server to grant longer lock timeouts because the administrator knows 1099 that there is a process in place to allow users to deal with 1100 forgotten locks left by other users. On the other hand, a 1101 disadvantage of unlocking someone else's lock is that can create a 1102 situation where two users are working on modifications to the same 1103 resource at the same time which can result in a client having to 1104 perform an merge that wasn't previously planned. 1106 6.1 Marshalling 1108 The request MUST include a "Lock-Token" header (see Section 9.1) that 1109 identifies the lock to be removed. 1111 6.2 Preconditions 1113 6.2.1 DAV:lock-token-matches precondition 1115 The lock identified by the "Lock-Token" request header exists, and 1116 the resource identified by the Request-URI indeed is directly locked 1117 by the specified lock. 1119 6.2.2 DAV:lock-removal-allowed precondition 1121 As dicussed above, the principal authenticated for the UNLOCK request 1122 MUST be allowed to remove the identified lock (note that servers that 1123 support the "WebDAV Access Control Protocol" should use the DAV:need- 1124 privileges precondition defined in section 7.1.1 of [RFC3744]). 1126 6.3 Postconditions 1128 6.3.1 DAV:lock-removed postcondition 1130 The lock MUST have been removed from all resources included in the 1131 lock. 1133 6.4 Example - UNLOCK 1135 >>Request 1137 UNLOCK /workspace/webdav/info.doc HTTP/1.1 1138 Host: example.com 1139 Lock-Token: 1140 Authorization: Digest username="ejw", 1141 realm="ejw@example.com", nonce="...", 1142 uri="/workspace/webdav/proposal.doc", 1143 response="...", opaque="..." 1145 >>Response 1147 HTTP/1.1 204 No Content 1149 In this example, the lock identified by the lock token 1150 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 1151 successfully removed from the resource 1152 http://example.com/workspace/webdav/info.doc. If this lock included 1153 more than just one resource, the lock is removed from all resources 1154 included in the lock. Note that clients MUST interpret any of the 1155 success status codes defined in [RFC2616], section 10.2 as success 1156 codes. 204 (No Content) was used here merely for consistency with the 1157 example in [RFC2518], section 8.11.1). The remainder of the document 1158 discusses Capability Discovery, Security Considerations, 1159 Internationalization Considerations and IANA Considerations. 1160 Appendices discuss changes from RFC2518 (Appendix B) and the 1161 "opaquelocktoken" URI scheme (Appendix D). 1163 7. Additional status codes 1165 7.1 423 Locked 1167 The 423 (Locked) status code means the source or destination resource 1168 of a method is locked. 1170 8. Additional marshalling and method semantics for other methods 1171 8.1 Additional marshalling 1173 This section defines additional condition names (see Section 1.2) 1174 that apply to all methods. 1176 8.1.1 DAV:name-allowed precondition 1178 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1179 create a new internal member URI inside a collection resource, the 1180 last path segment of that URI must specify a name that is available 1181 as a resource name (for instance, servers may disallow path segments 1182 that -- after being URI-unescaped -- aren't valid UTF-8 octet 1183 sequences). [[anchor41: Copied from 1184 draft-ietf-webdav-redirectref-protocol. --reschke]] 1186 8.1.2 DAV:parent-resource-must-be-non-null precondition 1188 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1189 create a new internal member URI inside a collection resource, that 1190 collection resource must be non-null. [[anchor43: Copied from 1191 draft-ietf-webdav-redirectref-protocol. --reschke]] 1193 8.2 Additional method semantics (preconditions) 1195 This section defines names (see Section 1.2) for new conditions 1196 introduced by locking semantics. Otherwise noted otherwise, they 1197 apply to all methods. 1199 8.2.1 DAV:lock-token-submission-allowed precondition 1201 If the server restricts usage of the lock token inside an "If" 1202 request header to specific principals, the authenticated principal 1203 for this request MUST be one of them. 1205 8.2.2 DAV:need-lock-token precondition 1207 If a request would modify the content for a locked resource, a dead 1208 property of a locked resource, a live property that is defined to be 1209 lockable for a locked resource, or an internal member URI of a locked 1210 collection, the request MUST fail unless the lock-token for that lock 1211 is submitted in the request. An internal member URI of a collection 1212 is considered to be modified if it is added, removed, or identifies a 1213 different resource. 1215 1217 Servers SHOULD insert DAV:href elements for the URLs of each root of 1218 a lock for which a lock token was needed, unless that URL identies 1219 the same resource to that the request was sent. 1221 8.2.2.1 Example 1223 In the example below, a client unaware of a "Depth: infinity" lock on 1224 the parent collection "/workspace/webdav/" attempts to modify the 1225 collection member "/workspace/webdav/proposal.doc". 1227 >>Request 1229 PUT /workspace/webdav/proposal.doc HTTP/1.1 1230 Host: example.com 1232 >>Response 1234 HTTP/1.1 423 Locked 1235 Content-Type: text/xml; charset="utf-8" 1236 Content-Length: xxxx 1238 1239 1240 1241 /workspace/webdav/ 1242 1243 1245 8.3 Additional method semantics (postconditions) 1247 8.3.1 DAV:lock-removed postcondition 1249 If an operation (such as a MOVE or a DELETE request) causes a 1250 directly locked resource to no longer be mapped to the lock-root of 1251 that lock, that lock MUST have been deleted by that request. 1253 8.3.1.1 Example 1255 In this example, a client renames a collection "/workspace/webdav" 1256 containing the locked member "/workspace/webdav/proposal.doc" (with 1257 lock token "urn:uuid:FC28D97C-569E-411e-86BC-D30A233DD8A2"). 1259 >>Request 1261 MOVE /workspace/webdav/ HTTP/1.1 1262 Host: example.com 1263 Destination: http://example.com/workspace/deltav/ 1264 If: 1265 () 1267 >>Response 1269 HTTP/1.1 201 Created 1271 After executing the MOVE request, the member resource will now be 1272 mapped to "/workspace/deltav/proposal.doc", but not to "/workspace/ 1273 webdav/proposal.doc" anymore. Therefore, the lock will be removed. 1275 9. Headers 1277 9.1 Lock-Token request/response header 1279 Lock-Token = "Lock-Token" ":" Coded-URL 1280 ; Coded-URL: see [RFC2518], Section 9.4. 1282 The Lock-Token request header is used with the UNLOCK method to 1283 identify the lock to be removed. The lock token in the Lock-Token 1284 request header MUST identify a lock that contains the resource 1285 identified by Request-URI as a member. 1287 The Lock-Token response header is used with the LOCK method to 1288 indicate the lock token created as a result of a successful LOCK 1289 request to create a new lock. 1291 Note that the "Lock-Token" request header does not contribute to the 1292 precondition checks defined for the HTTP status 412 (see [RFC2616], 1293 section 10.4.13). 1295 9.2 Timeout request header 1297 TimeOut = "Timeout" ":" 1#TimeType 1298 TimeType = (TimeTypeSec | "Infinite" | Other) 1299 TypeTypeSec = "Second-" 1*digit 1300 Other = "Extend" field-value 1301 ; field-value: see [RFC2616], Section 4.2 1303 (Linear white space (LWS) MUST NOT be used inside "TimeTypeSec".) 1305 Clients MUST NOT submit a Timeout request header with any method 1306 other than a LOCK method. 1308 A Timeout request header MUST contain at least one TimeType and may 1309 contain multiple TimeType entries. The purpose of listing multiple 1310 TimeType entries is to indicate multiple different values and value 1311 types that are acceptable to the client. The client lists the 1312 TimeType entries in order of preference. 1314 Timeout response values MUST use a Second value, Infinite, or a 1315 TimeType the client has indicated familiarity with. The server may 1316 assume a client is familiar with any TimeType submitted in a Timeout 1317 header. 1319 The "Second" TimeType specifies the number of seconds that will 1320 elapse between granting of the lock at the server, and the automatic 1321 removal of the lock. The timeout value for TimeType "Second" MUST 1322 NOT be greater than 2^32-1. 1324 10. Capability discovery 1326 10.1 OPTIONS method 1328 If the server supports locking, it MUST return both the compliance 1329 class names "2" and "locking" as fields in the "DAV" response header 1330 (see [RFC2518], section 9.1) from an OPTIONS request on any resource 1331 implemented by that server. A value of "2" or "locking" in the "DAV" 1332 response header MUST indicate that the server meets all class "1" 1333 requirements defined in [RFC2518] and supports all MUST level 1334 requirements and REQUIRED features specified in this document, 1335 including: 1337 o LOCK and UNLOCK methods, 1339 o DAV:lockdiscovery and DAV:supportedlock properties, 1341 o "Time-Out" request header, "Lock-Token" request and response 1342 header. 1344 Note that for servers implementing this specification, the compliance 1345 classes "2" and "locking" are synonymous. However, new clients can 1346 take advantage of the new "locking" compliance class to detect server 1347 support for changes introduced by this specification (see 1348 Appendix B). 1350 11. Security considerations 1352 All security considerations mentioned in [RFC2518] also apply to this 1353 document. Additionally, lock tokens introduce new privacy issues 1354 discussed below. 1356 11.1 Privacy Issues Connected to Locks 1358 When submitting a lock request a user agent may also submit an owner 1359 XML field giving contact information for the person taking out the 1360 lock (for those cases where a person, rather than a robot, is taking 1361 out the lock). This contact information is stored in a DAV: 1362 lockdiscovery property on the resource, and can be used by other 1363 collaborators to begin negotiation over access to the resource. 1364 However, in many cases this contact information can be very private, 1365 and should not be widely disseminated. Servers SHOULD limit read 1366 access to the DAV:lockdiscovery property as appropriate. 1367 Furthermore, user agents SHOULD provide control over whether contact 1368 information is sent at all, and if contact information is sent, 1369 control over exactly what information is sent. 1371 12. Internationalization Considerations 1373 All internationalization considerations mentioned in [RFC2518] also 1374 apply to this document. 1376 13. IANA Considerations 1378 This specification updates the definition of the "opaquelocktoken" 1379 URI scheme described in Appendix D, registered my means of [RFC2518], 1380 section 6.4. There are no additional IANA considerations. 1382 14. Acknowledgements 1384 This document is the collaborative product of 1386 o the authors, 1388 o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault 1389 - and 1391 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron 1392 Goland, Del Jensen and Jim Whitehead. 1394 This document has also benefited from thoughtful discussion by Mark 1395 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, 1396 Rickard Falk, Eric Glass, Stanley Guan, Larry Masinter, Joe Orton, 1397 Juergen Pill, Elias Sinderson, Greg Stein, Kevin Wiggen, and other 1398 members of the WebDAV working group. 1400 15. References 1402 15.1 Normative References 1404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1405 Requirement Levels", BCP 14, RFC 2119, March 1997. 1407 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1408 Jensen, "HTTP Extensions for Distributed Authoring -- 1409 WEBDAV", RFC 2518, February 1999. 1411 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1412 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1413 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1415 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1416 Resource Identifier (URI): Generic Syntax", STD 66, 1417 RFC 3986, January 2005. 1419 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A UUID URN 1420 Namespace", RFC 4122, July 2005. 1422 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1423 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1424 Edition)", W3C REC-xml-20040204, February 2004, 1425 . 1427 15.2 Informative References 1429 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1430 Distributed Authoring and Versioning (WebDAV) Access 1431 Control Protocol", RFC 3744, May 2004. 1433 Author's Address 1435 Julian F. Reschke 1436 greenbytes GmbH 1437 Salzmannstrasse 152 1438 Muenster, NW 48159 1439 Germany 1441 Phone: +49 251 2807760 1442 Fax: +49 251 2807761 1443 Email: julian.reschke@greenbytes.de 1444 URI: http://greenbytes.de/tech/webdav/ 1446 Appendix A. Collected Locking Semantics 1448 This section provides a complete summary of the semantics for (write) 1449 locks. 1451 A.1 Directly vs Indirectly 1453 A lock either directly or indirectly locks a resource. (See 1454 Section 2.5.4) 1456 A.2 Creating Locks 1458 A LOCK request with a non-empty body creates a new lock, and the 1459 resource identified by the Request-URI is directly locked by that 1460 lock. The "lock-root" of the new lock is the Request-URI. If at the 1461 time of the request, the Request-URI is not mapped to a resource, a 1462 new resource with empty content MUST be created by the request. (See 1463 Section 5.1) 1465 A.3 Lock Inheritance 1467 If a collection is directly locked by a depth:infinity lock, all 1468 members of that collection (other than the collection itself) are 1469 indirectly locked by that lock. In particular, if an internal member 1470 resource is added to a collection that is locked by a depth:infinity 1471 lock, and if the resource is not locked by that lock, then the 1472 resource becomes indirectly locked by that lock. Conversely, if a 1473 resource is indirectly locked with a depth:infinity lock, and if the 1474 result of deleting an internal member URI is that the resource is no 1475 longer a member of the collection that is directly locked by that 1476 lock, then the resource is no longer locked by that lock. (See 2.5.4 1477 and 3.5). 1479 A.4 Removing Locks 1481 An UNLOCK request deletes the lock with the specified lock token. 1482 The Request-URI of the request MUST identify a resource that is 1483 either directly or indirectly locked by that lock. After a lock is 1484 deleted, no resource is locked by that lock. (See Section 6) 1486 A.5 Submitting Lock Tokens 1488 A lock token is "submitted" in a request when it appears in an "If" 1489 request header. (See Section 3.4) 1491 A.6 Locked State 1493 If a request would modify the content for a locked resource, a dead 1494 property of a locked resource, a live property that is defined to be 1495 lockable for a locked resource, or an internal member URI of a locked 1496 collection, the request MUST fail unless the lock-token for that lock 1497 is submitted in the request. An internal member URI of a collection 1498 is considered to be modified if it is added, removed, or identifies a 1499 different resource. (See 3.1 and 8.2.2). 1501 A.7 URL protection 1503 If a request causes a directly locked resource to no longer be mapped 1504 to the lock-root of that lock, then the request MUST fail unless the 1505 lock-token for that lock is submitted in the request. If the request 1506 succeeds, then that lock MUST have been deleted by that request. 1507 (See 3.5, 8.2.2 and 8.3.1) 1509 A.8 Exclusive vs Shared 1511 If a request would cause a resource to be locked by two different 1512 exclusive locks, the request MUST fail. (See Section 2.1) 1514 Appendix B. Changes to RFC2518 1516 See Section 10 for a description about how clients can discover 1517 support for this version of the WebDAV Locking protocol. 1519 B.1 Removed/Deprecated features 1521 B.1.1 Implicit lock refresh 1523 In section 9.8, [RFC2518] specifies that locks should be refreshed 1524 implicitly every time "...any time an owner of the lock sends a 1525 method to any member of the lock, including unsupported methods, or 1526 methods which are unsuccessful." This features has been removed 1527 (locks need to be refreshed explicitly using the LOCK method). 1529 Compatibility consideration: clients historically have never relied 1530 on this feature as it was never implemented in widely deployed WebDAV 1531 servers. 1533 B.1.2 Lock-null resources 1535 In section 7.4, [RFC2518] specifies a special resource type called 1536 "lock-null resource" that's being created when a LOCK method request 1537 is applied to a null resource. In practice, no real interoperability 1538 was achieved because many servers failed to implement this feature 1539 properly and few clients (if any) ever relied on that particular 1540 functionality. 1542 Removing this feature also means that there is no atomic way to 1543 create a collection in locked state, but in practice, this doesn't 1544 seem to be a problem. 1546 Compatibility consideration: there do not seem to be any widely 1547 deployed clients that actually relied on "lock-null resources". 1549 B.2 Additional features 1550 B.2.1 DAV:lockroot element in DAV:activelock 1552 Clients can take advantage of the new DAV:lockroot element to 1553 discover the URL to which the LOCK request (that created the lock) 1554 was applied. 1556 Compatibility consideration: clients will have to fail gracefully 1557 when communicating with older servers that do not support the new 1558 element. 1560 B.2.2 Error Marshalling 1562 Clients can take advantage of additional, detailed error information 1563 using the DAV:error element defined in Section 1.2. 1565 Compatibility consideration: old clients should not even notice the 1566 additional informations. New clients SHOULD handle absence of 1567 additional error information gracefully. 1569 Appendix C. Text to be integrated from RFC2518 1571 C.1 HTTP Methods for Distributed Authoring 1573 C.1.1 LOCK Method 1575 C.1.1.1 Locking Replicated Resources 1577 A resource may be made available through more than one URI. However 1578 locks apply to resources, not URIs. Therefore a LOCK request on a 1579 resource MUST NOT succeed if can not be honored by all the URIs 1580 through which the resource is addressable. 1582 C.2 HTTP Headers for Distributed Authoring 1584 C.2.1 If Header 1586 [[anchor61: Add "If" header considerations: --reschke]] 1588 Appendix D. 'opaquelocktoken' URI Scheme 1590 The opaquelocktoken URI scheme is designed to be unique across all 1591 resources for all time. Due to this uniqueness quality, a client may 1592 submit an opaque lock token in an If header on a resource other than 1593 the one that returned it. 1595 All resources MUST recognize the opaquelocktoken scheme and, at 1596 minimum, recognize that the lock token does not refer to an 1597 outstanding lock on the resource. 1599 In order to guarantee uniqueness across all resources for all time 1600 the opaquelocktoken requires the use of the Universal Unique 1601 Identifier (UUID) mechanism, as described in Section 4 of [RFC4122]. 1603 OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] 1604 ; UUID: see [RFC4122], Section 3. 1605 ; path: see [RFC3986], Section 3.3. 1607 Appendix E. Change Log (to be removed by RFC Editor before publication) 1609 E.1 Since draft-reschke-webdav-locking-00 1611 Add and resolve issue "rfc2606-compliance". Resolve issues "extract- 1612 locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL", 1613 "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS", 1614 "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02", 1615 "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL", 1616 "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION", 1617 "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC", 1618 "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK", 1619 "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS", 1620 "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and 1621 "111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work 1622 on moving text from RFC2518 excerpts into new sections. Define new 1623 compliance class "locking" (similar to "bis" in RFC2518bis, but only 1624 relevant to locking). Reformatted "GULP" into separate subsections 1625 for easier reference. 1627 E.2 Since draft-reschke-webdav-locking-01 1629 Update "008_URI_URL", "040_LOCK_ISSUES_06", 1630 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY", 1631 "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN". Re- 1632 opened "065_UNLOCK_WHAT_URL". Close 1633 "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK 1634 refresh method descriptions. Fix page title (TXT version). Close 1635 "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH", 1636 "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and 1637 resolve "8.10.1_lockdiscovery_on_failure". Started attempt to 1638 clarify status code. 1640 E.3 Since draft-reschke-webdav-locking-02 1642 Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04", 1643 "040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS", 1644 "067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN". 1645 Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version 1646 (5.7). Add and resolve new issue "7.5_DELETE_vs_URIs". Start work 1647 on "additional marshalling" and "introduction". Update issues 1648 "044_REPORT_OTHER_RESOURCE_LOCKED" and 1649 "066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL". 1651 E.4 Since draft-reschke-webdav-locking-03 1653 Close issues "import-rfc3253-stuff", "008_URI_URL", 1654 "015_MOVE_SECTION_6.4.1_TO_APPX", "044_REPORT_OTHER_RESOURCE_LOCKED", 1655 "056_DEPTH_LOCK_AND_IF" and "072_LOCK_URL_WITH_NO_PARENT_COLLECTION". 1656 Reformat condition name descriptions. Add mention of condition 1657 failure signalling to "Changes" appendix. Start edit of header 1658 descriptions (Depth, Timeout) and LOCK creation description. Open 1659 and close issue "3.2_lockdiscovery_depth". Start work on intro. 1661 E.5 Since draft-reschke-webdav-locking-04 1663 Add description of the lock as a resource and it's state (merging in 1664 Timeout semantics from old headers section). Close issues 1665 "040_LOCK_ISSUES_06", 1666 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY" and 1667 "088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED". Move edited version of 1668 "Write Lock" chapter. 1670 E.6 Since draft-reschke-webdav-locking-05 1672 Add and close issues "rfc2396bis" and "5.2.1- 1673 depth_header_vs_lock_refresh". Fixed DAV:lockdiscovery example. 1675 E.7 Since draft-reschke-webdav-locking-06 1677 Add and resolve issues "uri_draft_ref", "abnf", 1678 "D_delegate_UUID_definition" and "lock_state_auth_principal". 1680 E.8 Since draft-reschke-webdav-locking-07 1682 Editorial fixes (whitespace, duplicate DTD fragment, Document 1683 Organization section). Resolve issue "import_gulp": keep the 1684 semantics summary as normative appendix, also make it the first one 1685 (no change tracking for the move). Add "lock-removed" postcondition. 1686 Update urn:uuid reference. 1688 Appendix F. Resolved issues (to be removed by RFC Editor before 1689 publication) 1691 Issues that were either rejected or resolved in this version of this 1692 document. 1694 F.1 import-gulp 1696 Type: change 1698 julian.reschke@greenbytes.de (2004-05-25): Make specification text 1699 compatible with GULP where it isn't. Integrate GULP as normative 1700 specification of the locking behaviour. 1702 Resolution (2005-05-16): Integrate GULP as is, let remaining text 1703 refer to it where appropriate. Also add pointers from GULP back into 1704 the main document. Rename section to "Collected Method Semantics. 1706 Appendix G. Open issues (to be removed by RFC Editor prior to 1707 publication) 1709 G.1 edit 1711 Type: edit 1713 julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for 1714 editorial fixes/enhancements. 1716 G.2 safeness_and_idempotence 1718 Type: edit 1720 julian.reschke@greenbytes.de (2005-03-02): Specify safeness and 1721 idempotence of LOCK and UNLOCK methods. 1723 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION 1725 Type: change 1727 1730 ccjason@us.ibm.com (): What resource should be flagged in the 1731 multistatus response to locking issues in COPY/MOVE requests? 1733 Resolution: Resolved to flag the locking errors at the source 1734 resource that was affected by the problem. The details of how to 1735 describe the error was deferred to a subsequent version of WebDAV. - 1736 6/15/02 - 2518bis does not reflect this. 1738 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION 1740 Type: change 1741 1744 (): The method of describing the details of (beyond what resolved by 1745 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of 1746 various locking and ACL COPY/MOVE problems is deferred. Two 1747 proposals were outlined in the discussion, but interest was not great 1748 and we clearly don't have interoperability to take these proposals 1749 forward. 1751 G.5 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL 1753 Type: change 1755 (): Right now the server uses the IF: header to verify that a client 1756 knows what locks it has that are affected by an operation before it 1757 allows the operation. Must the client provide the root URL of a 1758 lock, any URL for a pertainent loc, or some specific URL in the IF: 1759 header. 1761 ccjason@us.ibm.com (): It is felt by the group that it's important 1762 that the client not just own and hold the lock token, but that it 1763 also know where the lock is rooted before it does tasks related to 1764 that lock. This is just a point of info. The issue itself still 1765 needs to be brought up and answered.still 1767 julian.reschke@greenbytes.de (): Summary: current implementations do 1768 not seem to care (see http://lists.w3.org/Archives/Public/ 1769 w3c-dist-auth/2004AprJun/0190.html). Suggestion to require clients 1770 to specify the lock root anyway, because this is what the WG agreed 1771 upon earlier. 1773 Index 1775 4 1776 423 Locked (status code) 27 1778 C 1779 Condition Names 1780 DAV:create-lock (post) 20 1781 DAV:create-resource (post) 20 1782 DAV:lock-removal-allowed (pre) 26 1783 DAV:lock-removed (post) 27, 29 1784 DAV:lock-submission-allowed (pre) 24 1785 DAV:lock-token-matches (pre) 26 1786 DAV:lock-token-submission-allowed (pre) 28 1787 DAV:locks-refreshed (post) 24 1788 DAV:name-allowed (pre) 28 1789 DAV:need-lock-token (pre) 28 1790 DAV:parent-resource-must-be-non-null (pre) 28 1792 D 1793 DAV header 1794 compliance class '2' 31 1795 compliance class 'locking' 31 1796 DAV:create-lock postcondition 20 1797 DAV:create-resource postcondition 20 1798 DAV:lock-removal-allowed precondition 26 1799 DAV:lock-removed postcondition 27, 29 1800 DAV:lock-submission-allowed precondition 24 1801 DAV:lock-token-matches precondition 26 1802 DAV:lock-token-submission-allowed precondition 28 1803 DAV:lockdiscovery property 16 1804 DAV:locks-refreshed postcondition 24 1805 DAV:name-allowed precondition 28 1806 DAV:need-lock-token precondition 28 1807 DAV:parent-resource-must-be-non-null precondition 28 1808 DAV:supportedlock property 18 1810 H 1811 Headers 1812 Lock-Token 30 1813 Timeout 30 1815 L 1816 LOCK method 19 1817 lock creation 19 1818 lock refresh 24 1819 Lock-Token header 30 1821 M 1822 Methods 1823 LOCK (lock creation) 19 1824 LOCK (lock refresh) 24 1825 LOCK 19 1826 UNLOCK 26 1828 O 1829 opaquelocktoken (URI scheme) 36 1831 P 1832 Properties 1833 DAV:lockdiscovery 16 1834 DAV:supportedlock 18 1836 S 1837 Status Codes 1838 423 Locked 27 1840 T 1841 Timeout header 30 1843 U 1844 UNLOCK method 26 1845 URI schemes 1846 opaquelocktoken 36 1848 Intellectual Property Statement 1850 The IETF takes no position regarding the validity or scope of any 1851 Intellectual Property Rights or other rights that might be claimed to 1852 pertain to the implementation or use of the technology described in 1853 this document or the extent to which any license under such rights 1854 might or might not be available; nor does it represent that it has 1855 made any independent effort to identify any such rights. Information 1856 on the procedures with respect to rights in RFC documents can be 1857 found in BCP 78 and BCP 79. 1859 Copies of IPR disclosures made to the IETF Secretariat and any 1860 assurances of licenses to be made available, or the result of an 1861 attempt made to obtain a general license or permission for the use of 1862 such proprietary rights by implementers or users of this 1863 specification can be obtained from the IETF on-line IPR repository at 1864 http://www.ietf.org/ipr. 1866 The IETF invites any interested party to bring to its attention any 1867 copyrights, patents or patent applications, or other proprietary 1868 rights that may cover technology that may be required to implement 1869 this standard. Please address the information to the IETF at 1870 ietf-ipr@ietf.org. 1872 Disclaimer of Validity 1874 This document and the information contained herein are provided on an 1875 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1876 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1877 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1878 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1879 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1880 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1882 Copyright Statement 1884 Copyright (C) The Internet Society (2005). This document is subject 1885 to the rights, licenses and restrictions contained in BCP 78, and 1886 except as set forth therein, the authors retain all their rights. 1888 Acknowledgment 1890 Funding for the RFC Editor function is currently provided by the 1891 Internet Society.