The identifier is a name for the issue (and is unique within this document).
The type of issue is one of:
The status of the issue is one of:
The reference is an indication of where the issue was first raised.
The description is a succinct overview of the issue.
The resolution describes the specification change that resolves the issue.
| Identifier | Type / Status | Reference and Description | Proposed Resolution / Latest Change |
|---|---|---|---|
| 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL |
change 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.
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. |
latest change in revision latest |
| 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION |
change open |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html> ccjason@us.ibm.com: What resource should be flagged in the multistatus response to locking issues in COPY/MOVE requests? |
latest change in revision latest 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. |
| 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION |
change open |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html> 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. |
latest change in revision latest |
| edit |
edit open |
julian.reschke@greenbytes.de, 2004-05-25: Umbrella issue for editorial fixes/enhancements. | latest change in revision latest |
| safeness_and_idempotence |
edit open |
julian.reschke@greenbytes.de, 2005-03-02: Specify safeness and idempotence of LOCK and UNLOCK methods. | latest change in revision latest |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| 008_URI_URL |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0142.html> 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-22: 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. Use "(internal) member URI" when talking about collection membership (term is defined IN RFC2518). Otherwise use URI, making sure that if a relativeURI (as defined by RFC2396) is allowed, we say so. |
in revision 04: 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. Closed for now with the changes proposes by Julian R. |
| 015_MOVE_SECTION_6.4.1_TO_APPX |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html> 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. |
in revision 04: (1) Moved to appendix. (2) UUID URNs aren't ready; delay this to future revisions. |
| 022_COPY_OVERWRITE_LOCK_NULL |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0244.html> jdavis@parc.xerox.com, 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. |
in revision 01: See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC |
| 025_LOCK_REFRESH_BY_METHODS |
change closed |
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? | in revision 01: We should remove the mention of this behavior in 2518: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0137.html |
| 037_DEEP_LOCK_ERROR_STATUS |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html> wiggs@wiggenout.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. julian.reschke@greenbytes.de, 2004-04-24: Comment: 207 is correct, fix the bad spec text. |
in revision 01: Done. |
| 039_MISSING_LOCK_TOKEN |
change closed |
Reference: <http://dav.lyra.org/pipermail/dav-dev/1999-June/000277.html> 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. |
in revision 01: Make obvious editing changes to the examples: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0229.html Note that this only applies to the example for a successful lock creation, not for refreshes. |
| 040_LOCK_ISSUES |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> ccjason@us.ibm.com, 1999-06-07: Jason Crawford's list of lock issues sent to the list. |
in revision 00: Replace with list of distinct issues 040_LOCK_ISSUES_??. |
| 040_LOCK_ISSUES_01 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> ccjason@us.ibm.com, 1999-06-07: 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. |
in revision 01: Agreed, use "submitting". |
| 040_LOCK_ISSUES_02 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> ccjason@us.ibm.com, 1999-06-07: 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. :-) julian.reschke@greenbytes.de, 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. |
in revision 01: No change. |
| 040_LOCK_ISSUES_03 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> 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. |
in revision 03: |
| 040_LOCK_ISSUES_04 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> 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 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. |
in revision 03: Clarify that this only applies to the attempt to depth-infinity lock the collection. |
| 040_LOCK_ISSUES_05 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> ccjason@us.ibm.com, 1999-06-07: 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. |
in revision 01: No change: LOCKs are lost then the locked resource is moved. Will also be clearer once GULP is incorporated. |
| 040_LOCK_ISSUES_06 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> 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. |
in revision 05: Resolved after cleaning up error marshalling descriptions and rewriting the statement about UNLOCK and status 204. |
| 040_LOCK_ISSUES_07 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> ccjason@us.ibm.com, 1999-06-07: 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? 9.4.1.1 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. |
in revision 01: This issue needs to be handled in the base protocol. |
| 040_LOCK_ISSUES_08 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html> 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. |
in revision 03: |
| 043_NULL_LOCK_SLASH_URL |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html> wiggs@xythos.com, 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. |
in revision 01: See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC |
| 044_REPORT_OTHER_RESOURCE_LOCKED |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html> 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. |
in revision 04: |
| 052_LOCK_BODY_SHOULD_BE_MUST |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0224.html> gstein@lyra.org, 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. julian.reschke@greenbytes.de, 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. |
in revision 02: Clarify that LOCK refresh MUST NOT have a request body. Also clarify Lock-Token header vs If header. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0124.html. |
| 053_LOCK_INHERITANCE |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0250.html> 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. |
in revision 03: Agreed; make that change. |
| 054_IF_AND_AUTH |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0211.html> geoffrey.clemm@rational.com, 2000-01-27: The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document. julian.reschke@greenbytes.de, 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. |
in revision 02: Duplicate of 057_LOCK_SEMANTICS. |
| 056_DEPTH_LOCK_AND_IF |
change closed |
Reference: <http://dav.lyra.org/pipermail/dav-dev/2000-March/000830.html> 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-06-19: See http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0194.html: existing servers accept both. This is consistent with the concept of "if it appears in the If header, it's submitted". We still need to say something about lock state token evaluation in the If header, though. |
in revision 04: Closed. See issue 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL for the question of how lock tokens are evaluated in the If header. |
| 057_LOCK_SEMANTICS |
change closed |
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. | in revision 03: 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. |
| 058_LOCK_SEIZURE |
change 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. | in revision 00: Duplicated by UNLOCK_BY_NON_LOCK_OWNER issue. |
| 060_LOCK_REFRESH_BODY |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html> rickard.falk@excosoft.se, 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. |
in revision 02: Clarify that LOCK refresh MUST NOT have a request body. Also clarify Lock-Token header vs If header. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0124.html. |
| 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY |
change closed |
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. |
in revision 05: Do not change existing RFC2518 semantics now. See discussion around http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0047.html. |
| 065_UNLOCK_WHAT_URL |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0086.html> 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. |
in revision 03: 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. |
| 067_UNLOCK_NEEDS_IF_HEADER |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html> 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) |
in revision 03: 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. |
| 068_UNLOCK_WITHOUT_GOOD_TOKEN |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html> 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). |
in revision 03: 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 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0180.html |
| 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0109.html> 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. |
in revision 02: Rejected. See also 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY |
| 072_LOCK_URL_WITH_NO_PARENT_COLLECTION |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0134.html> 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. |
in revision 04: 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. See DAV:parent-resource-must-be-non-null precondition. |
| 073_LOCKDISCOVERY_ON_UNLOCKED_RESOURCE |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0128.html> 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. julian.reschke@greenbytes.de, 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. |
in revision 01: Added example. |
| 077_LOCK_NULL_STATUS_CREATION |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0267.html> lisa@xythos.com: 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). |
in revision 01: 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. See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC |
| 079_UNLOCK_BY_NON_LOCK_OWNER |
change closed |
lisa@xythos.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? | in revision 02: 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. |
| 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC |
change closed |
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. | in revision 01: 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. Closes 022_COPY_OVERWRITE_LOCK_NULL, 043_NULL_LOCK_SLASH_URL, 077_LOCK_NULL_STATUS_CREATION. |
| 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED |
change closed |
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. | in revision 05: Resolved by repeated statement and no disagreement. |
| 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0047.html> gclemm@rational.com: 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. |
in revision 01: Proposed solution: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html approved. See also 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK |
| 093_HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0127.html> dbrotsky@adobe.com: How does a client determine if a given lock was created by it? |
in revision 00: 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. |
| 096_SHARED_LOCKS_INTEROP_NOT_TESTED |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0165.html> lisa@xythos.com: There might not be any implementations of shared locks. If so, remove them. |
in revision 00: 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. |
| 101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0215.html> julian.reschke@greenbytes.de: 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. |
in revision 01: Resolved trivially that it's probably worthwhile to demonstrate a correct response for this situation in one of the examples. |
| 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html> julian.reschke@greenbytes.de: 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? |
in revision 01: Resolved to support a dav:lockroot element in the lock discovery property: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html See 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK |
| 111_MULTIPLE_TOKENS_PER_LOCK |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0050.html> julian.reschke@greenbytes.de: 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? |
in revision 01: 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. |
| 3.2_lockdiscovery_depth |
edit closed |
julian.reschke@greenbytes.de, 2004-06-19: "depth" can never have the value "1". | in revision 04: Fixed. |
| 5.2.1-depth_header_vs_lock_refresh |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0300.html> stanley.guan@oracle.com, 2003-12-18: Under the topic of "Refreshing Locks", it hints that Client may include a Timeout header. But, Depth header has not being mentioned. Under the topic of "Depth and Locking", it discussed what will happen if "Depth" header is specified for creating a new lock. But, nothing was mentioned on what's its implication on a lock refreshing command. |
in revision 06: Clarify that servers MUST ignore the Depth header upon LOCK refresh. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0059.html. |
| 7.5_DELETE_vs_URIs |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0174.html> 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." |
in revision 03: Done. |
| 8.10.1_lockdiscovery_on_failure |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0147.html> julian.reschke@greenbytes.de, 2004-06-04: Returning DAV:lockdiscovery on error seems to be (a) useless and (b) underspecified (the example given in section 8.10.10 isn't compliant to the multstatus response format). |
in revision 02: Specify returning DAV:lockdiscovery just upon success. Fix example (will use precondition names when they are defined). |
| abnf |
change closed |
julian.reschke@greenbytes.de, 2005-02-12: Clarify BNF syntax (Notation, and when used). | in revision 07: Done. |
| D_delegate_UUID_definition |
change closed |
julian.reschke@greenbytes.de, 2005-01-30: Delegate the definition of UUIDs to draft-mealling-uuid-urn. | in revision 07: Done. See also http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0187.html. |
| extract-locking |
change closed |
julian.reschke@greenbytes.de, 2004-04-14: Locking extracted from RFC2518. | in revision 01: Finished as of draft 00. |
| import-gulp |
change closed |
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. | in revision 08: Integrate GULP as is, let remaining text refer to it where appropriate. Also add pointers from GULP back into the main document. Rename section to "Collected Method Semantics. |
| import-rfc3253-stuff |
change closed |
julian.reschke@greenbytes.de, 2004-04-25: Import error marshalling and terminology from RFC3253. | in revision 04: Done. |
| lock_state_auth_principal |
change closed |
julian.reschke@greenbytes.de, 2005-02-13: Mention the principal that was authenticated when the lock was created as part of the state of a lock; disambiguate with what previously was called "lock owner". | in revision 07: Done. |
| rfc2396bis |
edit closed |
julian.reschke@greenbytes.de, 2004-12-04: Update references to RFC2396 with draft-fielding-uri-rfc2396bis-07. | in revision 06: Done. |
| rfc2606-compliance |
editor closed |
julian.reschke@greenbytes.de, 2004-05-23: Ensure that examples use only sample domains as per RFC2606. | in revision 01: Done. |
| updated-rfc2068 |
change closed |
julian.reschke@greenbytes.de, 2004-04-25: Update references of RFC2068 to either RFC2396 or RFC2616. | in revision 01: Done. |
| uri_draft_ref |
edit closed |
julian.reschke@greenbytes.de, 2005-01-01: Fix reference to draft-fielding-uri-rfc2396bis-07. | in revision 07: Update to RFC3986. |
| Version | Issues |
|---|---|
| latest | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 06 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 05 | ||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 04 | ||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 03 | |||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 02 | ||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 01 | |||||||||||||||||||||||||||||||||||||||||||||||||| |
| 00 | ||||||||||||||||||||||||||||||||||||||||||||||| |
Last change: 2005-05-16