Re: Bindings and GULP again

Geoffrey M Clemm wrote:

> There are a couple of ways to go here:
> (1) consider a lock token to be submitted if it is submitted with a
>     URL that is directly or indirectly locked by that lock token
> (2) consider a lock token to be submitted if it appears anywhere in
>     the If header, even if it only appears on a URL that is not in
>     fact locked by that lock.
> 
> Lisa's initial statement sounded like she was advocating the
> second approach, but her last statement sounds more like the
> first approach.  On the other hand, the last comment ("Otherwise
> you'd get a 412 Precondition Failed") is incorrect, since only
> one of the state lists need to match.
> 
> Either way is OK with me (although I'd probably have gone with
> the first approach myself), but I just wanted to verify what
> folks had in mind here.

I think the current spec 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-05.txt>) 
  assumes (2):

Quoting section 7.6:

    In order to prevent these collisions a lock token MUST be submitted
    by an authorized principal for all locked resources that a method
    may change or the method MUST fail.  A lock token is submitted when
    it appears in an If header.  For example, if a resource is to be
    moved and both the source and destination are locked then two lock
    tokens must be submitted in the if header, one for the source and
    the other for the destination.

I can live with that, but I'm not sure why this is better than requiring 
the token to appear with the right URL (when in a tagged list). Is this 
just a statement about current client behaviour, or a change compared to 
RFC2518?

Julian

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

Received on Tuesday, 30 December 2003 05:43:55 UTC