Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Jun 2004 15:45:50 +0200

Julian Reschke wrote:

>> I just noticed that in
>>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
>>
>> we write...:
>>
>>   "An UNLOCK request deletes the lock with the specified lock token.
>>   The request-URL of the request MUST identify the resource that
>>   is directly locked by that lock.  After a lock is deleted,
>>   no resource is locked by that lock."
>>
>> This was a change to the previous GULP version. However, the 
>> discussion attached to issue entry UNLOCK_WHAT_URL 
>> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that 
>> we agreed upon allowing any URL protected by the lock to be used as 
>> request URL.
>>
>> 1) We should agree on one of the two; and fix the other document 
>> accordingly.
>>
>> 2) RFC2518 seems to allow both interpretations:
>>
>>    "The UNLOCK method removes the lock identified by the lock token
>>    in the Lock-Token request header from the Request-URI, and all
>>    other resources included in the lock."
>>
>> 3) Back when I tested this, both Apache/moddav and Xythos were 
>> implementing this, and so are we (I think). Microsoft IIS doesn't 
>> support deep locks, so it's not relevant here.
>>
>> Therefore it seems that we should undo that particular change from 
>> GULP 5.5 for the sake of interoperability with older clients that may 
>> rely on it (this seems to be harmless).
> 
> 
> Adding to the confusion, I just find out that RFC2518bis-05 says it 
> needs to be directly locked as well (well, I guess it *tries* to say 
> that, see... 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0115.html>).
> 
> Can we please make a decision *and* make sure that it's tracked on the 
> issues list? An issues list that is not only out of sync but even 
> contradicts the latest draft really doesn't help much :-)

OK,

here are some actual test results:

a) Apache/moddav: allows UNLOCK on indirectly locked resources,
b) Xythos: same,
c) SAP Enterprise Portal: same,
d) Microsoft IIS: no support for depth infinity locks.

Thus the current text in the issues resolution "Resolved that you can 
specify any URL locked by the lock you want to unlock" does indeed 
reflect current implementation experience, and this is what spec 
revisions should be saying.

Thus:

1) RFC2518bis should undo that change, and
2) GULP should be updated accordingly (I'll do that for my in-document 
copy of GULP at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C>.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 12 Jun 2004 13:34:25 -0400

I agree.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Jun 2004 11:27:30 +0200

> I agree.

ok,

below the new version...:

-------------- GULP (Version 5.7) --------------

- A lock either directly or indirectly locks a resource.

- 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 no content MUST be created by the request.

- 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 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.

- 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.

- A lock token is "submitted" in a request when it appears in an If
   header.

- 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.

- 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.

- If a request would cause a resource to be locked by two different
   exclusive locks, the request MUST fail.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Jun 2004 17:19:05 +0200

Julian Reschke wrote:

> ...
 > ...

Stefan (rightfully) points out that this should say "...with empty 
content...". "No content" might be interpreted as defining that a GET on 
that resource would return a 404, which is not what we want.

Is everybody ok with thst minor change?

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 14 Jun 2004 12:57:46 -0400

I agree with that fix.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Jun 2004 19:13:05 +0200

> I agree with that fix.

OK, here we go...:

-------------- GULP (Version 5.8) --------------

   resource with empty content MUST be created by the request.