Subject: Bindings and GULP again

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 18 Nov 2003 13:33:58 -0800

I've reviewed the text of GULP before, and asked what part of
it wasn't sufficiently covered by the language in RFC2518bis.
I believe I've already incorporated most of pre-5.4 GULP (that part which
didn't assume bindings) into RFC2518bis.  That said, here's the text
you point to:

  "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."

Well, a LOCK doesn't always create a new lock.

  "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."

The phrase "and if the resource is not locked by that lock" confuses
this paragraph.  I believe it can be removed.  It's also not clear
in this para. if "members of" is recursive.  "descendants" is the
word I've used to make it clear when we're talking about all members
recursively, not just direct children.

  "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."

In RFC2518bis, UNLOCK MUST be to a directly-locked URL.

  "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."

In RFC2518bis, a lock token is submitted if it appears anywhere
in the if header, I think.

  "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.  An internal member URI
  of a collection is considered to be modified if it is added,
  removed, or identifies a different resource."

  "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."

Finally, this stuff doesn't address what happens to the other 
bindings of a locked resource - if they now appear as locked, 
which I would assume.  This needs to be made clear in bindings,
not RFC2518bis.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Tuesday, November 18, 2003 1:17 PM
> To: Lisa Dusseault
> Cc: 'Wallmer, Martin'; 'Kevin Wiggen'; [email-masked]
> Subject: Re: SEARCH by last path segment, Was: SEARCH for displayname
> 
> 
> 
> Lisa Dusseault wrote:
> 
> > 
> >>>Why have an architectural principle that holds us back, if
> >>
> >>it doesn't
> >>
> >>>give us something in return?
> >>
> >>It does. For instance, it allows us to define how locks and multiple
> >>bindings interact in a logical way.
> > 
> > 
> > This is exactly what I'm looking to understand, that I 
> don't currently 
> > understand.  In fact, I thought that the interaction of locks and 
> > multiple bindings was problematic.  So how does this make them work 
> > together in a logical way?
> 
> Looking at the latest GULP 
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar
/0367.html>), 
it nicely explains how locks work without even mentioning them specifically.

Maybe you could re-read it and suggest what is unclear?

Regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Nov 2003 02:00:48 +0100

> it wasn't sufficiently covered by the language in RFC2518bis.

Well, the agreed upon plan was to actually add GULP to RFC2518bis once 
we've come up with a final version. At least that's the plan I remember.

> I believe I've already incorporated most of pre-5.4 GULP (that part which

GULP never "assumed" bindings. It was just using the term "binding". We 
have replaced it by "internal member", because in this context the terms 
are exchangeable.

> Well, a LOCK doesn't always create a new lock.

It does, unless this is a LOCK refresh. Ok.

> this paragraph.  I believe it can be removed.  It's also not clear

No, it's required, because only if the resource is not already directly 
locked by that lock, it becomes *indirectly* locked.

> recursively, not just direct children.

"members" and "internal members" is terminilogy defined in RFC2518, 
section 3.

> In RFC2518bis, UNLOCK MUST be to a directly-locked URL.

OK.

> in the if header, I think.

Speaking of which I don't think that we ever agreed on making this change.

> which I would assume.  This needs to be made clear in bindings,

1) No, the other URIs mapped to that resource are *not* affected. It's 
the *resource* that is locked.

2) And no (we discussed this before), this should be defined in 
RFC2518bis as both HTTP and WebDAV already allow multiple URIs being 
mapped to the same resource. All the BIND spec does is clarifying 
behaviour that was defined in RFC2518bis and added specific methods for 
explicitly creating those additional URI mappings.

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 19 Nov 2003 12:32:08 +0100

Am 18.11.2003 um 22:33 schrieb Lisa Dusseault:

> [...]
> [...]

I agree to that view on submitted lock-tokens. In this, GULP needs a
simplification.

It is advisable for clients to create If headers which are tagged with
the lock-root of the lock. However it is also valid to use the uri of
an indirect-lock resource in a If header. The lock-token should then
be regarded as submitted, too, otherwise modifications of the
resource would fail.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Nov 2003 11:49:21 +0100

> I agree to that view on submitted lock-tokens. In this, GULP needs a

Clarification: I confused "being submitted for LOCK evaluation" with the 
If header handling. So yes, GULP should state that a lock token is 
submitted when it appears in the If header at all.

However, this doesn't mean that for "If" header processing, lock tokens 
can be supplied un-tagged or with the wrong URI. I'm mentioning this 
because that would be a change from RFC2518, and I don't think we've 
reached consensus on that.

> ...

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 20 Nov 2003 12:31:36 -0800

> Stefan Eissing wrote:
> 
> >> In RFC2518bis, a lock token is submitted if it appears anywhere in 
> >> the if header, I think. [...]
> > 
> > 

No problem here, we all agree that lock tokens must be tagged with
the right URI (or untagged). Otherwise you'd get 412 Precondition 
Failed.  This hasn't changed in RFC2518bis, but if the language is
unclear I'm happy to take a look.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Nov 2003 21:58:22 +0100

> unclear I'm happy to take a look.

No, that's fine. I just confused changes that are useful and we agreed 
upon and others I *thought* went in that were still under discussion.

If this shows anything, it's that we better finish discussions, then 
resolve the issues and document it :-)

Julian