RE: Bindings and Locks (was: bind draft issues)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver
> Sent: Wednesday, March 05, 2003 2:34 AM
> To: WebDAV
> Subject: Re: Bindings and Locks (was: bind draft issues)
>
>
>
> On Tuesday, March 4, 2003, at 12:13  PM, Clemm, Geoff wrote:
> > The only argument for not doing so is that being more
> > specific probably requires including the entire GULP
> > document, since that is needed to clearly define the difference
> > between locking a resource and protecting a URL.
> > But I don't think we want to include that information by
> > copy in each protocol extension document, so I think it
> > is more appropriate to get it into 2518bis, and refer to
> > it from the other documents.
> >
> > Cheers,
> > Geoff
>
> Geoff,
>
> As GULP frequently defines things in terms of bindings,
> the text as-is seems more appropriate to the binding
> spec.

Strong disagreement. The way to "fix" this is either to add the term
"binding" to RFC2518, or to use the term "internal member" instead (which
*will* make the text harder to read). Let's see:

--

- 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 a binding (1) to a
  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 removing a binding (2) to the resource 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.

- 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 a binding (3) 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.

---

So,

(1) "binding to a resource" -> "internal member"
(2) "binding to the resource" -> "internal member URL identifying that
resource"
(3) "binding of a locked collection" -> "internal member URL in a locked
collection"

should be equivalent, just using RFC2518 terminology.

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 5 March 2003 03:31:01 UTC