GULP (version 5.3)

The changes from version 5.2 are:
- replacing the term "binding" with the term "internal member URI", and
- handling untagged-list If headers.
This handles all issues raised so far with adding GULP to 2518bis
(except for the UNLOCK_WHAT_URL which will be pursued independently).

Cheers,
Geoff

--------------

- A lock either directly or indirectly locks a resource.

- A LOCK request creates a new lock, and the resource identified
  by the request-URL is directly locked by that lock.  The
  "lock-root" of the new lock is the request-URL. If at the time of
  the request, the request-URL is not mapped to a resource, a new
  resource with no content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
  members of that collection (other than the collection itself) are
  indirectly locked by that lock.  In particular, if an internal
  member resource is added to a collection that is locked by a
  depth:infinity lock, and if the resource is not locked by that lock,
  then the resource becomes indirectly locked by that lock.
  Conversely, if a resource is indirectly locked with a depth:infinity
  lock, and if the result of deleting an internal member URI is that
  the resource is no longer a member of the collection that is
  directly locked by that lock, then the resource is no longer locked
  by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock, or when
  it appears in an untagged list and the request-URL is the lock-root
  of the lock.

- If a request would modify the content for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or an internal member URI of a
  locked collection, the request MUST fail unless the lock-token for
  that lock is submitted in the request.

- If a request causes a directly locked resource to no longer be
  mapped to the lock-root of that lock, then the request MUST
  fail unless the lock-token for that lock is submitted in the
  request.  If the request succeeds, then that lock MUST have been
  deleted by that request.

- If a request would cause a resource to be locked by two different
  exclusive locks, the request MUST fail.

--------------

Received on Sunday, 9 March 2003 14:26:36 UTC