Re: Bindings and GULP again

Lisa Dusseault wrote:

> I've reviewed the text of GULP before, and asked what part of
> 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.

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

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

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

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

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

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

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

OK.

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

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

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

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

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

Received on Tuesday, 18 November 2003 20:01:34 UTC