RE: GULP (version 4)

RE: GULP (version 4)Geoff,
yes, that's what I wanted. At least it seemed to me that we had agreed on
that.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
 -----Original Message-----
 From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
 Sent: Monday, October 07, 2002 3:32 PM
 To: 'Webdav WG'
 Subject: RE: GULP (version 4)
 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?
 Cheers,
 Geoff
 -----Original Message-----
 From: Julian Reschke [mailto:julian.reschke@gmx.de]
 Geoff,
 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)?
 Julian
 --
 <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
 -----Original Message-----
 From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
 Sent: Monday, October 07, 2002 2:51 PM
 To: 'Webdav WG'
 Subject: GULP (version 4)
 We are about to submit a new ID for the BIND extension, and as part of
 that work, we are verifying that locking semantics is clearly defined
 in the presence of multiple bindings to a single resource. The last
 time we were working on locking for the bind proposal (about 2.5 years
 ago :-), I submitted a series of GULPs (Grand Unified Locking
 Proposals), the last of which was V3:
 <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0061.html>.
 The most complex part of this proposal was capturing the semantics
 of lock-null resources (and was a significant factor in my crusade
 agains them :-). Happily, now that we have cleaned up locking by
 removing lock-null resources, we can also significantly simplify
 the description of write-lock semantics:
 **************************
 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.
 **************************
 If you have any locking use cases (no matter how obscure or unlikely)
 that are not properly covered by this proposal, please let me know.
 We're especially interested in obscure multiple binding use cases,
 such as cyclic bindings.
 Cheers,
 Geoff