RE: GULP (version 4)

GULP (version 4)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