Subject: More questions on the IF header

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 19 Sep 2001 17:33:49 -0700

Geoff answered my previous question on the IF header and I have to agree
with him.  In my words, if you see two IF header tokens in the same parens
() you can OR them; otherwise you have to AND them.  So:
IF: (<locktoken1> [etag1])
--> if locktoken1 or etag1 matches the resourceURI

IF: (<locktoken1>) ([etag1])
--> if locktoken1 AND etag1 matches the resourceURI

When tagged tokens appear, it seems you can't combine two tokens with
different tags in the same parens.  So:
IF: <href1> (<locktoken1> [etag1]) <href2> (<locktoken2> [etag2])
--> if (href1 has locktoken1 OR href1 has etag1) AND (href2 has locktoken2
OR href2 has etag2)

Now I have a new question...

We know that when a collection with URL 'C/' is locked with depth infinity,
and a resource R is inside it or added to it, the resource R is somehow
'included' in the depth infinity lock.  Does that mean that the locktoken
created for the lock on C applies to R?  Or must the locktoken always be
associated with the exact URL for which it was created?

The language from section 9.4 is "If
   the state of the resource to which the header is applied does not
   match any of the specified state lists then the request MUST fail
   with a 412 (Precondition Failed).  "

So my question can be reworded as, does a child resource "match" the lock
token from a infinite-depth lock on a parent resource?

We know this will work, because it applies the lock token to the exact
resource for which it was created:
  PUT C/R
  If: <C/> (<locktoken-from-C>)

But must this succeed, or must it fail because the locktoken from C is
tagged to the "wrong" resource?
  PUT C/R
  If: <C/R> (<locktoken-from-C>)

And this?
  PUT C/R
  If: (<locktoken-from-C>)

lisa

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 20 Sep 2001 10:46:20 -0400

From: Lisa Dusseault [mailto:[email-masked]]

   with him.  In my words, if you see two IF header tokens in the same
parens

Actually, it's the other way round, i.e.:
 IF (token1 token2) (token3 token4)
is
 if (token1 AND token2) OR (token3 AND token4)

   When tagged tokens appear, it seems you can't combine two tokens with
   different tags in the same parens.  So:
   IF: <href1> (<locktoken1> [etag1]) <href2> (<locktoken2> [etag2])
   --> if (href1 has locktoken1 OR href1 has etag1) AND (href2 has
locktoken2
   OR href2 has etag2)

Yes, you tag lists, not tokens (but you need to swap AND and OR, i.e.

--> if (href1 has locktoken1 AND href1 has etag1) OR (href2 has locktoken2
    AND href2 has etag2)

   We know that when a collection with URL 'C/' is locked with depth
infinity,

This has been debated in a thread a while back, and as I recall, there
was weak consensus around saying that you can associate the locktoken
in the IF header with any URL that identifies a resource that is
affected by the lock, not just the URL to which the lock was applied.
Which means that:

     PUT C/R

   And this?
     PUT C/R
     If: (<locktoken-from-C>)

would succeed.

Cheers,
Geoff