RE: GULP vs RFC2518bis

GULP changes the way the If header works in a fairly way in all the
proposed wordings I've seen. Some of the recent discussion:

>    > This doesn't mention untagged-list syntax in If header.  
> Is a corollary
>    > of this proposal that we remove the untagged-list 
> syntax? Or was the
>    > omission of untagged-list accidental?  I'd prefer to 
> keep the untagged
>    > list syntax, so I believe this should read:
>    >  "A lock token is "submitted" in a request when it 
> appears in an If
>    >   header."
> 
>    I'd prefer
> 
>    "when it appears in an If header tagged-list whose tag is 
> the lock-root
> of
>    the lock, or if it appears in an untagged list and the 
> request-URL is the
>    lock-root of the lock".
> 
> I agree this change should be made, and I prefer Julian's 
> rewording, as
> it is more precise.  I'll post a new version of GULP with this change.
> 

This changes the way the If header is parsed. It means the client can't
submit an untagged token list without matching the lock-root of the
token against the Request-URI. That's not how the If header worked
before.

I'll give an example of what should work today, and what GULP forbids.
Let's say I want to DELETE an unlocked  collection, and in that
collection are two independently locked descendants. The descendants
have these two Etags:

<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6> and 
<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>

The following request should allow the lock tokens to match and the
server should accept both tokens, because they are in an OR list:

DELETE /tld/ HTTP/1.1
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6>)
	(<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>) 

I don't want to change this behaviour, because it's a very convenient
way for a client to provide a bunch of lock tokens in exactly the
situation of deleting  or moving a collection with locked descendants. 

Lisa

Received on Tuesday, 11 March 2003 11:19:12 UTC