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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 4 Mar 2003 15:13:44 -0500

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

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 1:41 PM
To: WebDAV
Subject: Re: Bindings and Locks (was: bind draft issues)

On Monday, March 3, 2003, at 01:35  PM, Jason Crawford wrote:
> I suppose that covers it.  Hopefully the reader understands the 
> situations
> that
> that covers.

I'd like to vote in favor of providing enough specificity
that the reader will understand the situations it covers.
Are there any good arguments for not doing so?

>
> One question though... does it have to be a write-lock?  I suspect
> this precondition even applies to non-write locks.
>
>
>
-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Tue, 4 Mar 2003 17:33:53 -0800

> it from the other documents.

Geoff,

As GULP frequently defines things in terms of bindings,
the text as-is seems more appropriate to the binding
spec.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 09:30:51 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Wednesday, March 05, 2003 2:34 AM
> To: WebDAV

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