Subject: RE: GULP (version 4)

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 7 Oct 2002 10:35:18 -0400

Either way is fine with me.  But note that I consider that to
be a marshalling detail of the UNLOCK request (since the server
will be maintaining the lock-root, why would it care?) ... the GULP
lock semantics should apply however we decide to marshall UNLOCK.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]

yes, that's what I wanted. At least it seemed to me that we had agreed on
that.

-----Original Message-----
From:  Clemm, Geoff

That is covered by the rule: 
- If a request would remove a lock from a resource, the request MUST 
  fail unless the lock-token for that lock is specified in the 
  request. 
So, yes, you can use /b is the request-URL for the UNLOCK, as long 
as you submit the lock-token for the lock. 
Did you want to require that the request-URL of the UNLOCK be /a? 

-----Original Message----- 
From: Julian Reschke [mailto:[email-masked]] 

maybe now it's *too* simple... 
I am missing rules that tell me which request URIs I can submit an UNLOCK
request to. 
For instance,  let /a and /b bindings to the same resource, which was
exclusively locked on the URI /a. Can I unlock /b (using the lock token I
get via DAV:lockdiscovery)?

-----Original Message----- 
From:  Clemm, Geoff 

************************** 
Grand Unified Lock Proposal (V4) 
- A lock is either direct or indirect. 
- A LOCK request places a direct lock on the resource identified by 
  the request-URL.  The "lock-root" of the new lock is the request-URL. 
- If a request causes a resource with a direct lock to no longer be 
  mapped to the lock-root of that lock, then that lock MUST be removed 
  from that resource. 
- If a collection has a direct depth:infinity lock with token X, all 
  members of that collection (other than the collection itself) will 
  have an indirect depth:infinity lock with token X.  In particular, 
  if a binding to a resource is added to a collection with a 
  depth:infinity lock with token X, and if the resource does not have 
  a lock with token X, then an indirect lock with token X is added to 
  the resource.  Conversely, if a resource has an indirect lock with 
  token X, and if the result of removing a binding to the resource is 
  that the resource is no longer a member of the collection with the 
  direct lock with token X, then the lock with token X is removed from 
  the resource. 
- If a request would modify the content, dead properties, or bindings 
  of a locked resource, the request MUST fail unless the lock-token 
  for that lock is specified in the request. 
- If a request would remove a lock from a resource, the request MUST 
  fail unless the lock-token for that lock is specified in the 
  request. 
- If a request would cause two different exclusive locks to appear on 
  the same resource, the request MUST fail. 
**************************

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 7 Oct 2002 17:03:42 +0200

> lock semantics should apply however we decide to marshall UNLOCK.

Unless shown any benefit in this restriction of UNLOCK, I favor that
the "correct" URI of the request does not matter. The primary
function is to unlock the resource, not the URI.

//Stefan

> yes, that's what I wanted. At least it seemed to me that we had agreed 
> on that.
>
>
> I am missing rules that tell me which request URIs I can submit an 
> UNLOCK request to.
> exclusively locked on the URI /a. Can I unlock /b (using the lock 
> token I get via DAV:lockdiscovery)?
>