When If headers with tagged lists fail

I thought that RFC2518 was clear that if the If header includes a  
tagged list with the wrong URL then the request should be failed with  
412.  I went looking for the explanation in the section on tagged  
lists, and it wasn't terribly clear.  It just tacitly "inherits" the  
definition from the untagged If header behavior.

So, what if I added a sentence to the description of tagged list  
production in the If header, as follows:

Text already there:
    The tagged-list production scopes a list production.  That is, it
    specifies that the lists following the resource specification only
    apply to the specified resource.  The scope of the resource
    production begins with the list production immediately following the
    resource production and ends with the next resource production, if
    any.  All clauses must be evaluated.

Text to add immediately after:
    If the state of the resource named in the tag does not
    match any of the associated state lists then the request MUST fail
    with a 412 (Precondition Failed).

Does this clear up the confusion?  Is it OK/clear to have this  
information in a different section of the spec from where it says "a  
lock token is submitted if it appears anywhere in the If header"?

Lisa

On Dec 30, 2003, at 2:43 AM, Julian Reschke wrote:

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

Received on Wednesday, 7 July 2004 19:14:27 UTC