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