This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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”.¶
This Internet-Draft will expire in November 2004.¶
Copyright © The Internet Society (2004). All Rights Reserved.¶
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.¶
[rfc.comment.1: Note that this document is not a product of the WebDAV working group. It is just an experiment to study the feasability of extracing the locking feature into a separate specification. --reschke] [rfc.comment.2: This version of this document doesn't yet contain any new or rewritten text - it only contains text copied verbatim fro RFC2518 and GULP. It's sole purpose is be a reference point for all future changes. --reschke] ¶
Distribution of this document is unlimited. Please send comments to the WebDAV working group at firstname.lastname@example.org, which may be joined by sending a message with subject "subscribe" to email@example.com.¶
Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/.¶
|I extract-locking (type: change, status: open)|
|firstname.lastname@example.org||2004-04-14||Locking extracted from RFC2518.|
|Associated changes in this document: <#rfc.change.extract-locking.1>.|
|I updated-rfc2068 (type: change, status: open)|
|email@example.com||2004-04-25||Update references of RFC2068 to either RFC2396 or RFC2616.|
|I import-rfc3253-stuff (type: change, status: open)|
|firstname.lastname@example.org||2004-04-25||Import error marshalling and terminology from RFC3253.|
|I 008_URI_URL (type: change, status: open)|
|email@example.com||1998-11-09||Perform a thorough review of the specification to ensure that URI and URL are used correctly, and consistently throughout.|
|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.|
|I 015_MOVE_SECTION_6.4.1_TO_APPX (type: change, status: open)|
|firstname.lastname@example.org||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.|
|email@example.com||2004-04-24||Plan: get rid of the section altogether and refer to draft-mealling-uuid-urn.|
|I 022_COPY_OVERWRITE_LOCK_NULL (type: change, status: open)|
|firstname.lastname@example.org||1998-11-29||If URL Ub is locked, creating a lock-null resource, then if a COPY is performed listing Ub as the destination, COPY will remove the lock-null resource, removing the lock, then perform the copy. A note needs to be added stating that the delete performed by the Overwrite header is atomic with the rest of the operation.|
|Resolution: LNRs removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html.|
|I 025_LOCK_REFRESH_BY_METHODS (type: change, status: open)|
|Jim Amsden: The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed?|
|Resolution: We should remove the mention of this behavior in 2518: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0137.html|
|I 037_DEEP_LOCK_ERROR_STATUS (type: change, status: open)|
|email@example.com||1999-05-18||Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued. Yet, the example in section 8.10.10 which demonstrates this uses a 207.|
|firstname.lastname@example.org||2004-04-24||Comment: 207 is correct, fix the bad spec text.|
|I 039_MISSING_LOCK_TOKEN (type: change, status: open)|
|1999-06-15||Keith Wannamaker: Section 8.10.1 explicitly states that the response from a successful lock request MUST include the Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10 aren't compliant with this requirement, and should be updated.|
|Resolution: Make obvious editing changes to the examples: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0229.html|
|I 040_LOCK_ISSUES (type: change, status: closed)|
|email@example.com||1999-06-07||Jason Crawford's list of lock issues sent to the list.|
|Resolution: Replace with list of distinct issues 040_LOCK_ISSUES_??.|
|I 040_LOCK_ISSUES_01 (type: change, status: open)|
Section 6.3: ""Having a lock token provides no special access rights..."
I suggest that the phrase "owned by another party" be added in this first sentence to distinguish between owning and having. It speaks of "having" in this sentence but not subsequently. In fact "submitting" might be an even better word than having.
|firstname.lastname@example.org||2004-04-24||Agreed, use "submitting".|
|I 040_LOCK_ISSUES_02 (type: change, status: open)|
Section 6.3: "... However resource are free to return any URI scheme so long
as it meets the uniqueness requirements."
This is technically correct, but it might also be useful to say that the scheme should make the URI be readily recognizable as a *LOCK* state token in the event that other types of state tokens exist. I mention this because we seem to have created the possibility of other types of state tokens. -- Your call. :-)
|email@example.com||2004-04-24||Disagreement: any URI scheme can be used as a lock token. Specifications that define other types of state tokens will have to take care of distinguishing them inside an "If" header.|
|I 040_LOCK_ISSUES_03 (type: change, status: open)|
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.
|firstname.lastname@example.org||2004-04-24||Clarify as part of rewriting the general semantics. The point about shared locks is correct, though.|
|I 040_LOCK_ISSUES_04 (type: change, status: open)|
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 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.
|I 040_LOCK_ISSUES_05 (type: change, status: open)|
7.7 Write Locks and COPY/MOVE
It says that a lock doesn't move with a moved resource. Of course if the lock is on the resource, not the URI, it should move with the resource. But then we have the caveat that we are also protecting the LOCK'd URI. I think the rule should be that if we submit the locktoken with the MOVE request, we are allowed to have the LOCK move with the resource and the lock will now protect a different URI. Also, ALL locks in the subtree must be submitted or the MOVE must fail because otherwise it would break our URI protection rule.
|email@example.com||2004-04-24||Clarify as part of incorporating GULP (locks do not MOVE).|
|I 040_LOCK_ISSUES_06 (type: change, status: open)|
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.
- 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.
|I 040_LOCK_ISSUES_07 (type: change, status: open)|
9.4 If header
- BNF suggests that IF's content must be all tagged or all untagged.
- doesn't say if there can be two If headers in a request. Might we want a tagged one and an untagged one?
- I must be misunderstanding this, but it sounds to me like that state of a resource(s) must match one of the locktokens listed in the request. But what if some of the resources are locked and others are not. The unlocked resources definitely won't contain state that's listed. Are we precluding operations on regions that might not be entirely locked? -- Is this a valid observation or a red herring?
184.108.40.206 If header - untagged example
- See my comment about regions that are not entirely locked.
9.4.2 If header -tagged state
- So if we've applied a lock with depth.... and now we're doing a DELETE on a subtree of that tree and we've tagged the locktoken we've submitted, will this prevent that locktoken from apply'ing to ALL the resources of the subtree... and thus prevent the COPY from succeeding? Or are we supposed to tag the lock token with the root of the LOCK even if that is not part of what we are deleting? Or should the request use untagged locktokens?
9.4.3 If header - NOT operator
- Why do we want this? of course... why not? :-)
Overall, the If header seems backwards for locktokens. It's client driven rather than server semantics driven. The only feature it seems to provide is perhaps the ability for the client to request that the request be aborted if the resource no longer is locked. Other than that it seems to complicate the simple process of letting the server know what tokens you hold. I'd think we'd just want a different header to declare what lock tokens we hold and let the server (not the client) decide how they affect the success of the request.
|firstname.lastname@example.org||2004-04-24||This issue needs to be handled in the base protocol.|
|I 040_LOCK_ISSUES_08 (type: change, status: open)|
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.
|email@example.com||2004-04-24||Agreement that the rational for shared locks either needs to be rewritten or deleted. However shared locks are a fact, and we shouldn't change the semantics given in RFC2518.|
|I 043_NULL_LOCK_SLASH_URL (type: change, status: open)|
|firstname.lastname@example.org||1999-07-23||If a URL ending in a slash is null locked, is it legal to do a PUT to it? That is, does the URL ending in slash set the resource type to a collection, or does the first PUT/MKCOL set the resource to a ordinary, or collection resource.|
|Resolution: LNRs removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html|
|I 044_REPORT_OTHER_RESOURCE_LOCKED (type: change, status: open)|
|email@example.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.|
|firstname.lastname@example.org||2004-04-25||Proposal to define a specific precondition element plus specific child elements similar to ACL, section 7.1.1.|
|I 052_LOCK_BODY_SHOULD_BE_MUST (type: change, status: open)|
|email@example.com||1999-11-23||Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST.|
|firstname.lastname@example.org||2004-04-25||Clarify that for creating LOCKs, it MUST have a request body which SHOULD have the DAV:owner element. For LOCK refreshes, no body is required.|
|I 053_LOCK_INHERITANCE (type: change, status: open)|
|email@example.com||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.|
|firstname.lastname@example.org||2004-04-25||Clarify as part of integrating GULP.|
|I 054_IF_AND_AUTH (type: change, status: open)|
|email@example.com||2000-01-27||The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document.|
|firstname.lastname@example.org||2004-05-02||Submitting the lock token in an If header (usages != UNLOCK) SHOULD be restricted to whatever the server thinks the "owner" of the lock is.|
|I 056_DEPTH_LOCK_AND_IF (type: change, status: open)|
|email@example.com||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.|
|firstname.lastname@example.org||2004-04-25||Clarify as part of integrating GULP. May need to test interop with existing implementations.|
|I 057_LOCK_SEMANTICS (type: change, status: open)|
|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.|
|email@example.com||2004-05-02||Submitting the lock token in an If header (usages != UNLOCK) SHOULD be restricted to whatever the server thinks the "owner" of the lock is.|
|I 058_LOCK_SEIZURE (type: change, status: closed)|
|Should it be possible to seize a lock, or for any principal to unlock a lock, thus making it easier for another client to begin working on a locked resource.|
|Resolution: Duplicated by UNLOCK_BY_NON_LOCK_OWNER issue.|
|I 060_LOCK_REFRESH_BODY (type: change, status: open)|
|firstname.lastname@example.org||2000-07-11||Section 7.8 of RFC 2518 indicates that clients may submit a lock refresh without a body. However, it implies that clients could submit a lock refresh with a body. Server implementations have been disallowing a lock refresh with a body. It might make sense to codify this practice, and disallow submission of a body on a lock refresh.|
|email@example.com||2004-04-25||Clarify that LOCK refresh MUST NOT have a request body. Also clarify Lock-Token header vs If header.|
|I 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY (type: change, status: open)|
|firstname.lastname@example.org||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.|
|email@example.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.|
|firstname.lastname@example.org||2004-04-25||Need Lock-Token header to indicate the lock to be refreshed.|
|I 065_UNLOCK_WHAT_URL (type: change, status: open)|
|Juergen.Pill@softwareag.com||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?|
|Resolution: 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.|
|I 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL (type: change, status: open)|
|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.|
|email@example.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|
|I 067_UNLOCK_NEEDS_IF_HEADER (type: change, status: open)|
|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 LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)|
|I 068_UNLOCK_WITHOUT_GOOD_TOKEN (type: change, status: open)|
|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.)|
|I 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER (type: change, status: open)|
|dbrotsky@Adobe.COM||The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header.|
|firstname.lastname@example.org||2004-04-25||Need Lock-Token header to indicate the lock to be refreshed.|
|I 072_LOCK_URL_WITH_NO_PARENT_COLLECTION (type: change, status: open)|
|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|
|I 073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE (type: change, status: open)|
|hwarncke@Adobe.COM||If the DAV:lockdiscovery property is requested from an unlocked resource, what is the correct response? Apache mod_dav responds with an empty mod_dav sends an empty lockdiscovery element (<D:lockdiscovery/>) while IIS sends an empty prop element (<D:prop/>), that is, it sends no lockdiscovery element at all.|
|email@example.com||2004-04-25||The difference shouldn't matter for clients, and they need to expect both. In general, servers that DO support locks on that resource should return an empty element.|
|I 077_LOCK_NULL_STATUS_CREATION (type: change, status: open)|
|firstname.lastname@example.org||What status code should be returned when a lock null resource is created - 200 OK or 201 Created? A related issue is what status code should be returned by a PUT or MKCOL on a lock-null resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201 seems like a slightly better choice).|
|Resolution: Resolved via the proposal to remove LNR and replace them with ordinary resources and by the following wording: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html.|
|I 079_UNLOCK_BY_NON_LOCK_OWNER (type: change, status: open)|
|email@example.com||At present, the specification is not explicit about who might be capable of grabbing a lock token via lock discovery and the submitting it in UNLOCK (and/or for a subsequent write operation). It is OK for the resource owner to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock token" privilege that can be assigned to anyone?|
|Resolution: Resolved in part by putting it under ACL control: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html and the response that follows it.|
|I 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC (type: change, status: open)|
|Proposal to remove lock null resources from the spec until we are motivated to have them or something equivalent. In the meantime, keep the spec silent on the topic in order to avoid precluding LNR or the equivalent in a future version of WebDAV.|
|Resolution: LNRs removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html.|
|I 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED (type: change, status: open)|
|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.|
|I 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK (type: change, status: open)|
|firstname.lastname@example.org||It would be good if a client could look at a locked resource that it was planning to unlock and also find out if it's depth locked and where the depth lock is rooted.|
|Resolution: Proposed solution: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html approved.|
|I 093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK (type: change, status: closed)|
|email@example.com||How does a client determine if a given lock was created by it?|
|Resolution: It was resolved that this type of info would not be provided by the server. The client creating the lock could store owner info in the DAV:owner field (or some field defined in the future) if it wishes. The querying client can also check ACL's to get similar info.|
|I 096_SHARED_LOCKS_INTEROP_NOT_TESTED (type: change, status: closed)|
|firstname.lastname@example.org||There might not be any implementations of shared locks. If so, remove them.|
|Resolution: The thread did conclude that shared locks interoperate although it doesn't look like they get used much. Also see: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0139.html.|
|I 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION (type: change, status: open)|
|email@example.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.|
|I 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION (type: change, status: open)|
|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.|
|I 101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS (type: change, status: open)|
|firstname.lastname@example.org||There is some confusion on how a PROPFIND response should express the fact that a resource has multiple shared locks on it. It was suggested that the spec become clearer.|
|Resolution: Resolved trivially that it's probably worthwhile to demonstrate a correc response for this situation in one of the examples.|
|I 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK (type: change, status: open)|
|email@example.com||If one finds a locked resource, it might be one of several resource locked by a depth lock. How does one determine the root of the lock?|
|Resolution: Resolved to support a dav:lockroot element in the lock discovery property: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html|
|I 111_MULTIPLE_TOKENS_PER_LOCK (type: change, status: open)|
|firstname.lastname@example.org||12.1.2 states that a dav:locktoken tag can have multiple <dav:href> tags in it. Is this right? And is it trying to suggest that a single (shared) lock might have multiple locktokens?|
|Resolution: It is resolved that section 12.1.2 was incorrect and that only a single lock token URI should be allowed there. Also it is resolved that a lock only has a single lock token.|
This document is the collaborative product of ¶
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.
Copyright © 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.¶
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.¶
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.¶