Network Working Group J. Reschke
Internet-Draft greenbytes
Updates: 2518 (if approved) June 18, 2004
Expires: December 17, 2004
Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
draft-reschke-webdav-locking-03
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies a set of methods and headers ancillary to
HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
RFC2518) for the management of resource locking (collision
avoidance). It updates those sections from RFC2518 that specify
WebDAV's locking features.
Editorial Note
[[anchor1: Note that this document is not a product of the WebDAV
Reschke Expires December 17, 2004 [Page 1]
Internet-Draft WebDAV Locking Protocol June 2004
working group. It is just an experiment to study the feasability of
extracing the locking feature into a separate specification.
--reschke]]
Distribution of this document is unlimited. Please send comments to
the WebDAV working group at w3c-dist-auth@w3.org [1], which may be
joined by sending a message with subject "subscribe" to
w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: .
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Method Preconditions and Postconditions . . . . . . . . . 5
2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 6
3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Common XML elements used in property values . . . . . . . 6
3.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 6
3.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 6
3.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 7
3.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 8
3.3.1 Examples for the DAV:supportedlock property . . . . . 9
4. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Example - Simple Lock Request . . . . . . . . . . . . 10
4.1.2 Example - Multi-Resource Lock Request . . . . . . . . 12
4.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Example - Refreshing a Write Lock . . . . . . . . . . 14
5. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Example - UNLOCK . . . . . . . . . . . . . . . . . . . . . 16
6. Additional status codes . . . . . . . . . . . . . . . . . . . 16
6.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Additional marshalling and method semantics for other
methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Additional marshalling . . . . . . . . . . . . . . . . . . 16
7.2 Additional method semantics . . . . . . . . . . . . . . . 17
8. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 Lock-Token request/response header . . . . . . . . . . . . 17
9. Capability discovery . . . . . . . . . . . . . . . . . . . . . 17
9.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 17
10. Security considerations . . . . . . . . . . . . . . . . . . 18
10.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 18
11. Internationalization Considerations . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Reschke Expires December 17, 2004 [Page 2]
Internet-Draft WebDAV Locking Protocol June 2004
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
14.2 Informative References . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 20
A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 20
A.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 20
A.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 21
A.2 Additional features . . . . . . . . . . . . . . . . . . . 21
A.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 21
B. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 21
B.1 Locking . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.1.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . 22
B.1.2 Required Support . . . . . . . . . . . . . . . . . . . 23
B.1.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . 23
B.1.4 Lock Capability Discovery . . . . . . . . . . . . . . 23
B.1.5 Active Lock Discovery . . . . . . . . . . . . . . . . 24
B.1.6 Usage Considerations . . . . . . . . . . . . . . . . . 24
B.2 Write Lock . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2.1 Methods Restricted by Write Locks . . . . . . . . . . 25
B.2.2 Write Locks and Lock Tokens . . . . . . . . . . . . . 25
B.2.3 Write Locks and Properties . . . . . . . . . . . . . . 26
B.2.4 Write Locks and Collections . . . . . . . . . . . . . 26
B.2.5 Write Locks and the If Request Header . . . . . . . . 26
B.2.6 Write Locks and COPY/MOVE . . . . . . . . . . . . . . 27
B.2.7 Refreshing Write Locks . . . . . . . . . . . . . . . . 28
B.3 HTTP Methods for Distributed Authoring . . . . . . . . . . 28
B.3.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 28
B.4 HTTP Headers for Distributed Authoring . . . . . . . . . . 30
B.4.1 Depth Header . . . . . . . . . . . . . . . . . . . . . 30
B.4.2 If Header . . . . . . . . . . . . . . . . . . . . . . 31
B.4.3 Timeout Request Header . . . . . . . . . . . . . . . . 31
B.5 XML Element Definitions . . . . . . . . . . . . . . . . . 32
B.5.1 lockinfo XML Element . . . . . . . . . . . . . . . . . 32
C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
C.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 32
C.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 32
C.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 32
C.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 33
C.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 33
C.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 33
C.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 33
C.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 33
D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 33
D.1 Node Field Generation Without the IEEE 802 Address . . . . 34
E. Change Log (to be removed by RFC Editor before publication) . 36
E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 36
E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 36
Reschke Expires December 17, 2004 [Page 3]
Internet-Draft WebDAV Locking Protocol June 2004
E.3 Since draft-reschke-webdav-locking-02 . . . . . . . . . . 37
F. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 37
F.1 065_UNLOCK_WHAT_URL . . . . . . . . . . . . . . . . . . . 37
F.2 067_UNLOCK_NEEDS_IF_HEADER . . . . . . . . . . . . . . . . 38
F.3 068_UNLOCK_WITHOUT_GOOD_TOKEN . . . . . . . . . . . . . . 38
F.4 040_LOCK_ISSUES_08 . . . . . . . . . . . . . . . . . . . . 39
F.5 040_LOCK_ISSUES_03 . . . . . . . . . . . . . . . . . . . . 40
F.6 7.5_DELETE_vs_URIs . . . . . . . . . . . . . . . . . . . . 40
F.7 040_LOCK_ISSUES_04 . . . . . . . . . . . . . . . . . . . . 40
F.8 053_LOCK_INHERITANCE . . . . . . . . . . . . . . . . . . . 41
F.9 057_LOCK_SEMANTICS . . . . . . . . . . . . . . . . . . . . 41
G. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 41
G.1 import-rfc3253-stuff . . . . . . . . . . . . . . . . . . . 42
G.2 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 42
G.3 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
G.4 008_URI_URL . . . . . . . . . . . . . . . . . . . . . . . 42
G.5 040_LOCK_ISSUES_06 . . . . . . . . . . . . . . . . . . . . 43
G.6 056_DEPTH_LOCK_AND_IF . . . . . . . . . . . . . . . . . . 43
G.7 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY . . . . . 44
G.8 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED . . . . . . . . . . 44
G.9 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 45
G.10 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 45
G.11 072_LOCK_URL_WITH_NO_PARENT_COLLECTION . . . . . . . . . . 45
G.12 044_REPORT_OTHER_RESOURCE_LOCKED . . . . . . . . . . . . . 46
G.13 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . . 46
G.14 015_MOVE_SECTION_6.4.1_TO_APPX . . . . . . . . . . . . . . 47
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . 50
Reschke Expires December 17, 2004 [Page 4]
Internet-Draft WebDAV Locking Protocol June 2004
1. Introduction
This document describes the "locking" extension to the Web
Distributed Authoring and Versioning (WebDAV) protocol that allows to
keep more than one person from working on a document at the same
time. This helps preventing the "lost update problem," in which
modifications are lost as first one author then another writes
changes without merging the other author's changes.
1.1 Terminology
The terminology used here follows and extends that in the WebDAV
Distributed Authoring Protocol specification [RFC2518].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses XML DTD fragments ([XML]) as a purely notational
convention. WebDAV request and response bodies cannot be validated
due to the specific extensibility rules defined in section 23 of
[RFC2518] and due to the fact that all XML elements defined by this
specification use the XML namespace name "DAV:". In particular:
o Element names use the "DAV:" namespace.
o Element ordering is irrelevant.
o Extension elements/attributes (elements/attributes not already
defined as valid child elements) may be added anywhere, except
when explicitly stated otherwise.
1.2 Method Preconditions and Postconditions
A "precondition" of a method describes the state on the server that
must be true for that method to be performed. A "postcondition" of a
method describes the state on the server that must be true after that
method has completed. If a method precondition or postcondition for
a request is not satisfied and unless a more specific HTTP status
code applies, the response status of the request MUST be either 403
(Forbidden) if the request should not be repeated because it will
always fail, or 409 (Conflict) if it is expected that the user might
be able to resolve the conflict and resubmit the request.
In order to allow better client handling of error responses, a
distinct XML element type is associated with each method precondition
and postcondition of a request. When a particular precondition is
Reschke Expires December 17, 2004 [Page 5]
Internet-Draft WebDAV Locking Protocol June 2004
not satisfied or a particular postcondition cannot be achieved, the
appropriate XML element MUST be returned as the child of a top-level
DAV:error element in the response body, unless otherwise negotiated
by the request. In a 207 Multi-Status response, the DAV:error
element would appear in the appropriate DAV:responsedescription
element.
2. Overview of Locking
3. Properties
The locking feature introduces the following properties for a
resource.
3.1 Common XML elements used in property values
3.1.1 Lock Scopes
3.1.2 Lock Types
At present, this specification only defines one lock type, the write
lock.
3.2 DAV:lockdiscovery property
The DAV:lockdiscovery property returns a listing of who has a lock,
what type of lock he has, the timeout type, the time remaining on the
timeout, the associated lock token and the root of the lock. The
server is free to withhold any or all of this information if the
requesting principal does not have sufficient access rights to see
the requested data.
Reschke Expires December 17, 2004 [Page 6]
Internet-Draft WebDAV Locking Protocol June 2004
depth: the value of the Depth header (see Appendix B.4.1; takes the
values "0", "1" or "infinity").
owner: provides information about the principal taking out a lock;
should be sufficient for either directly contacting a principal (such
as a telephone number or email URI), or for discovering the principal
(such as the URL of a homepage).
timeout: the timeout associated with a lock (defined in Appendix
B.4.3).
locktoken: the lock token associated with a lock; the href element
contains the lock token.
lockroot: the URL of the resource that was addressed in the LOCK
request; the href element contains the URL of the resource to which
the LOCK request has been applied.
href: defined in [RFC2518], section 12.3.
3.2.1 Examples for the DAV:lockdiscovery
Reschke Expires December 17, 2004 [Page 7]
Internet-Draft WebDAV Locking Protocol June 2004
DAV:lockdiscovery property for a resource that has two shared write
locks on it, with infinite timeouts:
0
Jane Smith
Infinite
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
http://example.com/container/
0
John Doe
Infinite
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77
http://example.com/container/
DAV:lockdiscovery property for a resource with no locks on it:
3.3 DAV:supportedlock property
The DAV:supportedlock property of a resource returns a listing of the
combinations of scope and access types which may be specified in a
lock request on the resource. Note that the actual contents are
Reschke Expires December 17, 2004 [Page 8]
Internet-Draft WebDAV Locking Protocol June 2004
themselves controlled by access controls so a server is not required
to provide information the client is not authorized to see.
3.3.1 Examples for the DAV:supportedlock property
DAV:supportedlock property for a resource that supports both
exclusive and shares write locks:
DAV:supportedlock property for a resource that doesn't support any
locks at all:
4. LOCK Method
The following sections describe the LOCK method, which is used to
take out a lock of any access type or to refresh an existing lock.
4.1 Creating Locks
[[anchor13: TODO: move method description from appendix --reschke]]
Reschke Expires December 17, 2004 [Page 9]
Internet-Draft WebDAV Locking Protocol June 2004
4.1.1 Example - Simple Lock Request
>>Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
http://example.org/~ejw/contact.html
Reschke Expires December 17, 2004 [Page 10]
Internet-Draft WebDAV Locking Protocol June 2004
>>Response
HTTP/1.1 200 OK
Lock-Token:
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Infinity
http://example.org/~ejw/contact.html
Second-604800
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
http://example.com/workspace/webdav/proposal.doc
This example shows the successful creation of an exclusive write lock
on resource http://example.com/workspace/webdav/proposal.doc. The
resource http:/example.org/~ejw/contact.html contains contact
information for the owner of the lock. The server has an
activity-based timeout policy in place on this resource, which causes
the lock to automatically be removed after 1 week (604800 seconds).
Reschke Expires December 17, 2004 [Page 11]
Internet-Draft WebDAV Locking Protocol June 2004
4.1.2 Example - Multi-Resource Lock Request
>>Request
LOCK /webdav/ HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
http://example.org/~ejw/contact.html
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
/webdav/secret
HTTP/1.1 403 Forbidden
/webdav/
HTTP/1.1 424 Failed Dependency
This example shows a request for an exclusive write lock on a
collection and all its children. In this request, the client has
specified that it desires an infinite length lock, if available,
otherwise a timeout of 4.1 billion seconds, if available. The
request entity body contains the contact information for the
principal taking out the lock, in this case a web page URL.
Reschke Expires December 17, 2004 [Page 12]
Internet-Draft WebDAV Locking Protocol June 2004
The error is a 403 (Forbidden) response on the resource
http://example.com/webdav/secret. Because this resource could not be
locked, none of the resources were locked.
4.2 Refreshing Locks
A LOCK request with no request body is a "LOCK refresh" request.
It's purpose is to restart all timers associated with a lock.
If an error is received in response to a refresh LOCK request the
client SHOULD assume that the lock was not refreshed.
Marshalling:
The request MUST include an "If" header that contains the lock
tokens of the locks to be refreshed (note there may be multiple in
the case of shared locks).
The request MAY include a new "Timeout" header to be used as the
new timeout value for the lock(s) to be refreshed.
The response to a successful lock refresh request MUST contain the
value of the current DAV:lockdiscovery property in a prop XML
element.
Preconditions:
(DAV:lock-submission-allowed): see Section 7.1.
Postconditions:
(DAV:locks-refreshed): Timers associated with the those locks
submitted in the "If" request header whose lock root is the
resource identified by the request URI MUST be reset to their
original value (or alternatively to the new value given in the
"Timeout" request header).
Reschke Expires December 17, 2004 [Page 13]
Internet-Draft WebDAV Locking Protocol June 2004
4.2.1 Example - Refreshing a Write Lock
>>Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
If: ()
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Infinity
http://example.org/~ejw/contact.html
Second-604800
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
http://example.com/workspace/webdav/proposal.doc
This request would refresh the lock, resetting any time outs. Notice
that the client asked for an infinite time out but the server choose
to ignore the request.
Reschke Expires December 17, 2004 [Page 14]
Internet-Draft WebDAV Locking Protocol June 2004
5. UNLOCK Method
The UNLOCK method removes the lock identified by the lock token in
the Lock-Token request header from the resource identified by the
Request-URI, and all other resources included in the lock. Note that
the UNLOCK request may be submitted to any resource locked by that
lock (even those that are locked indirectly).
If all resources which have been locked under the submitted lock
token can not be unlocked then the UNLOCK request MUST fail.
Any DAV compliant resource which supports the LOCK method MUST
support the UNLOCK method.
A server MAY allow principals other than a lock owner to unlock a
resource. In this case, this capability SHOULD be under access
control (see [RFC3744], section 3.5). Note that there is a tradeoff
in allowing non-owners of a lock to unlock a resource. It can be
beneficial to allow non-lock owners to perform UNLOCK requests
because it allows the adminstrator of the server to configure the
server to grant longer lock timeouts because the administrator knows
that there is a process in place to allow users to deal with
forgotten locks left by other users. On the other hand, a
disadvantage of unlocking someone else's lock is that can create a
situation where two users are working on modifications to the same
resource at the same time which can result in a client having to
perform an merge that wasn't previously planned.
Marshalling:
The request MUST include a "Lock-Token" header (see Section 8.1)
that identifies the lock to be removed.
[[anchor17: Specify optional request body? --reschke]]
Preconditions:
(DAV:lock-token-matches): The lock identified by the "Lock-Token"
request header exists, and the resource identified by the request
URI indeed is directly locked by the specified lock.
(DAV:lock-removal-allowed): As dicussed above, the principal
authenticated for the UNLOCK request MUST be allowed to remove the
identified lock (note that servers that support the "WebDAV Access
Control Protocol" should use the DAV:need-privileges precondition
defined in section 7.1.1 of [RFC3744]).
Postconditions:
Reschke Expires December 17, 2004 [Page 15]
Internet-Draft WebDAV Locking Protocol June 2004
(DAV:lock-removed): The lock MUST have been removed from all
resources included in the lock.
5.1 Example - UNLOCK
>>Request
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token:
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
HTTP/1.1 204 No Content
In this example, the lock identified by the lock token
"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
successfully removed from the resource
http://example.com/workspace/webdav/info.doc. If this lock included
more than just one resource, the lock is removed from all resources
included in the lock. The 204 (No Content) status code is used
instead of 200 (OK) because there is no response entity body.
6. Additional status codes
6.1 423 Locked
The 423 (Locked) status code means the source or destination resource
of a method is locked.
7. Additional marshalling and method semantics for other methods
7.1 Additional marshalling
This section defines additional condition names (see Section 1.2)
that apply to all methods.
Preconditions:
(DAV:lock-submission-allowed): If the server restricts usage of
the lock token inside an "If" request header to specific
principals, the authenticated principal for this request MUST be
one of them.
Reschke Expires December 17, 2004 [Page 16]
Internet-Draft WebDAV Locking Protocol June 2004
(DAV:name-allowed): If a request such as COPY, LOCK, MOVE, PUT or
MKCOL is going to create a new internal member URI inside a
collection resource, the last path segment of that URI must
specify a name that is available as a resource name (for instance,
servers may disallow path segments that -- after being
URI-unescaped -- aren't valid UTF-8 octet sequences). [[anchor21:
Copied from draft-ietf-webdav-redirectref-protocol. --reschke]]
(DAV:parent-resource-must-be-non-null): If a request such as COPY,
LOCK, MOVE, PUT or MKCOL is going to create a new internal member
URI inside a collection resource, that collection resource must be
non-null. [[anchor22: Copied from
draft-ietf-webdav-redirectref-protocol. --reschke]]
7.2 Additional method semantics
8. Headers
8.1 Lock-Token request/response header
Lock-Token = "Lock-Token" ":" Coded-URL
Note that the "Coded-URL" production is defined in [RFC2518], section
9.4.
The Lock-Token request header is used with the UNLOCK method to
identify the lock to be removed. The lock token in the Lock-Token
request header MUST identify a lock that contains the resource
identified by Request-URI as a member.
The Lock-Token response header is used with the LOCK method to
indicate the lock token created as a result of a successful LOCK
request to create a new lock.
Note that the "Lock-Token" request header does not contribute to the
precondition checks defined for the HTTP status 412 (see [RFC2616],
section 10.4.13).
9. Capability discovery
9.1 OPTIONS method
If the server supports locking, it MUST return both the compliance
class names "2" and "locking" as fields in the "DAV" response header
(see [RFC2518], section 9.1) from an OPTIONS request on any resource
implemented by that server. A value of "2" or "locking" in the "DAV"
Reschke Expires December 17, 2004 [Page 17]
Internet-Draft WebDAV Locking Protocol June 2004
response header MUST indicate that the server meets all class "1"
requirements defined in [RFC2518] and supports all MUST level
requirements and REQUIRED features specified in this document,
including:
o LOCK and UNLOCK methods,
o DAV:lockdiscovery and DAV:supportedlock properties,
o "Time-Out" request header, "Lock-Token" request and response
header.
Note that for servers implementing this specification, the compliance
classes "2" and "locking" are synonymous. However, new clients can
take advantage of the new "locking" compliance class to detect server
support for changes introduced by this specification (see Appendix
A).
10. Security considerations
All security considerations mentioned in [RFC2518] also apply to this
document. Additionally, lock tokens introduce new privacy issues
discussed below.
10.1 Privacy Issues Connected to Locks
When submitting a lock request a user agent may also submit an owner
XML field giving contact information for the person taking out the
lock (for those cases where a person, rather than a robot, is taking
out the lock). This contact information is stored in a
DAV:lockdiscovery property on the resource, and can be used by other
collaborators to begin negotiation over access to the resource.
However, in many cases this contact information can be very private,
and should not be widely disseminated. Servers SHOULD limit read
access to the DAV:lockdiscovery property as appropriate.
Furthermore, user agents SHOULD provide control over whether contact
information is sent at all, and if contact information is sent,
control over exactly what information is sent.
11. Internationalization Considerations
All internationalization considerations mentioned in [RFC2518] also
apply to this document.
12. IANA Considerations
This specification updates the definition of the "opaquelocktoken"
URI scheme described in Appendix D, registered my means of [RFC2518],
Reschke Expires December 17, 2004 [Page 18]
Internet-Draft WebDAV Locking Protocol June 2004
section 6.4. There are no additional IANA considerations.
13. Acknowledgements
This document is the collaborative product of
o the authors,
o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault
- and
o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron
Goland, Del Jensen and Jim Whitehead.
This document has also benefited from thoughtful discussion by Mark
Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing,
Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias
Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV
working group.
14. References
14.1 Normative References
[ISO-11578]
International Organization for Standardization, "ISO/IEC
11578:1996. Information technology - Open Systems
Interconnection - Remote Procedure Call (RPC)", 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC-xml-20040204, February 2004,
.
Reschke Expires December 17, 2004 [Page 19]
Internet-Draft WebDAV Locking Protocol June 2004
14.2 Informative References
[RFC3744] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access
Control Protocol", RFC 3744, May 2004.
URIs
[1]
[2]
Author's Address
Julian F. Reschke
greenbytes GmbH
Salzmannstrasse 152
Muenster, NW 48159
Germany
Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Appendix A. Changes to RFC2518
See Section 9 for a description about how clients can discover
support for this version of the WebDAV Locking protocol.
A.1 Removed/Deprecated features
A.1.1 Implicit lock refresh
In section 9.8, [RFC2518] specifies that locks should be refreshed
implicitly every time "...any time an owner of the lock sends a
method to any member of the lock, including unsupported methods, or
methods which are unsuccessful." This features has been removed
(locks need to be refreshed explicitly using the LOCK method).
Compatibility considerations
Clients historically have never relied on this feature as it was
never implemented in widely deployed WebDAV servers.
Reschke Expires December 17, 2004 [Page 20]
Internet-Draft WebDAV Locking Protocol June 2004
A.1.2 Lock-null resources
In section 7.4, [RFC2518] specifies a special resource type called
"lock-null resource" that's being created when a LOCK method request
is applied to a null resource. In practice, no real interoperability
was achieved because many servers failed to implement this feature
properly and few clients (if any) ever relied on that particular
functionality.
Removing this feature also means that there is no atomic way to
create a collection in locked state, but in practice, this doesn't
seem to be a problem.
Compatibility considerations
There do not seem to be any widely deployed clients that actually
relied on "lock-null resources".
A.2 Additional features
A.2.1 DAV:lockroot element in DAV:activelock
Clients can take advantage of the new DAV:lockroot element to
discover the URL to which the LOCK request (that created the lock)
was applied.
Compatibility consideration
Clients will have to fail gracefully when communicating with older
servers that do not support the new property.
Appendix B. Text to be integrated from RFC2518
B.1 Locking
The ability to lock a resource provides a mechanism for serializing
access to that resource. Using a lock, an authoring client can
provide a reasonable guarantee that another principal will not modify
a resource while it is being edited. In this way, a client can
prevent the "lost update" problem.
This specification allows locks to vary over two client-specified
parameters, the number of principals involved (exclusive vs. shared)
and the type of access to be granted. This document defines locking
for only one access type, write. However, the syntax is extensible,
and permits the eventual specification of locking for other access
Reschke Expires December 17, 2004 [Page 21]
Internet-Draft WebDAV Locking Protocol June 2004
types.
B.1.1 Exclusive Vs. Shared Locks
The most basic form of lock is an exclusive lock. This is a lock
where the access right in question is only granted to a single
principal. The need for this arbitration results from a desire to
avoid having to merge results.
However, there are times when the goal of a lock is not to exclude
others from exercising an access right but rather to provide a
mechanism for principals to indicate that they intend to exercise
their access rights. Shared locks are provided for this case. A
shared lock allows multiple principals to receive a lock. Hence any
principal with appropriate access can get the lock.
With shared locks there are two trust sets that affect a resource.
The first trust set is created by access permissions. Principals who
are trusted, for example, may have permission to write to the
resource. Among those who have access permission to write to the
resource, the set of principals who have taken out a shared lock also
must trust each other, creating a (typically) smaller trust set
within the access permission write set.
Starting with every possible principal on the Internet, in most
situations the vast majority of these principals will not have write
access to a given resource. Of the small number who do have write
access, some principals may decide to guarantee their edits are free
from overwrite conflicts by using exclusive write locks. Others may
decide they trust their collaborators will not overwrite their work
(the potential set of collaborators being the set of principals who
have write permission) and use a shared lock, which informs their
collaborators that a principal may be working on the resource.
The WebDAV extensions to HTTP do not need to provide all of the
communications paths necessary for principals to coordinate their
activities. When using shared locks, principals may use any out of
band communication channel to coordinate their work (e.g.,
face-to-face interaction, written notes, post-it notes on the screen,
telephone conversation, Email, etc.) The intent of a shared lock is
to let collaborators know who else may be working on a resource.
Shared locks are included because experience from web distributed
authoring systems has indicated that exclusive locks are often too
rigid. An exclusive lock is used to enforce a particular editing
process: take out an exclusive lock, read the resource, perform
edits, write the resource, release the lock. This editing process
has the problem that locks are not always properly released, for
Reschke Expires December 17, 2004 [Page 22]
Internet-Draft WebDAV Locking Protocol June 2004
example when a program crashes, or when a lock owner leaves without
unlocking a resource. While both timeouts and administrative action
can be used to remove an offending lock, neither mechanism may be
available when needed; the timeout may be long or the administrator
may not be available. With a shared lock, another user can at least
take out another shared lock and start modifying the resource.
B.1.2 Required Support
A WebDAV compliant server is not required to support locking in any
form. If the server does support locking it may choose to support
any combination of exclusive and shared locks for any access types.
The reason for this flexibility is that locking policy strikes to the
very heart of the resource management and versioning systems employed
by various storage repositories. These repositories require control
over what sort of locking will be made available. For example, some
repositories only support shared write locks while others only
provide support for exclusive write locks while yet others use no
locking at all. As each system is sufficiently different to merit
exclusion of certain locking features, this specification leaves
locking as the sole axis of negotiation within WebDAV.
B.1.3 Lock Tokens
A lock token is a type of state token, represented as a URI, which
identifies a particular lock. A lock token is returned by every
successful LOCK operation in the DAV:lockdiscovery property in the
response body, and can also be found through lock discovery on a
resource.
Lock token URIs MUST be unique across all resources for all time.
This uniqueness constraint allows lock tokens to be submitted across
resources and servers without fear of confusion.
This specification provides a lock token URI scheme called
"opaquelocktoken" that meets the uniqueness requirements. However
resources are free to return any URI scheme so long as it meets the
uniqueness requirements.
Submitting a lock token provides no special access rights. Anyone
can find out anyone else's lock token by performing lock discovery.
Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values.
B.1.4 Lock Capability Discovery
Since server lock support is optional, a client trying to lock a
Reschke Expires December 17, 2004 [Page 23]
Internet-Draft WebDAV Locking Protocol June 2004
resource on a server can either try the lock and hope for the best,
or perform some form of discovery to determine what lock capabilities
the server supports. This is known as lock capability discovery.
Lock capability discovery differs from discovery of supported access
control types, since there may be access control types without
corresponding lock types. A client can determine what lock types the
server supports by retrieving the DAV:supportedlock property.
Any DAV compliant resource that supports the LOCK method MUST support
the DAV:supportedlock property.
B.1.5 Active Lock Discovery
If another principal locks a resource that a principal wishes to
access, it is useful for the second principal to be able to find out
who the first principal is. For this purpose the DAV:lockdiscovery
property is provided. This property lists all outstanding locks,
describes their type, and where available, provides their lock token.
Any DAV compliant resource that supports the LOCK method MUST support
the DAV:lockdiscovery property.
B.1.6 Usage Considerations
Although the locking mechanisms specified here provide some help in
preventing lost updates, they cannot guarantee that updates will
never be lost. Consider the following scenario:
o Two clients A and B are interested in editing the resource
'index.html'. Client A is an HTTP client rather than a WebDAV
client, and so does not know how to perform locking.
o Client A doesn't lock the document, but does a GET and begins
editing.
o Client B does LOCK, performs a GET and begins editing.
o Client B finishes editing, performs a PUT, then an UNLOCK.
o Client A performs a PUT, overwriting and losing all of B's
changes.
There are several reasons why the WebDAV protocol itself cannot
prevent this situation. First, it cannot force all clients to use
locking because it must be compatible with HTTP clients that do not
comprehend locking. Second, it cannot require servers to support
locking because of the variety of repository implementations, some of
which rely on reservations and merging rather than on locking.
Reschke Expires December 17, 2004 [Page 24]
Internet-Draft WebDAV Locking Protocol June 2004
Finally, being stateless, it cannot enforce a sequence of operations
like LOCK / GET / PUT / UNLOCK.
WebDAV servers that support locking can reduce the likelihood that
clients will accidentally overwrite each other's changes by requiring
clients to lock resources before modifying them. Such servers would
effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
resources.
WebDAV clients can be good citizens by using a lock / retrieve /
write /unlock sequence of operations (at least by default) whenever
they interact with a WebDAV server that supports locking.
HTTP 1.1 clients can be good citizens, avoiding overwriting other
clients' changes, by using entity tags in If-Match headers with any
requests that would modify resources.
Information managers may attempt to prevent overwrites by
implementing client-side procedures requiring locking before
modifying WebDAV resources.
B.2 Write Lock
This section describes the semantics specific to the write lock type.
The write lock is a specific instance of a lock type, and is the only
lock type described in this specification.
B.2.1 Methods Restricted by Write Locks
If a request would modify the content for a locked resource, a dead
property of a locked resource, a live property that is defined to be
lockable for a locked resource, or an internal member URI of a locked
collection, the request MUST fail unless the lock-token for that lock
is submitted in the request. An internal member URI of a collection
is considered to be modified if it is added, removed, or identifies a
different resource. [[anchor41: Copy of GULP, "Locked State".
--reschke]]
B.2.2 Write Locks and Lock Tokens
A successful request for an exclusive or shared write lock MUST
result in the generation of a unique lock token associated with the
requesting principal. Thus if five principals have a shared write
lock on the same resource there will be five lock tokens, one for
each principal.
Reschke Expires December 17, 2004 [Page 25]
Internet-Draft WebDAV Locking Protocol June 2004
B.2.3 Write Locks and Properties
While those without a write lock may not alter a property on a
resource it is still possible for the values of live properties to
change, even while locked, due to the requirements of their schemas.
Only dead properties and live properties defined to respect locks are
guaranteed not to change while write locked.
B.2.4 Write Locks and Collections
A write lock on a collection, whether created by a "Depth: 0" or
"Depth: infinity" lock request, prevents the addition or removal of
member URIs of the collection by non-lock owners. As a consequence,
when a principal issues a PUT or POST request to create a new
resource under a URI which needs to be an internal member of a write
locked collection to maintain HTTP namespace consistency, or issues a
DELETE to remove an internal member URI of a write locked collection,
this request MUST fail if the principal does not have a write lock on
the collection.
However, if a write lock request is issued to a collection containing
member URIs identifying resources that are currently locked in a
manner which conflicts with the write lock, the request MUST fail
with a 423 (Locked) status code (Note that this can only occur for a
request of a "Depth: infinity" write lock).
If a lock owner causes the URI of a resource to be added as an
internal member URI of a "Depth: infinity" locked collection then
the new resource MUST be automatically added to the lock. This is
the only mechanism that allows a resource to be added to a write
lock. Thus, for example, if the collection /a/b/ is write locked and
the resource /c is moved to /a/b/c then resource /a/b/c will be added
to the write lock.
B.2.5 Write Locks and the If Request Header
If a user agent is not required to have knowledge about a lock when
requesting an operation on a locked resource, the following scenario
might occur. Program A, run by User A, takes out a write lock on a
resource. Program B, also run by User A, has no knowledge of the
lock taken out by Program A, yet performs a PUT to the locked
resource. In this scenario, the PUT succeeds because locks are
associated with a principal, not a program, and thus program B,
because it is acting with principal A's credential, is allowed to
perform the PUT. However, had program B known about the lock, it
would not have overwritten the resource, preferring instead to
present a dialog box describing the conflict to the user. Due to
this scenario, a mechanism is needed to prevent different programs
Reschke Expires December 17, 2004 [Page 26]
Internet-Draft WebDAV Locking Protocol June 2004
from accidentally ignoring locks taken out by other programs with the
same authorization.
In order to prevent these collisions a lock token MUST be submitted
in the If header for all locked resources that a method may interact
with or the method MUST fail. For example, if a resource is to be
moved and both the source and destination are locked then two lock
tokens must be submitted, one for the source and the other for the
destination.
Servers SHOULD restrict usage of the lock token to exactly the
authenticated principal who created the lock.
B.2.5.1 Example - Write Lock
>>Request
COPY /~fielding/index.html HTTP/1.1
Host: example.com
Destination: http://example.com/users/f/fielding/index.html
If:
()
>>Response
HTTP/1.1 204 No Content
In this example, even though both the source and destination are
locked, only one lock token must be submitted, for the lock on the
destination. This is because the source resource is not modified by
a COPY, and hence unaffected by the write lock. In this example,
user agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in the underlying transport
layer.
B.2.6 Write Locks and COPY/MOVE
A COPY method invocation MUST NOT duplicate any write locks active on
the source. However, as previously noted, if the COPY copies the
resource into a collection that is locked with "Depth: infinity",
then the resource will be added to the lock.
A successful MOVE request on a write locked resource MUST NOT move
the write lock with the resource. However, the resource is subject
to being added to an existing lock at the destination, as specified
in Appendix B.2.4. For example, if the MOVE makes the resource a
child of a collection that is locked with "Depth: infinity", then the
resource will be added to that collection's lock. Additionally, if a
Reschke Expires December 17, 2004 [Page 27]
Internet-Draft WebDAV Locking Protocol June 2004
resource locked with "Depth: infinity" is moved to a destination that
is within the scope of the same lock (e.g., within the namespace tree
covered by the lock), the moved resource will again be a added to the
lock. In both these examples, as specified in Appendix B.2.5, an If
header must be submitted containing a lock token for both the source
and destination.
B.2.7 Refreshing Write Locks
[[anchor47: Just state that locks can be refreshed and point to
actual method description. --reschke]]
B.3 HTTP Methods for Distributed Authoring
B.3.1 LOCK Method
B.3.1.1 Operation
[[anchor51: Make sure updated method description discusses applying
LOCK to null resources. --reschke]]
A LOCK method invocation creates the lock specified by the lockinfo
XML element on the resource identified by the Request-URI. Lock
method requests SHOULD have a XML request body which contains an
owner XML element for this lock request, unless this is a refresh
request. The LOCK request may have a Timeout header.
Clients MUST assume that locks may arbitrarily disappear at any time,
regardless of the value given in the Timeout header. The Timeout
header only indicates the behavior of the server if "extraordinary"
circumstances do not occur. For example, an administrator may remove
a lock at any time or the system may crash in such a way that it
loses the record of the lock's existence. The response for a
successful LOCK creation request MUST contain the value of the
DAV:lockdiscovery property in a prop XML element.
In order to indicate the lock token associated with a newly created
lock, a Lock-Token response header MUST be included in the response
for every successful LOCK request for a new lock. Note that the
Lock-Token header would not be returned in the response for a
successful refresh LOCK request because a new lock was not created.
B.3.1.2 The Effect of Locks on Properties and Collections
The scope of a lock is the entire state of the resource, including
its body and associated properties. As a result, a lock on a
resource MUST also lock the resource's properties.
Reschke Expires December 17, 2004 [Page 28]
Internet-Draft WebDAV Locking Protocol June 2004
For collections, a lock also affects the ability to add or remove
members. The nature of the effect depends upon the type of access
control involved.
B.3.1.3 Locking Replicated Resources
A resource may be made available through more than one URI. However
locks apply to resources, not URIs. Therefore a LOCK request on a
resource MUST NOT succeed if can not be honored by all the URIs
through which the resource is addressable.
B.3.1.4 Depth and Locking
The Depth header may be used with the LOCK method. Values other than
0 or infinity MUST NOT be used with the Depth header on a LOCK
method. All resources that support the LOCK method MUST support the
Depth header.
A Depth header of value 0 means to just lock the resource specified
by the Request-URI.
If the Depth header is set to infinity then the resource specified in
the Request-URI along with all its internal members, all the way down
the hierarchy, are to be locked. A successful result MUST return a
single lock token which represents all the resources that have been
locked. If an UNLOCK is successfully executed on this token, all
associated resources are unlocked. If the lock cannot be granted to
all resources, a 207 (Multistatus) status code MUST be returned with
a response entity body containing a multistatus XML element
describing which resource(s) prevented the lock from being granted.
Hence, partial success is not an option. Either the entire hierarchy
is locked or no resources are locked.
If no Depth header is submitted on a LOCK request then the request
MUST act as if a "Depth:infinity" had been submitted.
B.3.1.5 Interaction with other Methods
The interaction of a LOCK with various methods is dependent upon the
lock type. However, independent of lock type, a successful DELETE of
a resource MUST cause all of its locks to be removed.
Reschke Expires December 17, 2004 [Page 29]
Internet-Draft WebDAV Locking Protocol June 2004
B.3.1.6 Lock Compatibility Table
The table below describes the behavior that occurs when a lock
request is made on a resource.
+-------------------------+--------------------+--------------------+
| Current lock state / | Shared Lock | Exclusive Lock |
| Lock request | | |
+-------------------------+--------------------+--------------------+
| None | True | True |
| Shared Lock | True | False |
| Exclusive Lock | False | False* |
+-------------------------+--------------------+--------------------+
Legend: True = lock may be granted. False = lock MUST NOT be
granted. *=It is illegal for a principal to request the same lock
twice.
The current lock state of a resource is given in the leftmost column,
and lock requests are listed in the first row. The intersection of a
row and column gives the result of a lock request. For example, if a
shared lock is held on a resource, and an exclusive lock is
requested, the table entry is "false", indicating the lock must not
be granted.
B.3.1.7 Status Codes
200 (OK) - The lock request succeeded and the value of the
DAV:lockdiscovery property is included in the body.
412 (Precondition Failed) - The included lock token was not
enforceable on this resource or the server could not satisfy the
request in the lockinfo XML element.
423 (Locked) - The resource is locked, so the method has been
rejected.
B.4 HTTP Headers for Distributed Authoring
B.4.1 Depth Header
[[anchor58: Add "Depth" header considerations: --reschke]]
If a resource, source or destination, within the scope of the method
with a Depth header is locked in such a way as to prevent the
successful execution of the method, then the lock token for that
resource MUST be submitted with the request in the If request header.
Reschke Expires December 17, 2004 [Page 30]
Internet-Draft WebDAV Locking Protocol June 2004
B.4.2 If Header
[[anchor59: Add "If" header considerations: --reschke]]
B.4.3 Timeout Request Header
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; See section 4.2 of [RFC2616]
[[anchor60: Discussion of timeout behaviour should move somewhere
else. Keep only the actual syntax description here. --reschke]]
Clients may include Timeout headers in their LOCK requests. However,
the server is not required to honor or even consider these requests.
Clients MUST NOT submit a Timeout request header with any method
other than a LOCK method.
A Timeout request header MUST contain at least one TimeType and may
contain multiple TimeType entries. The purpose of listing multiple
TimeType entries is to indicate multiple different values and value
types that are acceptable to the client. The client lists the
TimeType entries in order of preference.
Timeout response values MUST use a Second value, Infinite, or a
TimeType the client has indicated familiarity with. The server may
assume a client is familiar with any TimeType submitted in a Timeout
header.
The "Second" TimeType specifies the number of seconds that will
elapse between granting of the lock at the server, and the automatic
removal of the lock. The timeout value for TimeType "Second" MUST
NOT be greater than 2^32-1.
If the timeout expires then the lock may be lost. Specifically, if
the server wishes to harvest the lock upon time-out, the server
SHOULD act as if an UNLOCK method was executed by the server on the
resource using the lock token of the timed-out lock, performed with
its override authority. Thus logs should be updated with the
disposition of the lock, notifications should be sent, etc., just as
they would be for an UNLOCK request.
Servers are advised to pay close attention to the values submitted by
clients, as they will be indicative of the type of activity the
client intends to perform. For example, an applet running in a
browser may need to lock a resource, but because of the instability
of the environment within which the applet is running, the applet may
be turned off without warning. As a result, the applet is likely to
Reschke Expires December 17, 2004 [Page 31]
Internet-Draft WebDAV Locking Protocol June 2004
ask for a relatively small timeout value so that if the applet dies,
the lock can be quickly harvested. However, a document management
system is likely to ask for an extremely long timeout because its
user may be planning on going off-line.
A client MUST NOT assume that just because the time-out has expired
the lock has been lost.
B.5 XML Element Definitions
B.5.1 lockinfo XML Element
Name: lockinfo
Namespace: DAV:
Purpose: The lockinfo XML element is used with a LOCK method to
specify the type of lock the client wishes to have created.
Appendix C. GULP
*Copied from
*
.
C.1 Directly vs Indirectly
A lock either directly or indirectly locks a resource.
C.2 Creating Locks
A LOCK request with a non-empty body creates a new lock, and the
resource identified by the request-URL is directly locked by that
lock. The "lock-root" of the new lock is the request-URL. If at the
time of the request, the request-URL is not mapped to a resource, a
new resource with empty content MUST be created by the request.
C.3 Lock Inheritance
If a collection is directly locked by a depth:infinity lock, all
members of that collection (other than the collection itself) are
indirectly locked by that lock. In particular, if an internal member
resource is added to a collection that is locked by a depth:infinity
lock, and if the resource is not locked by that lock, then the
Reschke Expires December 17, 2004 [Page 32]
Internet-Draft WebDAV Locking Protocol June 2004
resource becomes indirectly locked by that lock. Conversely, if a
resource is indirectly locked with a depth:infinity lock, and if the
result of deleting an internal member URI is that the resource is no
longer a member of the collection that is directly locked by that
lock, then the resource is no longer locked by that lock.
C.4 Removing Locks
An UNLOCK request deletes the lock with the specified lock token.
The request-URL of the request MUST identify a resource that is
either directly or indirectly locked by that lock. After a lock is
deleted, no resource is locked by that lock.
C.5 Submitting Lock Tokens
A lock token is "submitted" in a request when it appears in an "If"
request header.
C.6 Locked State
If a request would modify the content for a locked resource, a dead
property of a locked resource, a live property that is defined to be
lockable for a locked resource, or an internal member URI of a locked
collection, the request MUST fail unless the lock-token for that lock
is submitted in the request. An internal member URI of a collection
is considered to be modified if it is added, removed, or identifies a
different resource.
C.7 URL protection
If a request causes a directly locked resource to no longer be mapped
to the lock-root of that lock, then the request MUST fail unless the
lock-token for that lock is submitted in the request. If the request
succeeds, then that lock MUST have been deleted by that request.
C.8 Exclusive vs Shared
If a request would cause a resource to be locked by two different
exclusive locks, the request MUST fail.
Appendix D. 'opaquelocktoken' URI Scheme
The opaquelocktoken URI scheme is designed to be unique across all
resources for all time. Due to this uniqueness quality, a client may
submit an opaque lock token in an If header on a resource other than
the one that returned it.
All resources MUST recognize the opaquelocktoken scheme and, at
Reschke Expires December 17, 2004 [Page 33]
Internet-Draft WebDAV Locking Protocol June 2004
minimum, recognize that the lock token does not refer to an
outstanding lock on the resource.
In order to guarantee uniqueness across all resources for all time
the opaquelocktoken requires the use of the Universal Unique
Identifier (UUID) mechanism, as described in [ISO-11578].
Opaquelocktoken generators, however, have a choice of how they create
these tokens. They can either generate a new UUID for every lock
token they create or they can create a single UUID and then add
extension characters. If the second method is selected then the
program generating the extensions MUST guarantee that the same
extension will never be used twice with the associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
production is the string representation of a UUID, as defined in
[ISO-11578]. Note that white space (LWS) is not allowed between
elements of this production.
Extension = path ; path is defined in [RFC2396], section 3.3.
D.1 Node Field Generation Without the IEEE 802 Address
UUIDs, as defined in [ISO-11578], contain a "node" field that
contains one of the IEEE 802 addresses for the server machine. As
noted in Section 10.1, there are several security risks associated
with exposing a machine's IEEE 802 address. This section provides an
alternate mechanism for generating the "node" field of a UUID which
does not employ an IEEE 802 address. WebDAV servers MAY use this
algorithm for creating the node field when generating UUIDs. The
text in this section is originally from an Internet-Draft by Paul
Leach and Rich Salz, who are noted here to properly attribute their
work.
The ideal solution is to obtain a 47 bit cryptographic quality random
number, and use it as the low 47 bits of the node ID, with the most
significant bit of the first octet of the node ID set to 1. This bit
is the unicast/multicast bit, which will never be set in IEEE 802
addresses obtained from network cards; hence, there can never be a
conflict between UUIDs generated by machines with and without network
cards.
If a system does not have a primitive to generate cryptographic
quality random numbers, then in most systems there are usually a
fairly large number of sources of randomness available from which one
can be generated. Such sources are system specific, but often
include:
Reschke Expires December 17, 2004 [Page 34]
Internet-Draft WebDAV Locking Protocol June 2004
o the percent of memory in use
o the size of main memory in bytes
o the amount of free main memory in bytes
o the size of the paging or swap file in bytes
o free bytes of paging or swap file
o the total size of user virtual address space in bytes
o the total available user address space bytes
o the size of boot disk drive in bytes
o the free disk space on boot drive in bytes
o the current time
o the amount of time since the system booted
o the individual sizes of files in various system directories
o the creation, last read, and modification times of files in
various system directories
o the utilization factors of various system resources (heap, etc.)
o current mouse cursor position
o current caret position
o current number of running processes, threads
o handles or IDs of the desktop window and the active window
o the value of stack pointer of the caller
o the process and thread ID of caller
o various processor architecture specific performance counters
(instructions executed, cache misses, TLB misses)
(Note that it is precisely the above kinds of sources of randomness
that are used to seed cryptographic quality random number generators
on systems without special hardware for their construction.)
Reschke Expires December 17, 2004 [Page 35]
Internet-Draft WebDAV Locking Protocol June 2004
In addition, items such as the computer's name and the name of the
operating system, while not strictly speaking random, will help
differentiate the results from those obtained by other systems.
The exact algorithm to generate a node ID using these data is system
specific, because both the data available and the functions to obtain
them are often very system specific. However, assuming that one can
concatenate all the values from the randomness sources into a buffer,
and that a cryptographic hash function such as MD5 is available, then
any 6 bytes of the MD5 hash of the buffer, with the multicast bit
(the high bit of the first byte) set will be an appropriately random
node ID.
Other hash functions, such as SHA-1, can also be used. The only
requirement is that the result be suitably random in the sense that
the outputs from a set uniformly distributed inputs are themselves
uniformly distributed, and that a single bit change in the input can
be expected to cause half of the output bits to change.
Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1 Since draft-reschke-webdav-locking-00
Add and resolve issue "rfc2606-compliance". Resolve issues
"extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL",
"025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS",
"039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02",
"040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL",
"065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION",
"080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC",
"089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK",
"101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS",
"109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and
"111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work
on moving text from RFC2518 excerpts into new sections. Define new
compliance class "locking" (similar to "bis" in RFC2518bis, but only
relevant to locking). Reformatted "GULP" into separate subsections
for easier reference.
E.2 Since draft-reschke-webdav-locking-01
Update "008_URI_URL", "040_LOCK_ISSUES_06",
"063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY",
"067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN".
Re-opened "065_UNLOCK_WHAT_URL". Close
"070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK
refresh method descriptions. Fix page title (TXT version). Close
"052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH",
Reschke Expires December 17, 2004 [Page 36]
Internet-Draft WebDAV Locking Protocol June 2004
"060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and
resolve "8.10.1_lockdiscovery_on_failure". Started attempt to
clarify status code.
E.3 Since draft-reschke-webdav-locking-02
Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04",
"040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS",
"067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN".
Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version
(5.7). Add and resolve new issue "7.5_DELETE_vs_URIs". Start work
on "additional marshalling" and "introduction". Update issues
"044_REPORT_OTHER_RESOURCE_LOCKED" and
"066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL".
Appendix F. Resolved issues (to be removed by RFC Editor before
publication)
Issues that were either rejected or resolved in this version of this
document.
F.1 065_UNLOCK_WHAT_URL
Type: change
Juergen.Pill@softwareag.com (2001-03-01): What do you return if the
unlock request specifies a URL on which the lock does not reside?
What if it's on a URL that is locked by the lock, but it's not the
resource where the lock is rooted?
julian.reschke@greenbytes.de (2004-06-01): New discussion, resolution
pending. See
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0120.html.
Resolution (2004-06-12): Resolution (as of May 31, 2004) from RFC2518
issues list: Resolved that you can specify any URL locked by the lock
you want to unlock.
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html)
We should resolve the issue of UNLOCK'ing other URLs in a few days.
See also
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0170.html.
Reschke Expires December 17, 2004 [Page 37]
Internet-Draft WebDAV Locking Protocol June 2004
F.2 067_UNLOCK_NEEDS_IF_HEADER
Type: change
dbrotsky@Adobe.COM (): Shouldn't we be using an IF header to do an
UNLOCK seeing as you need to prove you are holding a lock before you
can remove it? (This might be contingent on
063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)
Resolution: Testing of current implementations shows that servers
indeed use the "Lock-Token" request header to specify the lock to be
removed; and that they do not require an additional "If" header. No
change. See also
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0178.html.
F.3 068_UNLOCK_WITHOUT_GOOD_TOKEN
Type: change
dbrotsky@Adobe.COM (): What should UNLOCK return if a bad token is
provided or no token. (This might be contingent on
UNLOCK_NEEDS_IF_HEADER.)
julian.reschke@greenbytes.de (2004-06-06): According to the rewritten
description, this will be a 4xx with condition code
DAV:lock-token-matches. Check the status codes for existing
implementations, though.
julian.reschke@greenbytes.de (2004-06-07): Results: (a) Microsoft IIS
5.0: (a1) no lock token: 400, (a2) bad lock token: 412, (a3) unlocked
resource: 412. (b) Apache/Moddav 2.0.49: (b1) no lock token: 400,
(b2): bad lock token: 400, (b3) unlocked resource: 400. (c) SAP
Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock
token: 412, (c3) unlocked resource: 412. (d) Xythos (Sharemation):
see (c).
Resolution (2004-06-15): Clarify that the Lock-Token header does not
contribute to the set of preconditions that are relevant for a 412
status. Thus other 4xx status code are be recommended here (note
that more details can be obtained by processing the optional
DAV:error response body). See also
Reschke Expires December 17, 2004 [Page 38]
Internet-Draft WebDAV Locking Protocol June 2004
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0180.html
F.4 040_LOCK_ISSUES_08
Type: change
ccjason@us.ibm.com (1999-06-07): Shared locks... read locks... Our
justifcation for shared locks ("Shared locks are included
because....") seems faulty. It's not a mechansim for dealing with
programs that forget to release their locks. That remains a problem
with shared locks. In this case they'd forget to release a shared
lock and block exclusive lock users. Timeouts and administrative
action are the solutions to this problem... not shared locks. BTW,
I'd think that the use of exclusive locks is just fine. I do have a
problem with shared locks though... or at least shared write locks.
Although they were relatively easy to define, I see them as solving a
red herring problem of multiple entites cooperatively writing using
distinct locks. I say it's a red herring because they don't know
each other well enough to use the same lock but they do know each
other well enough to not step on each other. This seems unlikely.
As does the managing a compatibility matrix and getting all the
entities to abide by it. OTOH I see another more common problem that
is being overlooked. I see a class of folks whose purpose is to not
actually write to a (set of) resource(s), but to simply prevent
others from writing to it while they are looking at it. Shared write
locks do not necessarily do that because with a shared write lock.
someone else could grab a shared lock and go ahead and write. The
only way to block that is to get an exclusive write lock. But doing
that prevents anyone else from doing what you're doing despite it
being pretty benign. An expedient solution is to say that a shared
write lock should not necessarily give one the right to modify a
resource. All it should do is prevent others from writing. And then
the purpose of an exclusive write lock is just to insure that others
can't get a lock and block you from writing. Now is this the right
solution? Probably not. There probably should be something called a
read lock that actually prevents writes as a side effect.... and
would tend to get used in shared mode. Anyway, as it is, I think the
shared write locks are a red herring and we're missing something we
are more likely to need... shared read locks.
julian.reschke@greenbytes.de (2004-06-17): Reject: shared lock
semantics have been stable since publication of RFC2518. However,
state what the advantage of a shared lock in this case is.
Reschke Expires December 17, 2004 [Page 39]
Internet-Draft WebDAV Locking Protocol June 2004
F.5 040_LOCK_ISSUES_03
Type: change
ccjason@us.ibm.com (1999-06-07): Section 7.1 Write lock. I believe
this definition of a write lock is not right... or not complete...
judging from what I read elsewhere. I believe one can do these
operations without a write lock... as long as someone else doesn't
have a write lock on the resources effected. I also believe it
doesn't prevent LOCK requests in the case of shared locks.
julian.reschke@greenbytes.de (2004-06-16): Remove paragraph and copy
relevant section from GULP.
F.6 7.5_DELETE_vs_URIs
Type: change
julian.reschke@greenbytes.de (2004-06-14): Section 7.5 Write Locks
and Collections. "...or issues a DELETE to remove a resource which
has a URI which is an existing internal member URI of a write locked
collection, this request MUST fail if the principal does not have a
write lock on the collection." This is consistent with RFC2518's
definition of DELETE, however the requirement to remove *all* URIs
mapped to the resource is incompatible with BIND and has been removed
in RFC2518bis-05. Thus we should rewrite section 7.5 as: "..., or
issues a DELETE to remove an internal member URI of a write locked
collection, this request MUST fail if the principal does not have a
write lock on the collection."
Resolution (2004-06-15): Done.
F.7 040_LOCK_ISSUES_04
Type: change
ccjason@us.ibm.com (1999-06-07): Section 7.5 Write Locks and
Collections. It says that if members are locked in a conflicting
manner, then their collection can't be locked. That seems
Reschke Expires December 17, 2004 [Page 40]
Internet-Draft WebDAV Locking Protocol June 2004
ambiguously safe to say, but I suspect that text should mention depth
since if the parent lock request is depth 0, I don't think we let the
members lock state effect the success of the LOCK request. The
possible exception is what we said about protecting a URI that was
used to perform a lock (of a member of the collection). I'm not sure
what we'd like to say for that. In the advanced collection meetings
we refered to these being "protected" and avoided speaking about
"lock"ing the URI. This creates an odd situation though.
Resolution (2004-06-14): Clarify that this only applies to the
attempt to depth-infinity lock the collection.
F.8 053_LOCK_INHERITANCE
Type: edit
jrd3@alum.mit.edu (1999-11-26): Section 7.5 states, "If a lock owner
causes the URI of a resource to be added as an internal member URI of
a locked collection then the new resource MUST be automatically added
to the lock." However, though this is the intent, the specification
does not explicitly state that this behavior only applies to depth
infinity locked collections. The words "Depth infinity" should be
added before the word "locked" in this sentence.
Resolution (2004-06-14): Agreed; make that change.
F.9 057_LOCK_SEMANTICS
Type: change
(): At present, the WebDAV specification is not excruciatingly
explicit that writing to a locked resource requires the combination
of the lock token, plus an authentication principal. At one point,
the spec. discusses an "authorized" principal, but "authorized" is
never explicitly defined.
Resolution (2004-06-17): Submitting the lock token in an If header
(usages != UNLOCK) SHOULD be restricted to whatever the server thinks
the "owner" of the lock is. See discussion at
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57.
Appendix G. Open issues (to be removed by RFC Editor prior to
publication)
Reschke Expires December 17, 2004 [Page 41]
Internet-Draft WebDAV Locking Protocol June 2004
G.1 import-rfc3253-stuff
Type: change
julian.reschke@greenbytes.de (2004-04-25): Import error marshalling
and terminology from RFC3253.
G.2 import-gulp
Type: change
julian.reschke@greenbytes.de (2004-05-25): Make specification text
compatible with GULP where it isn't. Integrate GULP as normative
specification of the locking behaviour.
G.3 edit
Type: edit
julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for
editorial fixes/enhancements.
G.4 008_URI_URL
Type: change
masinter@parc.xerox.com (1998-11-09): Perform a thorough review of
the specification to ensure that URI and URL are used correctly, and
consistently throughout.
julian.reschke@greenbytes.de (2004-06-04): Use "request URI" when
talking particularily about HTTP messages because this is the term
used by RFC2616. Use "URL" when talking about HTTP/WebDAV resources.
Otherwise use URI, making sure that if a relativeURI (as defined by
RFC2396) is allowed, we say so.
Resolution: Seems to have been deferred:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html,
but there is some follow on discussion on what exactly needs to be
clarified:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html,
but no specific action was concluded besides the fact that we don't
need to wait for RFC2396 to be updated or request any changes/
clarifications to that.
Reschke Expires December 17, 2004 [Page 42]
Internet-Draft WebDAV Locking Protocol June 2004
G.5 040_LOCK_ISSUES_06
Type: change
ccjason@us.ibm.com (1999-06-07): Upon cursory reading of the rfc 2518
sec 8.10.4 through 8.11 I was confused by the plethoria of error
codes. Nothing seems to unify them. 8.10.4 speaks of a return code
of 409 Conflict if a lock can't be granted. - Firstly, I can't tell
if it is saying that the 409 is within the multistatus body... or in
the response header. - Secondly, later text seems to use a different
status codes and never mentions this one again. 8.10.7 lists status
codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed,
but 409 Conflict (mentioned above) is not. - In the case of 412
Precondition Failed, the description the follows doesn't seem to
describe a "precondition failed". And it sounds like it's talking
about an access request that includes a "locktoken", not a LOCK
request that generates one. - The 423 Locked condition also sort of
sounds like it's talking about an access request rather than a LOCK
request. 8.10.10 lists LOCK status codes - 207 Multistatus which was
not mentioned above - 403 Forbidden which was not mentioned above.
- 424 Failed dependency which was not mentioned above. 8.11 UNLOCK
- we don't mention what the failure response should look like. -
comment: 200 OK seems like a better response than 204 No Content.
The brief explanation isn't persuasive and seems to say that the
response code should serve the purpose of the Content-Length.
header. - we should probably explicitly say if an UNLOCK can only be
done on the original resource... and will fail even if the resource
specified is locked by virtue of being a child of the original
resource. Or is this too obvious? I know it's something easy to
goof up in an implementation.
julian.reschke@greenbytes.de (2004-06-04): (1) 8.10.4 is wrong. The
return code is 207. See issue 037_DEEP_LOCK_ERROR_STATUS, resolved
in draft 01. (2) General agreement that descriptions of error
marshalling needs to be redone. This applies both th LOCK and
UNLOCK. (3) Agreement that the argument given for 204 is lame;
clients should handle all 2xx status codes with the notable exception
of 207 as "success". We may want to explain that in RFC2518bis'
section about 207.
G.6 056_DEPTH_LOCK_AND_IF
Type: change
Reschke Expires December 17, 2004 [Page 43]
Internet-Draft WebDAV Locking Protocol June 2004
joe@orton.demon.co.uk (2000-03-04): The specification is currently
silent on how to use the If header for submitting a locktoken when
performing a DELETE in a Depth infinity locked collection. Should
the If header have both the collection URL and the Request-URI, or
just the Request-URI? An example of this is needed.
julian.reschke@greenbytes.de (2004-04-25): Clarify as part of
integrating GULP. May need to test interop with existing
implementations.
G.7 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
Type: change
jrd3@alum.mit.edu (): Is the complexity of the IF header appropriate
for the simple task o verifying that a client knowingly owns a lock?
The IF header seems to serve a different purpose. One of those
purposes is for the server to verify that you have the lock token
(and that you know the root of it?). Another is for the client to
check some preconditions before doing an action. Another seems to be
to specify what lock to refresh in a lock refresh request. This
seems to create ambiguity in our definition of the semantics of the
IF: header.
ccjason@us.ibm.com (): It is felt by the group that it's important
that the client not just own and hold the lock token, but that it
also know where the lock is rooted before it does tasks related to
that lock. This still leaves the lock referesh issue unresolved.
julian.reschke@greenbytes.de (2004-06-02): Re.: using Lock-Token to
identify the lock to be refreshed
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0127.html):
problems with current rfc2518bis-05 wording; also no support in
popular implementations; suggestion to roll-back changes in -bis and
keep "If" header based syntax.
G.8 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED
Type: change
(): The DAV:owner field of a lock is controlled by the locking client
and should not be manipulated by the server. This is the only place
the client can store info. The roundtrip details should match what
we resolve for the PROP_ROUNDTRIP issue. Examples should also be
checked.
Resolution: Resolved by repeated statement and no disagreement.
Reschke Expires December 17, 2004 [Page 44]
Internet-Draft WebDAV Locking Protocol June 2004
G.9 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION
Type: change
ccjason@us.ibm.com (): What resource should be flagged in the
multistatus response to locking issues in COPY/MOVE requests?
Resolution: Resolved to flag the locking errors at the source
resource that was affected by the problem. The details of how to
describe the error was deferred to a subsequent version of WebDAV. -
6/15/02 - 2518bis does not reflect this.
G.10 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION
Type: change
(): The method of describing the details of (beyond what resolved by
COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of
various locking and ACL COPY/MOVE problems is deferred. Two
proposals were outlined in the discussion, but interest was not great
and we clearly don't have interoperability to take these proposals
forward.
G.11 072_LOCK_URL_WITH_NO_PARENT_COLLECTION
Type: change
dbrotsky@Adobe.COM (): If a LOCK request is submitted to a URL that
doesn't have a parent collection, what should be the correct
response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409
response in this case. Seems like LOCK should have this requirement
as well.
Resolution: Resolved that since LNRs no longer exist (see
NULL_RESOURCE_CLARIFY) the server should return 409. We should
insure that the new text we add to replace LNRs does not create an
ambiguity:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html
Reschke Expires December 17, 2004 [Page 45]
Internet-Draft WebDAV Locking Protocol June 2004
G.12 044_REPORT_OTHER_RESOURCE_LOCKED
Type: change
wiggs@xythos.com (1999-07-23): In some cases, such as when the parent
collection of a resource is locked, a 423 (Locked) status code is
returned even though the resource identified by the Request-URI is
not locked. This can be confusing, since it is not possible for a
client to easily discover which resource is causing the locked status
code to be returned. An improved status report would indicate the
resource causing the lock message.
julian.reschke@greenbytes.de (2004-04-25): Proposal to define a
specific precondition element plus specific child elements similar to
RFC3744, section 7.1.1.
julian.reschke@greenbytes.de (2004-06-18): See summary and proposal
in
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0192.html.
G.13 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL
Type: change
(): Right now the server uses the IF: header to verify that a client
knows what locks it has that are affected by an operation before it
allows the operation. Must the client provide the root URL of a
lock, any URL for a pertainent loc, or some specific URL in the IF:
header.
ccjason@us.ibm.com (): It is felt by the group that it's important
that the client not just own and hold the lock token, but that it
also know where the lock is rooted before it does tasks related to
that lock. This is just a point of info. The issue itself still
needs to be brought up and answered.still
julian.reschke@greenbytes.de (): Summary: current implementations do
not seem to care (see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0190.html).
Suggestion to require clients to specify the lock root anyway,
because this is what the WG agreed upon earlier.
Reschke Expires December 17, 2004 [Page 46]
Internet-Draft WebDAV Locking Protocol June 2004
G.14 015_MOVE_SECTION_6.4.1_TO_APPX
Type: change
mda@discerning.com (1998-11-24): The discussion of generating UUID
node fields without using the IEEE 802 address in section 6.4.1 can
be moved to an appendix.
julian.reschke@greenbytes.de (2004-04-31): Plan: get rid of the
section altogether and refer to draft-mealling-uuid-urn. In the
meantime, move the whole opaquelocktoken discussion into an appendix.
Reschke Expires December 17, 2004 [Page 47]
Internet-Draft WebDAV Locking Protocol June 2004
Index
4
423 Locked (status code) 16
C
Condition Names
DAV:lock-removal-allowed (pre) 15
DAV:lock-removed (post) 16
DAV:lock-submission-allowed (pre) 13, 16
DAV:lock-token-matches (pre) 15
DAV:locks-refreshed (post) 13
DAV:name-allowed (pre) 17
DAV:parent-resource-must-be-non-null (pre) 17
D
DAV header
compliance class '2' 17
compliance class 'locking' 17
DAV:lock-removal-allowed precondition 15
DAV:lock-removed postcondition 16
DAV:lock-submission-allowed precondition 13, 16
DAV:lock-token-matches precondition 15
DAV:lockdiscovery property 6
DAV:locks-refreshed postcondition 13
DAV:name-allowed precondition 17
DAV:parent-resource-must-be-non-null precondition 17
DAV:supportedlock property 8
H
Headers
Lock-Token 17
Timeout 31
L
LOCK method 9
lock creation 9
lock refresh 13
Lock-Token header 17
lockinfo
XML element 32
M
Methods
LOCK (lock creation) 9
LOCK (lock refresh) 13
LOCK 9
UNLOCK 15
Reschke Expires December 17, 2004 [Page 48]
Internet-Draft WebDAV Locking Protocol June 2004
O
opaquelocktoken (URI scheme) 33
P
Properties
DAV:lockdiscovery 6
DAV:supportedlock 8
S
Status Codes
423 Locked 16
T
Timeout header 31
U
UNLOCK method 15
URI schemes
opaquelocktoken 33
Reschke Expires December 17, 2004 [Page 49]
Internet-Draft WebDAV Locking Protocol June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Reschke Expires December 17, 2004 [Page 50]