idnits 2.17.1 draft-reschke-webdav-locking-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1868. ** 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 (February 15, 2005) is 7004 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: 7 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) February 15, 2005 5 Expires: August 19, 2005 7 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol 8 draft-reschke-webdav-locking-07 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 19, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document specifies a set of methods and headers ancillary to 44 HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, 45 RFC2518) for the management of resource locking (collision 46 avoidance). It updates those sections from RFC2518 that specify 47 WebDAV's locking features. 49 Editorial Note (to be removed by RFC Editor before publication) 51 [[anchor1: Note that this document is not a product of the WebDAV 52 working group. It is just an experiment to study the feasability of 53 extracing the locking feature into a separate specification. 54 --reschke]] 56 Distribution of this document is unlimited. Please send comments to 57 the WebDAV working group at , which may 58 be joined by sending a message with subject "subscribe" to 59 . Discussions of the WEBDAV 60 working group are archived at 61 . 63 An issues list and XML and HTML versions of this draft are available 64 from 65 . 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 71 1.2 Method Preconditions and Postconditions . . . . . . . . . 6 72 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 7 73 2.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . . 7 74 2.1.1 Lock Compatibility Table . . . . . . . . . . . . . . . 9 75 2.2 Required Support . . . . . . . . . . . . . . . . . . . . . 9 76 2.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . . . 9 77 2.4 Lock Capability Discovery . . . . . . . . . . . . . . . . 10 78 2.5 Status of a lock . . . . . . . . . . . . . . . . . . . . . 10 79 2.5.1 Lock Access Type . . . . . . . . . . . . . . . . . . . 10 80 2.5.2 Lock Scope . . . . . . . . . . . . . . . . . . . . . . 11 81 2.5.3 Lock Root . . . . . . . . . . . . . . . . . . . . . . 11 82 2.5.4 Lock Depth . . . . . . . . . . . . . . . . . . . . . . 11 83 2.5.5 Client-supplied Lock Owner Information (optional) . . 11 84 2.5.6 Lock Creator (optional) . . . . . . . . . . . . . . . 11 85 2.5.7 Lock Timeout . . . . . . . . . . . . . . . . . . . . . 11 86 2.6 Active Lock Discovery . . . . . . . . . . . . . . . . . . 12 87 2.7 Usage Considerations . . . . . . . . . . . . . . . . . . . 12 88 3. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 3.1 Methods Restricted by Write Locks . . . . . . . . . . . . 14 90 3.2 Write Locks and Properties . . . . . . . . . . . . . . . . 14 91 3.3 Write Locks and Collections . . . . . . . . . . . . . . . 14 92 3.4 Write Locks and the If Request Header . . . . . . . . . . 14 93 3.4.1 Example - Write Lock . . . . . . . . . . . . . . . . . 15 94 3.5 Write Locks and COPY/MOVE . . . . . . . . . . . . . . . . 16 95 4. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 4.1 Common XML elements used in property values . . . . . . . 16 97 4.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 16 98 4.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 16 99 4.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 16 100 4.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 17 101 4.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 18 102 4.3.1 Examples for the DAV:supportedlock property . . . . . 19 103 5. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 5.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 19 105 5.1.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 19 106 5.1.2 Postconditions . . . . . . . . . . . . . . . . . . . . 20 107 5.1.3 Example - Simple Lock Request . . . . . . . . . . . . 21 108 5.1.4 Example - Multi-Resource Lock Request . . . . . . . . 23 109 5.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 24 110 5.2.1 Marshalling . . . . . . . . . . . . . . . . . . . . . 24 111 5.2.2 Preconditions . . . . . . . . . . . . . . . . . . . . 24 112 5.2.3 Postconditions . . . . . . . . . . . . . . . . . . . . 24 113 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 . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . 28 130 8.2.1 DAV:lock-token-submission-allowed precondition . . . . 28 131 8.2.2 DAV:need-lock-token precondition . . . . . . . . . . . 28 132 9. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 133 9.1 Lock-Token request/response header . . . . . . . . . . . . 29 134 9.2 Timeout request header . . . . . . . . . . . . . . . . . . 29 135 10. Capability discovery . . . . . . . . . . . . . . . . . . . . 30 136 10.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 30 137 11. Security considerations . . . . . . . . . . . . . . . . . . 31 138 11.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 31 139 12. Internationalization Considerations . . . . . . . . . . . . 31 140 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 141 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 143 15.1 Normative References . . . . . . . . . . . . . . . . . . . 32 144 15.2 Informative References . . . . . . . . . . . . . . . . . . 32 145 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 146 A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 33 147 A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 33 148 A.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 33 149 A.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 33 150 A.2 Additional features . . . . . . . . . . . . . . . . . . . 34 151 A.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 34 152 A.2.2 Error Marshalling . . . . . . . . . . . . . . . . . . 34 153 B. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 34 154 B.1 HTTP Methods for Distributed Authoring . . . . . . . . . . 34 155 B.1.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 34 156 B.2 HTTP Headers for Distributed Authoring . . . . . . . . . . 35 157 B.2.1 If Header . . . . . . . . . . . . . . . . . . . . . . 35 158 C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 159 C.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 35 160 C.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 35 161 C.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 35 162 C.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 35 163 C.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 36 164 C.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 36 165 C.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 36 166 C.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 36 167 D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 36 168 E. Change Log (to be removed by RFC Editor before publication) . 37 169 E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 37 170 E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 37 171 E.3 Since draft-reschke-webdav-locking-02 . . . . . . . . . . 37 172 E.4 Since draft-reschke-webdav-locking-03 . . . . . . . . . . 38 173 E.5 Since draft-reschke-webdav-locking-04 . . . . . . . . . . 38 174 E.6 Since draft-reschke-webdav-locking-05 . . . . . . . . . . 38 175 E.7 Since draft-reschke-webdav-locking-06 . . . . . . . . . . 38 176 F. Resolved issues (to be removed by RFC Editor before 177 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 38 178 F.1 lock_state_auth_principal . . . . . . . . . . . . . . . . 38 179 F.2 abnf . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 180 F.3 uri_draft_ref . . . . . . . . . . . . . . . . . . . . . . 39 181 F.4 D_delegate_UUID_definition . . . . . . . . . . . . . . . . 39 182 G. Open issues (to be removed by RFC Editor prior to 183 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39 184 G.1 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 39 185 G.2 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 186 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 39 187 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 40 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 2. Overview of Locking 256 The ability to lock a resource provides a mechanism for serializing 257 access to that resource. Using a lock, an authoring client can 258 provide a reasonable guarantee that another principal will not modify 259 a resource while it is being edited. In this way, a client can 260 prevent the "lost update" problem. 262 This specification allows locks to vary over two client-specified 263 parameters, the number of principals involved (exclusive vs. shared) 264 and the type of access to be granted. This document defines locking 265 for only one access type, write. However, the syntax is extensible, 266 and permits the eventual specification of locking for other access 267 types. 269 2.1 Exclusive Vs. Shared Locks 271 The most basic form of lock is an exclusive lock. This is a lock 272 where the access right in question is only granted to a single 273 principal. The need for this arbitration results from a desire to 274 avoid having to merge results. 276 However, there are times when the goal of a lock is not to exclude 277 others from exercising an access right but rather to provide a 278 mechanism for principals to indicate that they intend to exercise 279 their access rights. Shared locks are provided for this case. A 280 shared lock allows multiple principals to receive a lock. Hence any 281 principal with appropriate access can get the lock. 283 With shared locks there are two trust sets that affect a resource. 284 The first trust set is created by access permissions. Principals who 285 are trusted, for example, may have permission to write to the 286 resource. Among those who have access permission to write to the 287 resource, the set of principals who have taken out a shared lock also 288 must trust each other, creating a (typically) smaller trust set 289 within the access permission write set. 291 Starting with every possible principal on the Internet, in most 292 situations the vast majority of these principals will not have write 293 access to a given resource. Of the small number who do have write 294 access, some principals may decide to guarantee their edits are free 295 from overwrite conflicts by using exclusive write locks. Others may 296 decide they trust their collaborators will not overwrite their work 297 (the potential set of collaborators being the set of principals who 298 have write permission) and use a shared lock, which informs their 299 collaborators that a principal may be working on the resource. 301 This specification does not need to provide all of the communications 302 paths necessary for principals to coordinate their activities. When 303 using shared locks, principals may use any out of band communication 304 channel to coordinate their work (e.g., face-to-face interaction, 305 written notes, post-it notes on the screen, telephone conversation, 306 Email, etc.) The intent of a shared lock is to let collaborators 307 know who else may be working on a resource. 309 Shared locks are included because experience from web distributed 310 authoring systems has indicated that exclusive locks are often too 311 rigid. An exclusive lock is used to enforce a particular editing 312 process: take out an exclusive lock, read the resource, perform 313 edits, write the resource, release the lock. This editing process 314 has the problem that locks are not always properly released, for 315 example when a program crashes, or when a lock owner leaves without 316 unlocking a resource. While both timeouts and administrative action 317 can be used to remove an offending lock, neither mechanism may be 318 available when needed; the timeout may be long or the administrator 319 may not be available. With a shared lock, another user can at least 320 take out another shared lock and start modifying the resource. 322 2.1.1 Lock Compatibility Table 324 The table below describes the behavior that occurs when a lock 325 request is made on a resource. 327 +-------------------------+--------------------+--------------------+ 328 | Current lock state / | Shared Lock | Exclusive Lock | 329 | Lock request | | | 330 +-------------------------+--------------------+--------------------+ 331 | None | True | True | 332 | Shared Lock | True | False | 333 | Exclusive Lock | False | False* | 334 +-------------------------+--------------------+--------------------+ 336 Legend: True = lock may be granted. False = lock MUST NOT be 337 granted. *=It is illegal for a principal to request the same lock 338 twice. 340 The current lock state of a resource is given in the leftmost column, 341 and lock requests are listed in the first row. The intersection of a 342 row and column gives the result of a lock request. For example, if a 343 shared lock is held on a resource, and an exclusive lock is 344 requested, the table entry is "false", indicating the lock must not 345 be granted. 347 2.2 Required Support 349 A WebDAV compliant server is not required to support locking in any 350 form. If the server does support locking it may choose to support 351 any combination of exclusive and shared locks for any access types. 353 The reason for this flexibility is that locking policy strikes to the 354 very heart of the resource management and versioning systems employed 355 by various storage repositories. These repositories require control 356 over what sort of locking will be made available. For example, some 357 repositories only support shared write locks while others only 358 provide support for exclusive write locks while yet others use no 359 locking at all. As each system is sufficiently different to merit 360 exclusion of certain locking features, this specification leaves 361 locking as the sole axis of negotiation within WebDAV. 363 2.3 Lock Tokens 365 A lock token is a type of state token, represented as a URI, which 366 identifies a particular lock (see [RFC2518], section 9.4, for a 367 definition of state tokens). A lock token is returned by every 368 successful LOCK operation in the Lock-Token response header. The 369 lock token also appears in the value of the DAV:lockdiscovery 370 property, the value of which is returned in the body of the response 371 to a successful LOCK operation (note that this property also includes 372 the tokens of other current locks on the resource). 374 Lock token URIs MUST be unique across all resources for all time. 375 This uniqueness constraint allows lock tokens to be submitted across 376 resources and servers without fear of confusion. 378 This specification provides a lock token URI scheme called 379 "opaquelocktoken" that meets the uniqueness requirements. However 380 servers are free to return any URI scheme so long as it meets the 381 uniqueness requirements. Note that only URI schemes registered by 382 the IETF can ensure uniqueness. 384 Submitting a lock token provides no special access rights. Anyone 385 can find out anyone else's lock token by performing lock discovery. 386 Locks MUST be enforced based upon whatever authentication mechanism 387 is used by the server, not based on the secrecy of the token values. 389 2.4 Lock Capability Discovery 391 Since server lock support is optional, a client trying to lock a 392 resource on a server can either try the lock and hope for the best, 393 or perform some form of discovery to determine what lock capabilities 394 the server supports. This is known as lock capability discovery. 395 Lock capability discovery differs from discovery of supported access 396 control types, since there may be access control types without 397 corresponding lock types. A client can determine what lock types the 398 server supports by retrieving the DAV:supportedlock property defined 399 in Section 4.3. 401 2.5 Status of a lock 403 A lock is identified by a URI (the lock token URI) but in general, it 404 does not have a HTTP URL, and thus can not be directly manipulated 405 using HTTP methods. Instead, this specification defines the new 406 methods LOCK (creating and refreshing locks, see Section 5) and 407 UNLOCK (removing locks, see Section 6) that act indirectly on locks. 409 A lock has state that can be indirectly observed by using the DAV: 410 lockdiscovery property defined in Section 4.2. At a minimum, the 411 state of a lock consists of the items defined in the sections below. 412 After lock creation, all parts of the state with the exception of the 413 timeout value are immutable. 415 2.5.1 Lock Access Type 417 At present, this specification only defines one lock access type, the 418 "write" lock defined in Section 3. 420 2.5.2 Lock Scope 422 A lock has either exclusive or shared scope (see Section 2.1). 424 2.5.3 Lock Root 426 A lock is created as effect of a LOCK (creation) method request. The 427 lock root is the URL to which this request was adressed. 429 2.5.4 Lock Depth 431 A "depth 0" lock only affects the resource to which the LOCK request 432 was adressed to (the lock root). This resource is said to be 433 "directly locked" by the lock. 435 On the other hand, a "depth infinity" lock on a collection 436 additionally affects all members of that collection. These resources 437 are said to be "indirectly locked" by the lock. A "depth infinity" 438 lock on a non-collection resource behaves exactly the same way as a 439 "depth 0" lock. 441 2.5.5 Client-supplied Lock Owner Information (optional) 443 Clients can submit information about the lock owner when creating a 444 lock. This information should be sufficient for either directly 445 contacting a principal (such as a telephone number or email URI), or 446 for discovering the principal (such as the URL of a homepage). 448 Owner information is kept with the lock so that it can be returned in 449 the DAV:lockdiscovery property upon request. Note that this 450 information is entirely client-controlled, thus a server MUST store 451 the information faithfully just like if it appeared in a WebDAV dead 452 property (see [RFC2518], section 4). 454 2.5.6 Lock Creator (optional) 456 When a lock has been created by an authenticated principal, the 457 server SHOULD keep information about that principal with the lock. 458 This enables the server to subsequently check whether a lock 459 identified by a lock token submitted in a request belongs to the same 460 principal on whose behalf the lock was initially created (see 461 Section 8.2.1 below). 463 2.5.7 Lock Timeout 465 In general, a lock expires after a certain amount of time. This time 466 can be specified in the LOCK creation request (however servers are 467 not required to honor this request). 469 If the timeout expires then the lock may be lost. Specifically, if 470 the server wishes to harvest the lock upon time-out, the server 471 SHOULD act as if an UNLOCK method was executed by the server on the 472 resource using the lock token of the timed-out lock, performed with 473 its override authority. Thus logs should be updated with the 474 disposition of the lock, notifications should be sent, etc., just as 475 they would be for an UNLOCK request. 477 The timers used for timeout expiry can be reset by the client by 478 submitting a LOCK refresh request. 480 Servers are advised to pay close attention to the values submitted by 481 clients, as they will be indicative of the type of activity the 482 client intends to perform. For example, an applet running in a 483 browser may need to lock a resource, but because of the instability 484 of the environment within which the applet is running, the applet may 485 be turned off without warning. As a result, the applet is likely to 486 ask for a relatively small timeout value so that if the applet dies, 487 the lock can be quickly harvested. However, a document management 488 system is likely to ask for an extremely long timeout because its 489 user may be planning on going off-line. 491 A client MUST NOT assume that just because the time-out has expired 492 the lock has been lost. Clients MUST assume that locks may 493 arbitrarily disappear at any time, regardless of the value given in 494 the Timeout header. The Timeout header only indicates the behavior 495 of the server if "extraordinary" circumstances do not occur. For 496 example, an administrator may remove a lock at any time or the system 497 may crash in such a way that it loses the record of the lock's 498 existence. 500 2.6 Active Lock Discovery 502 If another principal locks a resource that a principal wishes to 503 access, it is useful for the second principal to be able to find out 504 who the first principal is. For this purpose the DAV:lockdiscovery 505 property is provided. This property lists all outstanding locks, 506 describes their type, and where available, provides their lock token. 508 2.7 Usage Considerations 510 Although the locking mechanisms specified here provide some help in 511 preventing lost updates, they cannot guarantee that updates will 512 never be lost. Consider the following scenario: 514 o Two clients A and B are interested in editing the resource 515 'index.html'. Client A is an HTTP client rather than a WebDAV 516 client, and so does not know how to perform locking. 518 o Client A doesn't lock the document, but does a GET and begins 519 editing. 521 o Client B does LOCK, performs a GET and begins editing. 523 o Client B finishes editing, performs a PUT, then an UNLOCK. 525 o Client A performs a PUT, overwriting and losing all of B's 526 changes. 528 There are several reasons why the WebDAV protocol itself cannot 529 prevent this situation. First, it cannot force all clients to use 530 locking because it must be compatible with HTTP clients that do not 531 comprehend locking. Second, it cannot require servers to support 532 locking because of the variety of repository implementations, some of 533 which rely on reservations and merging rather than on locking. 534 Finally, being stateless, it cannot enforce a sequence of operations 535 like LOCK / GET / PUT / UNLOCK. 537 WebDAV servers that support locking can reduce the likelihood that 538 clients will accidentally overwrite each other's changes by requiring 539 clients to lock resources before modifying them. Such servers would 540 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying 541 resources. 543 WebDAV clients can be good citizens by using a lock / retrieve / 544 write /unlock sequence of operations (at least by default) whenever 545 they interact with a WebDAV server that supports locking. 547 HTTP 1.1 clients can be good citizens, avoiding overwriting other 548 clients' changes, by using entity tags in If-Match headers with any 549 requests that would modify resources. 551 Information managers may attempt to prevent overwrites by 552 implementing client-side procedures requiring locking before 553 modifying WebDAV resources. 555 3. Write Lock 557 This section describes the semantics specific to the write lock type. 558 The write lock is a specific instance of a lock type, and is the only 559 lock type described in this specification. 561 3.1 Methods Restricted by Write Locks 563 If a request would modify the content for a locked resource, a dead 564 property of a locked resource, a live property that is defined to be 565 lockable for a locked resource, or an internal member URI of a locked 566 collection, the request MUST fail unless the lock-token for that lock 567 is submitted in the request. An internal member URI of a collection 568 is considered to be modified if it is added, removed, or identifies a 569 different resource. [[anchor15: Copy of GULP, "Locked State". 570 --reschke]] 572 3.2 Write Locks and Properties 574 While those without a write lock may not alter a property on a 575 resource it is still possible for the values of live properties to 576 change, even while locked, due to the requirements of their schemas. 577 Only dead properties and live properties defined to respect locks are 578 guaranteed not to change while write locked. 580 3.3 Write Locks and Collections 582 A write lock on a collection, whether created by a "Depth: 0" or 583 "Depth: infinity" lock request, prevents the addition or removal of 584 member URIs of the collection by non-lock owners. As a consequence, 585 when a principal issues a PUT or POST request to create a new 586 resource under a URI which needs to be an internal member of a write 587 locked collection to maintain HTTP namespace consistency, or issues a 588 DELETE to remove an internal member URI of a write locked collection, 589 this request MUST fail if the principal does not have a write lock on 590 the collection. 592 However, if a write lock request is issued to a collection containing 593 member URIs identifying resources that are currently locked in a 594 manner which conflicts with the write lock, the request MUST fail 595 with a 423 (Locked) status code (Note that this can only occur for a 596 request of a "Depth: infinity" write lock). 598 If a lock owner causes the URI of a resource to be added as an 599 internal member URI of a "Depth: infinity" locked collection then 600 the new resource MUST be automatically added to the lock. This is 601 the only mechanism that allows a resource to be added to a write 602 lock. Thus, for example, if the collection /a/b/ is write locked and 603 the resource /c is moved to /a/b/c then resource /a/b/c will be added 604 to the write lock. 606 3.4 Write Locks and the If Request Header 608 If a user agent is not required to have knowledge about a lock when 609 requesting an operation on a locked resource, the following scenario 610 might occur. Program A, run by User A, takes out a write lock on a 611 resource. Program B, also run by User A, has no knowledge of the 612 lock taken out by Program A, yet performs a PUT to the locked 613 resource. In this scenario, the PUT succeeds because locks are 614 associated with a principal, not a program, and thus program B, 615 because it is acting with principal A's credential, is allowed to 616 perform the PUT. However, had program B known about the lock, it 617 would not have overwritten the resource, preferring instead to 618 present a dialog box describing the conflict to the user. Due to 619 this scenario, a mechanism is needed to prevent different programs 620 from accidentally ignoring locks taken out by other programs with the 621 same authorization. 623 In order to prevent these collisions a lock token MUST be submitted 624 in the If header for all locked resources that a method may interact 625 with or the method MUST fail. For example, if a resource is to be 626 moved and both the source and destination are locked then two lock 627 tokens must be submitted, one for the source and the other for the 628 destination. 630 Servers SHOULD restrict usage of the lock token to exactly the 631 authenticated principal who created the lock. 633 3.4.1 Example - Write Lock 635 >>Request 637 COPY /~fielding/index.html HTTP/1.1 638 Host: example.com 639 Destination: http://example.com/users/f/fielding/index.html 640 If: 641 () 643 >>Response 645 HTTP/1.1 204 No Content 647 In this example, even though both the source and destination are 648 locked, only one lock token must be submitted, for the lock on the 649 destination. This is because the source resource is not modified by 650 a COPY, and hence unaffected by the write lock. In this example, 651 user agent authentication has previously occurred via a mechanism 652 outside the scope of the HTTP protocol, in the underlying transport 653 layer. 655 3.5 Write Locks and COPY/MOVE 657 A COPY method invocation MUST NOT duplicate any write locks active on 658 the source. However, as previously noted, if the COPY copies the 659 resource into a collection that is locked with "Depth: infinity", 660 then the resource will be added to the lock. 662 A successful MOVE request on a write locked resource MUST NOT move 663 the write lock with the resource. However, the resource is subject 664 to being added to an existing lock at the destination, as specified 665 in Section 3.3. For example, if the MOVE makes the resource a child 666 of a collection that is locked with "Depth: infinity", then the 667 resource will be added to that collection's lock. Additionally, if a 668 resource locked with "Depth: infinity" is moved to a destination that 669 is within the scope of the same lock (e.g., within the namespace tree 670 covered by the lock), the moved resource will again be a added to the 671 lock. In both these examples, as specified in Section 3.4, an If 672 header must be submitted containing a lock token for both the source 673 and destination. 675 4. Properties 677 Any DAV compliant resource that supports the LOCK method MUST support 678 the DAV:activelock and DAV:lockdiscovery properties defined below. 680 4.1 Common XML elements used in property values 682 4.1.1 Lock Scopes 684 685 686 688 4.1.2 Lock Types 690 691 693 4.2 DAV:lockdiscovery property 695 The DAV:lockdiscovery property returns a listing of who has a lock, 696 what type of lock he has, the timeout type, the time remaining on the 697 timeout, the associated lock token and the root of the lock. The 698 server is free to withhold any or all of this information if the 699 requesting principal does not have sufficient access rights to see 700 the requested data. 702 704 707 depth: the value of the Depth header (see Section 2.5.4; takes the 708 values "0" or "infinity"). 710 712 owner: provides information about the principal taking out a lock 713 (see Section 2.5.5). 715 717 timeout: the time remaining until timeout of a lock (see 718 Section 2.5.7). 720 722 locktoken: the lock token associated with a lock; the href element 723 contains the lock token. 725 727 lockroot: the URL that was specified as Request-URI in the LOCK 728 creation request; the href element contains the URL(see 729 Section 2.5.3). 731 733 href: defined in [RFC2518], section 12.3. 735 737 4.2.1 Examples for the DAV:lockdiscovery 738 DAV:lockdiscovery property for a resource that has two shared write 739 locks on it, with infinite timeouts: 741 742 743 744 745 0 746 Jane Smith 747 Infinite 748 749 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 751 752 753 http://example.com/container/ 755 756 > 757 758 759 760 0 761 John Doe 762 Infinite 763 764 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77 766 767 768 http://example.com/container/ 770 771 772 774 DAV:lockdiscovery property for a resource with no locks on it: 776 778 4.3 DAV:supportedlock property 780 The DAV:supportedlock property of a resource returns a listing of the 781 combinations of scope and access types which may be specified in a 782 lock request on the resource. Note that the actual contents are 783 themselves controlled by access controls so a server is not required 784 to provide information the client is not authorized to see. 786 787 789 4.3.1 Examples for the DAV:supportedlock property 791 DAV:supportedlock property for a resource that supports both 792 exclusive and shares write locks: 794 795 796 797 798 799 800 801 802 803 805 DAV:supportedlock property for a resource that doesn't support any 806 locks at all: 808 810 5. LOCK Method 812 The following sections describe the LOCK method, which is used to 813 take out a lock of any access type or to refresh an existing lock. 815 5.1 Creating Locks 817 A LOCK method invocation with non-empty request body creates the lock 818 specified by the lockinfo XML element on the resource identified by 819 the Request-URI. If the Request-URI identifies a null resource, the 820 invocation MUST create a new resource with empty content. 822 5.1.1 Marshalling 824 The request MAY include a "Timeout" header to be used as the timeout 825 value for the lock to be created (see Section 9.2). However, the 826 server is not required to honor or even consider this request. 828 The request MAY include a "Depth" header specifying either "0" or 829 "infinity" (see [RFC2518], section 9.2). If no "Depth" header is 830 submitted then the request MUST act as if a "Depth:infinity" had been 831 specified. 833 The request body MUST be a DAV:lockinfo element: 835 837 DAV:lockscope, DAV:locktype and DAV:owner are defined in Section 4. 839 The response body for a successful request MUST be a DAV:prop XML 840 element, containing the new value for the DAV:lockdiscovery property 841 defined in Section 4.2. The lock token URI for the new lock MUST be 842 returned in the "Lock-Token" response header (see Section 9.1). 844 [[anchor26: Add preconditions for the validy of various parts of the 845 request body? --reschke]] 847 5.1.2 Postconditions 849 5.1.2.1 DAV:create-lock postcondition 851 The request MUST have created a new lock on the resource identified 852 by the Request-URI. The request MUST have allocated a distinct new 853 lock token URI for the new lock, and that URI MUST NOT ever identify 854 anything other than that lock. [[anchor29: Say what parts of the 855 request lock criteria must be followed. --reschke]] 857 5.1.2.2 DAV:create-resource postcondition 859 If the Request-URI identified a null resource, the method MUST have 860 created a new resource with empty content. 862 5.1.3 Example - Simple Lock Request 864 >>Request 866 LOCK /workspace/webdav/proposal.doc HTTP/1.1 867 Host: example.com 868 Timeout: Infinite, Second-4100000000 869 Content-Type: text/xml; charset="utf-8" 870 Content-Length: xxxx 871 Authorization: Digest username="ejw", 872 realm="ejw@example.com", nonce="...", 873 uri="/workspace/webdav/proposal.doc", 874 response="...", opaque="..." 876 877 878 879 880 881 http://example.org/~ejw/contact.html 882 883 885 >>Response 887 HTTP/1.1 200 OK 888 Lock-Token: 889 Content-Type: text/xml; charset="utf-8" 890 Content-Length: xxxx 892 893 894 895 896 897 898 Infinity 899 900 http://example.org/~ejw/contact.html 902 903 Second-604800 904 905 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 907 908 909 http://example.com/workspace/webdav/proposal.doc 911 912 913 914 916 This example shows the successful creation of an exclusive write lock 917 on resource http://example.com/workspace/webdav/proposal.doc. The 918 resource http:/example.org/~ejw/contact.html contains contact 919 information for the owner of the lock. The server has an activity- 920 based timeout policy in place on this resource, which causes the lock 921 to automatically be removed after 1 week (604800 seconds). 923 5.1.4 Example - Multi-Resource Lock Request 925 >>Request 927 LOCK /webdav/ HTTP/1.1 928 Host: example.com 929 Timeout: Infinite, Second-4100000000 930 Depth: infinity 931 Content-Type: text/xml; charset="utf-8" 932 Content-Length: xxxx 933 Authorization: Digest username="ejw", 934 realm="ejw@example.com", nonce="...", 935 uri="/workspace/webdav/proposal.doc", 936 response="...", opaque="..." 938 939 940 941 942 943 http://example.org/~ejw/contact.html 944 945 947 >>Response 949 HTTP/1.1 207 Multi-Status 950 Content-Type: text/xml; charset="utf-8" 951 Content-Length: xxxx 953 954 955 956 /webdav/secret 957 HTTP/1.1 403 Forbidden 958 959 960 /webdav/ 961 HTTP/1.1 424 Failed Dependency 962 963 965 This example shows a request for an exclusive write lock on a 966 collection and all its children. In this request, the client has 967 specified that it desires an infinite length lock, if available, 968 otherwise a timeout of 4.1 billion seconds, if available. The 969 request entity body contains the contact information for the 970 principal taking out the lock, in this case a web page URL. 972 The error is a 403 (Forbidden) response on the resource 973 http://example.com/webdav/secret. Because this resource could not be 974 locked, none of the resources were locked. 976 5.2 Refreshing Locks 978 A LOCK request with no request body is a "LOCK refresh" request. 979 It's purpose is to restart all timers associated with a lock. 981 If an error is received in response to a refresh LOCK request the 982 client SHOULD assume that the lock was not refreshed. [[anchor33: 983 This fact is so obvious that it should be removed. --reschke]] 985 5.2.1 Marshalling 987 The request MUST include an "If" header that contains the lock tokens 988 of the locks to be refreshed (note there may be multiple in the case 989 of shared locks). 991 The request MAY include a "Timeout" header to be used as the new 992 timeout value for the lock(s) to be refreshed (see Section 9.2). 994 The request MAY include a "Depth" header specifying either "0" or 995 "infinity" (see [RFC2518], section 9.2) which MUST be ignored when 996 present. 998 The response to a successful lock refresh request MUST contain the 999 value of the current DAV:lockdiscovery property in a prop XML 1000 element. 1002 5.2.2 Preconditions 1004 5.2.2.1 DAV:lock-submission-allowed precondition 1006 See Section 8.2.1. 1008 5.2.3 Postconditions 1010 5.2.3.1 DAV:locks-refreshed postcondition 1012 Timers associated with the those locks submitted in the "If" request 1013 header whose lock root is the resource identified by the Request-URI 1014 MUST be reset to their original value (or alternatively to the new 1015 value given in the "Timeout" request header). 1017 5.2.4 Example - Refreshing a Write Lock 1019 >>Request 1021 LOCK /workspace/webdav/proposal.doc HTTP/1.1 1022 Host: example.com 1023 Timeout: Infinite, Second-4100000000 1024 If: () 1025 Authorization: Digest username="ejw", 1026 realm="ejw@example.com", nonce="...", 1027 uri="/workspace/webdav/proposal.doc", 1028 response="...", opaque="..." 1030 >>Response 1032 HTTP/1.1 200 OK 1033 Content-Type: text/xml; charset="utf-8" 1034 Content-Length: xxxx 1036 1037 1038 1039 1040 1041 1042 Infinity 1043 1044 http://example.org/~ejw/contact.html 1046 1047 Second-604800 1048 1049 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 1051 1052 1053 http://example.com/workspace/webdav/proposal.doc 1055 1056 1057 1058 1060 This request would refresh the lock, resetting any time outs. Notice 1061 that the client asked for an infinite time out but the server choose 1062 to ignore the request. 1064 6. UNLOCK Method 1066 The UNLOCK method removes the lock identified by the lock token in 1067 the Lock-Token request header from the resource identified by the 1068 Request-URI, and all other resources included in the lock. Note that 1069 the UNLOCK request may be submitted to any resource locked by that 1070 lock (even those that are locked indirectly). 1072 If all resources which have been locked under the submitted lock 1073 token can not be unlocked then the UNLOCK request MUST fail. 1075 Any DAV compliant resource which supports the LOCK method MUST 1076 support the UNLOCK method. 1078 A server MAY allow principals other than a lock owner to unlock a 1079 resource. In this case, this capability SHOULD be under access 1080 control (see [RFC3744], section 3.5). Note that there is a tradeoff 1081 in allowing non-owners of a lock to unlock a resource. It can be 1082 beneficial to allow non-lock owners to perform UNLOCK requests 1083 because it allows the adminstrator of the server to configure the 1084 server to grant longer lock timeouts because the administrator knows 1085 that there is a process in place to allow users to deal with 1086 forgotten locks left by other users. On the other hand, a 1087 disadvantage of unlocking someone else's lock is that can create a 1088 situation where two users are working on modifications to the same 1089 resource at the same time which can result in a client having to 1090 perform an merge that wasn't previously planned. 1092 6.1 Marshalling 1094 The request MUST include a "Lock-Token" header (see Section 9.1) that 1095 identifies the lock to be removed. 1097 [[anchor41: Specify optional request body? --reschke]] 1099 6.2 Preconditions 1101 6.2.1 DAV:lock-token-matches precondition 1103 The lock identified by the "Lock-Token" request header exists, and 1104 the resource identified by the Request-URI indeed is directly locked 1105 by the specified lock. 1107 6.2.2 DAV:lock-removal-allowed precondition 1109 As dicussed above, the principal authenticated for the UNLOCK request 1110 MUST be allowed to remove the identified lock (note that servers that 1111 support the "WebDAV Access Control Protocol" should use the DAV:need- 1112 privileges precondition defined in section 7.1.1 of [RFC3744]). 1114 6.3 Postconditions 1116 6.3.1 DAV:lock-removed postcondition 1118 The lock MUST have been removed from all resources included in the 1119 lock. 1121 6.4 Example - UNLOCK 1123 >>Request 1125 UNLOCK /workspace/webdav/info.doc HTTP/1.1 1126 Host: example.com 1127 Lock-Token: 1128 Authorization: Digest username="ejw", 1129 realm="ejw@example.com", nonce="...", 1130 uri="/workspace/webdav/proposal.doc", 1131 response="...", opaque="..." 1133 >>Response 1135 HTTP/1.1 204 No Content 1137 In this example, the lock identified by the lock token 1138 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 1139 successfully removed from the resource 1140 http://example.com/workspace/webdav/info.doc. If this lock included 1141 more than just one resource, the lock is removed from all resources 1142 included in the lock. Note that clients MUST interpret any of the 1143 success status codes defined in [RFC2616], section 10.2 as success 1144 codes. 204 (No Content) was used here merely for consistency with the 1145 example in [RFC2518], section 8.11.1). 1147 7. Additional status codes 1149 7.1 423 Locked 1151 The 423 (Locked) status code means the source or destination resource 1152 of a method is locked. 1154 8. Additional marshalling and method semantics for other methods 1156 8.1 Additional marshalling 1158 This section defines additional condition names (see Section 1.2) 1159 that apply to all methods. 1161 8.1.1 DAV:name-allowed precondition 1163 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1164 create a new internal member URI inside a collection resource, the 1165 last path segment of that URI must specify a name that is available 1166 as a resource name (for instance, servers may disallow path segments 1167 that -- after being URI-unescaped -- aren't valid UTF-8 octet 1168 sequences). [[anchor51: Copied from 1169 draft-ietf-webdav-redirectref-protocol. --reschke]] 1171 8.1.2 DAV:parent-resource-must-be-non-null precondition 1173 If a request such as COPY, LOCK, MOVE, PUT or MKCOL is going to 1174 create a new internal member URI inside a collection resource, that 1175 collection resource must be non-null. [[anchor53: Copied from 1176 draft-ietf-webdav-redirectref-protocol. --reschke]] 1178 8.2 Additional method semantics 1180 This section defines names (see Section 1.2) for new conditions 1181 introduced by locking semantics. Otherwise noted otherwise, they 1182 apply to all methods. 1184 8.2.1 DAV:lock-token-submission-allowed precondition 1186 If the server restricts usage of the lock token inside an "If" 1187 request header to specific principals, the authenticated principal 1188 for this request MUST be one of them. 1190 8.2.2 DAV:need-lock-token precondition 1192 If a request would modify the content for a locked resource, a dead 1193 property of a locked resource, a live property that is defined to be 1194 lockable for a locked resource, or an internal member URI of a locked 1195 collection, the request MUST fail unless the lock-token for that lock 1196 is submitted in the request. An internal member URI of a collection 1197 is considered to be modified if it is added, removed, or identifies a 1198 different resource. [[anchor56: Copied from GULP. --reschke]] 1200 1202 Servers SHOULD insert DAV:href elements for the URLs of each root of 1203 a lock for which a lock token was needed, unless that URL identies 1204 the same resource to that the request was sent. 1206 8.2.2.1 Example 1208 In the example below, a client unaware of a "Depth: infinity" lock on 1209 the parent collection "/workspace/webdav/" attempts to modify the 1210 collection member "/workspace/webdav/proposal.doc". 1212 >>Request 1214 PUT /workspace/webdav/proposal.doc HTTP/1.1 1215 Host: example.com 1217 >>Response 1219 HTTP/1.1 423 Locked 1220 Content-Type: text/xml; charset="utf-8" 1221 Content-Length: xxxx 1223 1224 1225 1226 /workspace/webdav/ 1227 1228 1230 9. Headers 1232 9.1 Lock-Token request/response header 1234 Lock-Token = "Lock-Token" ":" Coded-URL 1235 ; Coded-URL: see [RFC2518], Section 9.4. 1237 The Lock-Token request header is used with the UNLOCK method to 1238 identify the lock to be removed. The lock token in the Lock-Token 1239 request header MUST identify a lock that contains the resource 1240 identified by Request-URI as a member. 1242 The Lock-Token response header is used with the LOCK method to 1243 indicate the lock token created as a result of a successful LOCK 1244 request to create a new lock. 1246 Note that the "Lock-Token" request header does not contribute to the 1247 precondition checks defined for the HTTP status 412 (see [RFC2616], 1248 section 10.4.13). 1250 9.2 Timeout request header 1251 TimeOut = "Timeout" ":" 1#TimeType 1252 TimeType = (TimeTypeSec | "Infinite" | Other) 1253 TypeTypeSec = "Second-" 1*digit 1254 Other = "Extend" field-value 1255 ; field-value: see [RFC2616], Section 4.2 1257 (Linear white space (LWS) MUST NOT be used inside "TimeTypeSec".) 1259 Clients MUST NOT submit a Timeout request header with any method 1260 other than a LOCK method. 1262 A Timeout request header MUST contain at least one TimeType and may 1263 contain multiple TimeType entries. The purpose of listing multiple 1264 TimeType entries is to indicate multiple different values and value 1265 types that are acceptable to the client. The client lists the 1266 TimeType entries in order of preference. 1268 Timeout response values MUST use a Second value, Infinite, or a 1269 TimeType the client has indicated familiarity with. The server may 1270 assume a client is familiar with any TimeType submitted in a Timeout 1271 header. 1273 The "Second" TimeType specifies the number of seconds that will 1274 elapse between granting of the lock at the server, and the automatic 1275 removal of the lock. The timeout value for TimeType "Second" MUST 1276 NOT be greater than 2^32-1. 1278 10. Capability discovery 1280 10.1 OPTIONS method 1282 If the server supports locking, it MUST return both the compliance 1283 class names "2" and "locking" as fields in the "DAV" response header 1284 (see [RFC2518], section 9.1) from an OPTIONS request on any resource 1285 implemented by that server. A value of "2" or "locking" in the "DAV" 1286 response header MUST indicate that the server meets all class "1" 1287 requirements defined in [RFC2518] and supports all MUST level 1288 requirements and REQUIRED features specified in this document, 1289 including: 1291 o LOCK and UNLOCK methods, 1293 o DAV:lockdiscovery and DAV:supportedlock properties, 1295 o "Time-Out" request header, "Lock-Token" request and response 1296 header. 1298 Note that for servers implementing this specification, the compliance 1299 classes "2" and "locking" are synonymous. However, new clients can 1300 take advantage of the new "locking" compliance class to detect server 1301 support for changes introduced by this specification (see 1302 Appendix A). 1304 11. Security considerations 1306 All security considerations mentioned in [RFC2518] also apply to this 1307 document. Additionally, lock tokens introduce new privacy issues 1308 discussed below. 1310 11.1 Privacy Issues Connected to Locks 1312 When submitting a lock request a user agent may also submit an owner 1313 XML field giving contact information for the person taking out the 1314 lock (for those cases where a person, rather than a robot, is taking 1315 out the lock). This contact information is stored in a DAV: 1316 lockdiscovery property on the resource, and can be used by other 1317 collaborators to begin negotiation over access to the resource. 1318 However, in many cases this contact information can be very private, 1319 and should not be widely disseminated. Servers SHOULD limit read 1320 access to the DAV:lockdiscovery property as appropriate. 1321 Furthermore, user agents SHOULD provide control over whether contact 1322 information is sent at all, and if contact information is sent, 1323 control over exactly what information is sent. 1325 12. Internationalization Considerations 1327 All internationalization considerations mentioned in [RFC2518] also 1328 apply to this document. 1330 13. IANA Considerations 1332 This specification updates the definition of the "opaquelocktoken" 1333 URI scheme described in Appendix D, registered my means of [RFC2518], 1334 section 6.4. There are no additional IANA considerations. 1336 14. Acknowledgements 1338 This document is the collaborative product of 1340 o the authors, 1342 o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault 1343 - and 1345 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron 1346 Goland, Del Jensen and Jim Whitehead. 1348 This document has also benefited from thoughtful discussion by Mark 1349 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, 1350 Rickard Falk, Eric Glass, Stanley Guan, Larry Masinter, Joe Orton, 1351 Juergen Pill, Elias Sinderson, Greg Stein, Kevin Wiggen, and other 1352 members of the WebDAV working group. 1354 15. References 1356 15.1 Normative References 1358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1359 Requirement Levels", BCP 14, RFC 2119, March 1997. 1361 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1362 Jensen, "HTTP Extensions for Distributed Authoring -- 1363 WEBDAV", RFC 2518, February 1999. 1365 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1366 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1367 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1369 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1370 Resource Identifier (URI): Generic Syntax", STD 66, 1371 RFC 3986, January 2005. 1373 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1374 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1375 Edition)", W3C REC-xml-20040204, February 2004, 1376 . 1378 [draft-mealling-uuid-urn] 1379 Leach, P., Mealling, M., and R. Salz, "A UUID URN 1380 Namespace", draft-mealling-uuid-urn-05 (work in progress), 1381 January 2005, . 1384 15.2 Informative References 1386 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1387 Distributed Authoring and Versioning (WebDAV) Access 1388 Control Protocol", RFC 3744, May 2004. 1390 Author's Address 1392 Julian F. Reschke 1393 greenbytes GmbH 1394 Salzmannstrasse 152 1395 Muenster, NW 48159 1396 Germany 1398 Phone: +49 251 2807760 1399 Fax: +49 251 2807761 1400 Email: julian.reschke@greenbytes.de 1401 URI: http://greenbytes.de/tech/webdav/ 1403 Appendix A. Changes to RFC2518 1405 See Section 10 for a description about how clients can discover 1406 support for this version of the WebDAV Locking protocol. 1408 A.1 Removed/Deprecated features 1410 A.1.1 Implicit lock refresh 1412 In section 9.8, [RFC2518] specifies that locks should be refreshed 1413 implicitly every time "...any time an owner of the lock sends a 1414 method to any member of the lock, including unsupported methods, or 1415 methods which are unsuccessful." This features has been removed 1416 (locks need to be refreshed explicitly using the LOCK method). 1418 Compatibility consideration: clients historically have never relied 1419 on this feature as it was never implemented in widely deployed WebDAV 1420 servers. 1422 A.1.2 Lock-null resources 1424 In section 7.4, [RFC2518] specifies a special resource type called 1425 "lock-null resource" that's being created when a LOCK method request 1426 is applied to a null resource. In practice, no real interoperability 1427 was achieved because many servers failed to implement this feature 1428 properly and few clients (if any) ever relied on that particular 1429 functionality. 1431 Removing this feature also means that there is no atomic way to 1432 create a collection in locked state, but in practice, this doesn't 1433 seem to be a problem. 1435 Compatibility consideration: there do not seem to be any widely 1436 deployed clients that actually relied on "lock-null resources". 1438 A.2 Additional features 1440 A.2.1 DAV:lockroot element in DAV:activelock 1442 Clients can take advantage of the new DAV:lockroot element to 1443 discover the URL to which the LOCK request (that created the lock) 1444 was applied. 1446 Compatibility consideration: clients will have to fail gracefully 1447 when communicating with older servers that do not support the new 1448 element. 1450 A.2.2 Error Marshalling 1452 Clients can take advantage of additional, detailed error information 1453 using the DAV:error element defined in Section 1.2. 1455 Compatibility consideration: old clients should not even notice the 1456 additional informations. New clients SHOULD handle absence of 1457 additional error information gracefully. 1459 Appendix B. Text to be integrated from RFC2518 1461 B.1 HTTP Methods for Distributed Authoring 1463 B.1.1 LOCK Method 1465 B.1.1.1 Locking Replicated Resources 1467 A resource may be made available through more than one URI. However 1468 locks apply to resources, not URIs. Therefore a LOCK request on a 1469 resource MUST NOT succeed if can not be honored by all the URIs 1470 through which the resource is addressable. 1472 B.1.1.2 Depth and Locking 1474 A Depth header of value 0 means to just lock the resource specified 1475 by the Request-URI. 1477 If the Depth header is set to infinity then the resource specified in 1478 the Request-URI along with all its internal members, all the way down 1479 the hierarchy, are to be locked. A successful result MUST return a 1480 single lock token which represents all the resources that have been 1481 locked. If an UNLOCK is successfully executed on this token, all 1482 associated resources are unlocked. If the lock cannot be granted to 1483 all resources, a 207 (Multistatus) status code MUST be returned with 1484 a response entity body containing a multistatus XML element 1485 describing which resource(s) prevented the lock from being granted. 1487 Hence, partial success is not an option. Either the entire hierarchy 1488 is locked or no resources are locked. 1490 B.1.1.3 Interaction with other Methods 1492 The interaction of a LOCK with various methods is dependent upon the 1493 lock type. However, independent of lock type, a successful DELETE of 1494 a resource MUST cause all of its locks to be removed. 1496 B.2 HTTP Headers for Distributed Authoring 1498 B.2.1 If Header 1500 [[anchor73: Add "If" header considerations: --reschke]] 1502 Appendix C. GULP 1504 _Copied from _. 1507 C.1 Directly vs Indirectly 1509 A lock either directly or indirectly locks a resource. 1511 C.2 Creating Locks 1513 A LOCK request with a non-empty body creates a new lock, and the 1514 resource identified by the Request-URI is directly locked by that 1515 lock. The "lock-root" of the new lock is the Request-URI. If at the 1516 time of the request, the Request-URI is not mapped to a resource, a 1517 new resource with empty content MUST be created by the request. 1519 C.3 Lock Inheritance 1521 If a collection is directly locked by a depth:infinity lock, all 1522 members of that collection (other than the collection itself) are 1523 indirectly locked by that lock. In particular, if an internal member 1524 resource is added to a collection that is locked by a depth:infinity 1525 lock, and if the resource is not locked by that lock, then the 1526 resource becomes indirectly locked by that lock. Conversely, if a 1527 resource is indirectly locked with a depth:infinity lock, and if the 1528 result of deleting an internal member URI is that the resource is no 1529 longer a member of the collection that is directly locked by that 1530 lock, then the resource is no longer locked by that lock. 1532 C.4 Removing Locks 1534 An UNLOCK request deletes the lock with the specified lock token. 1536 The Request-URI of the request MUST identify a resource that is 1537 either directly or indirectly locked by that lock. After a lock is 1538 deleted, no resource is locked by that lock. 1540 C.5 Submitting Lock Tokens 1542 A lock token is "submitted" in a request when it appears in an "If" 1543 request header. 1545 C.6 Locked State 1547 If a request would modify the content for a locked resource, a dead 1548 property of a locked resource, a live property that is defined to be 1549 lockable for a locked resource, or an internal member URI of a locked 1550 collection, the request MUST fail unless the lock-token for that lock 1551 is submitted in the request. An internal member URI of a collection 1552 is considered to be modified if it is added, removed, or identifies a 1553 different resource. 1555 C.7 URL protection 1557 If a request causes a directly locked resource to no longer be mapped 1558 to the lock-root of that lock, then the request MUST fail unless the 1559 lock-token for that lock is submitted in the request. If the request 1560 succeeds, then that lock MUST have been deleted by that request. 1562 C.8 Exclusive vs Shared 1564 If a request would cause a resource to be locked by two different 1565 exclusive locks, the request MUST fail. 1567 Appendix D. 'opaquelocktoken' URI Scheme 1569 The opaquelocktoken URI scheme is designed to be unique across all 1570 resources for all time. Due to this uniqueness quality, a client may 1571 submit an opaque lock token in an If header on a resource other than 1572 the one that returned it. 1574 All resources MUST recognize the opaquelocktoken scheme and, at 1575 minimum, recognize that the lock token does not refer to an 1576 outstanding lock on the resource. 1578 In order to guarantee uniqueness across all resources for all time 1579 the opaquelocktoken requires the use of the Universal Unique 1580 Identifier (UUID) mechanism, as described in Section 4 of 1581 [draft-mealling-uuid-urn]. 1583 OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] 1584 ; UUID: see [draft-mealling-uuid-urn], Section 3. 1585 ; path: see [RFC3986], Section 3.3. 1587 Appendix E. Change Log (to be removed by RFC Editor before publication) 1589 E.1 Since draft-reschke-webdav-locking-00 1591 Add and resolve issue "rfc2606-compliance". Resolve issues "extract- 1592 locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL", 1593 "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS", 1594 "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02", 1595 "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL", 1596 "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION", 1597 "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC", 1598 "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK", 1599 "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS", 1600 "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and 1601 "111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work 1602 on moving text from RFC2518 excerpts into new sections. Define new 1603 compliance class "locking" (similar to "bis" in RFC2518bis, but only 1604 relevant to locking). Reformatted "GULP" into separate subsections 1605 for easier reference. 1607 E.2 Since draft-reschke-webdav-locking-01 1609 Update "008_URI_URL", "040_LOCK_ISSUES_06", 1610 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY", 1611 "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN". Re- 1612 opened "065_UNLOCK_WHAT_URL". Close 1613 "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK 1614 refresh method descriptions. Fix page title (TXT version). Close 1615 "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH", 1616 "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and 1617 resolve "8.10.1_lockdiscovery_on_failure". Started attempt to 1618 clarify status code. 1620 E.3 Since draft-reschke-webdav-locking-02 1622 Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04", 1623 "040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS", 1624 "067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN". 1625 Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version 1626 (5.7). Add and resolve new issue "7.5_DELETE_vs_URIs". Start work 1627 on "additional marshalling" and "introduction". Update issues 1628 "044_REPORT_OTHER_RESOURCE_LOCKED" and 1629 "066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL". 1631 E.4 Since draft-reschke-webdav-locking-03 1633 Close issues "import-rfc3253-stuff", "008_URI_URL", 1634 "015_MOVE_SECTION_6.4.1_TO_APPX", "044_REPORT_OTHER_RESOURCE_LOCKED", 1635 "056_DEPTH_LOCK_AND_IF" and "072_LOCK_URL_WITH_NO_PARENT_COLLECTION". 1636 Reformat condition name descriptions. Add mention of condition 1637 failure signalling to "Changes" appendix. Start edit of header 1638 descriptions (Depth, Timeout) and LOCK creation description. Open 1639 and close issue "3.2_lockdiscovery_depth". Start work on intro. 1641 E.5 Since draft-reschke-webdav-locking-04 1643 Add description of the lock as a resource and it's state (merging in 1644 Timeout semantics from old headers section). Close issues 1645 "040_LOCK_ISSUES_06", 1646 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY" and 1647 "088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED". Move edited version of 1648 "Write Lock" chapter. 1650 E.6 Since draft-reschke-webdav-locking-05 1652 Add and close issues "rfc2396bis" and "5.2.1- 1653 depth_header_vs_lock_refresh". Fixed DAV:lockdiscovery example. 1655 E.7 Since draft-reschke-webdav-locking-06 1657 Add and resolve issues "uri_draft_ref", "abnf", 1658 "D_delegate_UUID_definition" and "lock_state_auth_principal". 1660 Appendix F. Resolved issues (to be removed by RFC Editor before 1661 publication) 1663 Issues that were either rejected or resolved in this version of this 1664 document. 1666 F.1 lock_state_auth_principal 1668 Type: change 1670 julian.reschke@greenbytes.de (2005-02-13): Mention the principal that 1671 was authenticated when the lock was created as part of the state of a 1672 lock; disambiguate with what previously was called "lock owner". 1674 Resolution (2005-02-13): Done. 1676 F.2 abnf 1678 Type: change 1679 julian.reschke@greenbytes.de (2005-02-12): Clarify BNF syntax 1680 (Notation, and when used). 1682 Resolution (2005-02-13): Done. 1684 F.3 uri_draft_ref 1686 Type: edit 1688 julian.reschke@greenbytes.de (2005-01-01): Fix reference to 1689 draft-fielding-uri-rfc2396bis-07. 1691 Resolution (2005-01-25): Update to RFC3986. 1693 F.4 D_delegate_UUID_definition 1695 Type: change 1697 julian.reschke@greenbytes.de (2005-01-30): Delegate the definition of 1698 UUIDs to draft-mealling-uuid-urn. 1700 Resolution (2005-02-06): Done. See also http://lists.w3.org/ 1701 Archives/Public/w3c-dist-auth/2005JanMar/0187.html. 1703 Appendix G. Open issues (to be removed by RFC Editor prior to 1704 publication) 1706 G.1 import-gulp 1708 Type: change 1710 julian.reschke@greenbytes.de (2004-05-25): Make specification text 1711 compatible with GULP where it isn't. Integrate GULP as normative 1712 specification of the locking behaviour. 1714 G.2 edit 1716 Type: edit 1718 julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for 1719 editorial fixes/enhancements. 1721 G.3 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION 1723 Type: change 1725 1727 ccjason@us.ibm.com (): What resource should be flagged in the 1728 multistatus response to locking issues in COPY/MOVE requests? 1730 Resolution: Resolved to flag the locking errors at the source 1731 resource that was affected by the problem. The details of how to 1732 describe the error was deferred to a subsequent version of WebDAV. - 1733 6/15/02 - 2518bis does not reflect this. 1735 G.4 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION 1737 Type: change 1739 1742 (): The method of describing the details of (beyond what resolved by 1743 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of 1744 various locking and ACL COPY/MOVE problems is deferred. Two 1745 proposals were outlined in the discussion, but interest was not great 1746 and we clearly don't have interoperability to take these proposals 1747 forward. 1749 G.5 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL 1751 Type: change 1753 (): Right now the server uses the IF: header to verify that a client 1754 knows what locks it has that are affected by an operation before it 1755 allows the operation. Must the client provide the root URL of a 1756 lock, any URL for a pertainent loc, or some specific URL in the IF: 1757 header. 1759 ccjason@us.ibm.com (): It is felt by the group that it's important 1760 that the client not just own and hold the lock token, but that it 1761 also know where the lock is rooted before it does tasks related to 1762 that lock. This is just a point of info. The issue itself still 1763 needs to be brought up and answered.still 1765 julian.reschke@greenbytes.de (): Summary: current implementations do 1766 not seem to care (see http://lists.w3.org/Archives/Public/ 1767 w3c-dist-auth/2004AprJun/0190.html). Suggestion to require clients 1768 to specify the lock root anyway, because this is what the WG agreed 1769 upon earlier. 1771 Index 1773 4 1774 423 Locked (status code) 27 1776 C 1777 Condition Names 1778 DAV:create-lock (post) 20 1779 DAV:create-resource (post) 20 1780 DAV:lock-removal-allowed (pre) 26 1781 DAV:lock-removed (post) 27 1782 DAV:lock-submission-allowed (pre) 24 1783 DAV:lock-token-matches (pre) 26 1784 DAV:lock-token-submission-allowed (pre) 28 1785 DAV:locks-refreshed (post) 24 1786 DAV:name-allowed (pre) 28 1787 DAV:need-lock-token (pre) 28 1788 DAV:parent-resource-must-be-non-null (pre) 28 1790 D 1791 DAV header 1792 compliance class '2' 30 1793 compliance class 'locking' 30 1794 DAV:create-lock postcondition 20 1795 DAV:create-resource postcondition 20 1796 DAV:lock-removal-allowed precondition 26 1797 DAV:lock-removed postcondition 27 1798 DAV:lock-submission-allowed precondition 24 1799 DAV:lock-token-matches precondition 26 1800 DAV:lock-token-submission-allowed precondition 28 1801 DAV:lockdiscovery property 16 1802 DAV:locks-refreshed postcondition 24 1803 DAV:name-allowed precondition 28 1804 DAV:need-lock-token precondition 28 1805 DAV:parent-resource-must-be-non-null precondition 28 1806 DAV:supportedlock property 18 1808 H 1809 Headers 1810 Lock-Token 29 1811 Timeout 29 1813 L 1814 LOCK method 19 1815 lock creation 19 1816 lock refresh 24 1817 Lock-Token header 29 1819 M 1820 Methods 1821 LOCK (lock creation) 19 1822 LOCK (lock refresh) 24 1823 LOCK 19 1824 UNLOCK 26 1826 O 1827 opaquelocktoken (URI scheme) 36 1829 P 1830 Properties 1831 DAV:lockdiscovery 16 1832 DAV:supportedlock 18 1834 S 1835 Status Codes 1836 423 Locked 27 1838 T 1839 Timeout header 29 1841 U 1842 UNLOCK method 26 1843 URI schemes 1844 opaquelocktoken 36 1846 Intellectual Property Statement 1848 The IETF takes no position regarding the validity or scope of any 1849 Intellectual Property Rights or other rights that might be claimed to 1850 pertain to the implementation or use of the technology described in 1851 this document or the extent to which any license under such rights 1852 might or might not be available; nor does it represent that it has 1853 made any independent effort to identify any such rights. Information 1854 on the procedures with respect to rights in RFC documents can be 1855 found in BCP 78 and BCP 79. 1857 Copies of IPR disclosures made to the IETF Secretariat and any 1858 assurances of licenses to be made available, or the result of an 1859 attempt made to obtain a general license or permission for the use of 1860 such proprietary rights by implementers or users of this 1861 specification can be obtained from the IETF on-line IPR repository at 1862 http://www.ietf.org/ipr. 1864 The IETF invites any interested party to bring to its attention any 1865 copyrights, patents or patent applications, or other proprietary 1866 rights that may cover technology that may be required to implement 1867 this standard. Please address the information to the IETF at 1868 ietf-ipr@ietf.org. 1870 Disclaimer of Validity 1872 This document and the information contained herein are provided on an 1873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1875 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1876 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1877 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1880 Copyright Statement 1882 Copyright (C) The Internet Society (2005). This document is subject 1883 to the rights, licenses and restrictions contained in BCP 78, and 1884 except as set forth therein, the authors retain all their rights. 1886 Acknowledgment 1888 Funding for the RFC Editor function is currently provided by the 1889 Internet Society.