- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 7 Oct 2002 17:03:42 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
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