Re: GULP (version 4)

Am Montag, 07.10.02, um 16:35 Uhr (Europe/Berlin) schrieb Clemm, Geoff:

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

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

> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
> 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:julian.reschke@gmx.de]
>
> 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.
> **************************
>

Received on Monday, 7 October 2002 11:04:38 UTC