Bindings and GULP again

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: www-webdav-dasl-request@w3.org 
> [mailto:www-webdav-dasl-request@w3.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 18, 2003 1:17 PM
> To: Lisa Dusseault
> Cc: 'Wallmer, Martin'; 'Kevin Wiggen'; www-webdav-dasl@w3.org
> 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

Received on Tuesday, 18 November 2003 16:34:19 UTC