Subject: Re: Interop issue: Proposal for fixing lock token provision

From: Jason Crawford <[email-masked]>
Date: Wed, 2 Oct 2002 11:12:12 -0400

<<
I read three proposals:
1. more clearly define the If header and its scope.
2. Introduce an additional request header for relaxed lock
    checking. The client says: " this is the bag of lock tokens
   I have, server, take your pick."
3. Introduce an additional response header where the server
   can indicated which token from the bag are no longer valid.

I am all for (1).
Good :-)

<<
Regarding (2) and (3) I argued that, as we still need the If header, is
it really worth it to add a new header with related semantics?
I wasn't really talking about (3).  I was planning to cover that in
a seperate thread.   I don't want to tie (3) to the issue of (2).  (3)
is an optimization that only becomes realistic if you have (2).   If
people didn't accept (2), there is no point in talking about (3).

Regarding "related semantics"... one of my points is that their semantics
would not be related.  Each header would work independently
of the other and the functions that each would perform would not overlap
the functionality of the other.  I think this would be important to
make sure the spec is clear and simple.

<<
If I understand you correctly, you seem to extend Lisa's original
proposal. Do you think 2518bis should remove lock tokens
from the If header completely?
I propose that lock tokens remain in If: headers.  The If: header would
continue to be a list
of assertions by the client that must be true before the server performs
the request.  Those assertions
could continue to mention etag and also lock tokens.    None of that would
change, but...

The spec speaks of the need for a client to "submit" a lock-token to be
able to do
operations on a resource that is locked.   That is a good thing, but I
propose (2a) that
the mentioning of a lock-token in an If: header not be considered a
"submission" of a
lock token.  There would be a seperate header whose only purpose is to
allow the client
to submit lock tokens to satisfy the server's need to make sure that only
the principal
that holds the lock can operate on a locked resource.

I also propose, (2b) that we not *require* that a client check if a lock is
on a resource (with the
If: header) when submitting the token with the new header.   But we can
*recommend* it
for compatibility reasons and because in many situations it's the only way
a client can
be certain that there is no lost-update situation on that resource.

That is a simplified explanation.  The original proposal (2) above mentions
relaxed lock
checking on that new header.   I support that and can make a small case for
that, but I
realize others might not support that.  I could also accept a situation
where the new
header doesn't just list a bag of tokens but also says something about the
location of
those locks.  If we have to do that, my only request on that point is that
we be very clear
and thoughtful about how we specify that.  If we can't specify that clearly
and thoughtfully,
then I prefer we use the "bag of tokens" approach.  I find that approach
acceptable
because in most cases the client has plenty of motivation to use the If:
header to check
if the lock is still there.  If they are going to check that anyway, I
don't see a lot of point
in complicating the definition of the new header.

Another thing I'd like to propose is that the paragraph I mentioned about
the server
only checking the If: clauses that it wanted to check be removed.  If not
now, then later.
That paragraph limits the possible use of the If: header.   Anyway... I
don't want to talk
about this much.   It's just another improvement that becomes possible if
we do move
lock token submission to a new header.

I hope this is clearer.

J.

------------------------------------------
Phone: 914-784-7569

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 7 Oct 2002 10:25:36 -0400

I continue to be strongly against splitting the If header
functionality, primarily to maintain interoperability between new
clients and old servers, and between old clients and new servers.

Any new client that sends just the new header, without also sending
the same information in the If header, will fail against all old
servers.  A client could put in logic to send the new header to new
servers and the If header to old servers, but then you've just
increased the interoperation complexity of clients, not decreased it.

Similarly, any new server that only accepts the lock token list from
the new header, and not from the If header, will fail against all old
clients.  A server could put in logic to handle both the old and the
new headers, but again, you've just increased the interoperation
complexity of servers, not decreased it.

There is another question, which is that even if we leave the
semantics of the If header alone (to maintain interoperability between
new clients and old servers, and old clients and new servers), should
we introduce a new header that gives the client the ability to submit
a no longer valid lock token, and still have the request succeed.

I am against the addition of this new header, because I believe the
arguments in favor of it confuse the purpose of a lock and the purpose
of an etag.  An etag prevents lost updates.  You will be notified if
you are about to overwrite some other user's update, but you are then
left with a merge situation.  A lock prevents merge situations (and
thereby also prevents lost updates).  If you only care about lost
updates, then you can just use etags.  The only reason to use locks is
if: (1) you want to prevent merge situations, or (2) the resource
supports locks but not etags.  In either case, you always need to know
about lost locks because in case (1), you are no longer protected
against merge situations, or in case (2), you no longer are protected
against lost updates.

As a general principle, I believe that unless there is no alternative,
we should do all we can to reward implementors that have fully and
correctly implemented the specification, by maximizing the likelihood
that new clients and new servers will interoperate successfully with
those correctly and fully implemented old clients and servers.
Therefore, I believe that the use of the If header should be clarified
in RFC2518 bis (and in particular, guidance for how to use it to
submit lock tokens), but that the If semantics should remain
unchanged, and a new header which allows the submission of invalid
lock tokens should not be added.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Friday, October 04, 2002 7:06 PM
To: Lisa Dusseault
Cc: 'Stefan Eissing'; 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock token provision

We need to hear more from folks.  Things have been unusually quiet on this
subject.

Jason and Lisa have spoken up in favor of splitting the functionality.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html (and
previous postings)
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html

Stefan has spoken against it before that time, but it is unclear if he
understood the
proposal.  Hopefully the proposal is clearer now.

Let's hear from you folks...

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 7 Oct 2002 11:24:35 -0400

From: Clemm, Geoff [mailto:[email-masked]]

   ...
   Therefore, I believe that the use of the If header should be
   clarified in RFC2518 bis (and in particular, guidance for how to
   use it to submit lock tokens), but that the If semantics should
   remain unchanged, and a new header which allows the submission of
   invalid lock tokens should not be added.

As an example of clarifying how to use the If header to
submit lock tokens, we could say:

"When submitting multiple lock tokens, clients SHOULD use
the tagged-list production of the If header".

Cheers,
Geoff

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 8 Oct 2002 09:08:18 -0400

> clients and old servers, and between old clients and new servers.

   I hope my posting to Stefan's note addressed this for you.

Actually, it further convinced me that attempting to maintain
interoperability between old/new client/server with the new header
would be unacceptably complex, compared to just saying "use
tagged-list in the If header".

   An earlier posting already indicated a case where that was
   inefficient and suggested that because the client knows when this
   is appropriate and has plenty of motivation to check it, we don't
   need to specify that the server check this without being prompted
   by the client.

If one really feels this optimization is needed, then one could add an
"Ignore-Expired-Lock" header, without causing the interoperability
issues that result from splitting the header.  But like Julian, I
believe that one would be optimizing an uncommon case, and that it is
not worth doing so unless there is compelling evidence that this is a
significant performance issue.

   I hope my posting on compatibility covered that for you.  Old and
   new would continue to interoperate and new would perform better
   than old.

I believe the complexity of the solution you described would 
significantly decrease the interoperability between old and
new implementations.

   > invalid lock tokens should not be added.

   It's more than reasonable to come up with an alternate proposal
   though.  It sounds like we're trying to do that now.  We'll see how
   that goes.

In particular, the alternate proposal I'd like to offer is:

"A client MUST submit lock tokens in a tagged-list If header,
with the lock-root of the lock as the tag".

If line length is a problem, we would supplement that by allowing
a client to submit multiple If headers, and allowing "," as a
separator between If productions.

Cheers,
Geoff

---

From: Jason Crawford <[email-masked]>
Date: Tue, 8 Oct 2002 10:16:39 -0400

On Monday, 10/07/2002 at 02:14 AST, "Clemm, Geoff"
<[email-masked]> wrote:
> Alternatively, we could just say:
>
> "A client MUST submit a tagged-list If header, using the
> DAV:lock-root of the lock as the tag for that lock token."
>
> A simple rule for new clients, that will interoperate with
> all correctly implemented old and new servers.
>
> If any of the tagged-list productions fail, the resource
> that is no longer locked will be indicated with a 412 in
> the multistatus return, telling the client to either remove
> that lock from its table, or request a new lock for that
> resource.

And ALL tag list productions would be evaluated, so that
even if the server didn't think it was relevant, it still would be
checked.    So for example I can do a GET on a resource
with an IF: header and the IF: header would be checked despite
the server thinking it is unnecessary to check for locks on a
GET request.    Does this sound fine?

And the client is required to submit a tag list for every URL/resource
that the server thinks is relevant in order to submit the token.
And we're going to have to define what URL's are relevant.  And
define what constitutes submission.

So for a situation where a token needs to be submitted to allow a
protected URL from being broken (lock destroyed), the root URL of the lock
in
question needs to be submitted.

And in a situation where a token is needed to allow a write locked
resource to be modified, the URL of the root of that resource needs
to be specified.

And what is "modifying"? A PUT/PROPPATCH to an ordinary
resouce modifies it.   Also operations that add or remove children
of a collection are considered to modify the collection.

The client is free to test any other resources it wants to test beyond the
one's the server requires.

We need a spec'ing of what tag list entries are sufficient to be considered
a submission.   That has to deal with NOT  and any other expression
constructs we might come up with.

BTW... yes, I know earlier tonight I said that it's okay to test against
any resource locked by a resource in order to submit the lock, but
I'm guessing the definition of "submit" will be easier if we are as
specific as possible about what it means to submit a token and
specifying what URL is definitely something that will help.

Also, in the case of 2518-style DELETE where lots of bindings
get destoryed and they probably get destroyed bottom up, I'd think
it would be best (or at least equal) in some server implementations
if the URL you specified for the submisssion was the one that got
destoryed last.

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 8 Oct 2002 14:12:36 -0400

Jason pointed out to me in some private email that the questions in
his last posting were not rhetorical questions advocating one proposal
or another, but rather real questions that he thought we need to
answer.  I'd like to apologize to Jason for misreading his message,
and try to answer them properly this time.

   > that lock from its table, or request a new lock for that 

   And ALL tag list productions would be evaluated, so that even if 
   the server didn't think it was relevant, it still would be checked. 
   So for example I can do a GET on a resource with an IF: header and 
   the IF: header would be checked despite the server thinking it is 
   unnecessary to check for locks on a GET request.  Does this sound 
   fine? 

If a server knows that no condition specifiable in an If can cause a
GET to fail, then it can skip the If check.  But if it is not
absolutely sure, then yes, it has to check the If header.

   And the client is required to submit a tag list for every
   URL/resource that the server thinks is relevant in order to submit
   the token.  And we're going to have to define what URL's are
   relevant.

Whether we can define what URLs are relevant will depend somewhat on
whether we can get server consensus on that question.  We may need to
have a few "MAY depend" clauses.  But optimally, we can avoid that
and make everything a MUST.

   And define what constitutes submission.

Yes, we definitely have to clearly define what constitutes submission.

   So for a situation where a token needs to be submitted to allow a 
   protected URL from being broken (lock destroyed), the root URL of 
   the lock in question needs to be submitted. 

Yes.  (I assume you meant "to be broken" rather than "from being broken").

Yes.  We have been discussing whether to make a special case for the
UNLOCK request, but this may end up being decided more on
interoperability grounds (i.e. if existing servers require the
request-URL to be the lock-root, then for interoperability, we should
at least advise clients that they should use the lock-root for
interoperability).

   resouce modifies it.

Yes, in this case, I think we can clearly state that only the
lock on the resource specified by the request-URL must be
submitted.

   Also operations that add or remove children 
   of a collection are considered to modify the collection. 

To add a child, you would have to submit tokens for any locks
on the collection.  To remove a child you would have to submit
tokens for any locks on the collection, any locks on the child 
being removed, and if the child is a collection, any locks on
any member of the child collection.

   The client is free to test any other resources it wants to test 
   beyond the one's the server requires. 

Yes.

   We need a spec'ing of what tag list entries are sufficient to be 
   considered a submission.  That has to deal with NOT and any other 
   expression constructs we might come up with. 

I think it is simplest to just state that the appearance of the lock
token anywhere in the tagged list for the resource is sufficient.

   BTW... yes, I know earlier tonight I said that it's okay to test 
   against any resource locked by a resource in order to submit the 
   lock, but I'm guessing the definition of "submit" will be easier if 
   we are as specific as possible about what it means to submit a 
   token and specifying what URL is definitely something that will 
   help. 

I agree.

   Also, in the case of 2518-style DELETE where lots of bindings get 
   destoryed and they probably get destroyed bottom up, I'd think it 
   would be best (or at least equal) in some server implementations if 
   the URL you specified for the submisssion was the one that got 
   destoryed last. 

This raises a good (although tangential) point.
The BIND protocol "clarifies" the 2518 DELETE semantics, to 
state that it is the "mappings" to all the members that are 
removed by the DELETE of a collection, not the bindings. 
I believe this clarification should appear in 2518bis. 

But even if some (misguided :-) server did destroy all the 
bindings, the last one destroyed will be the lock-root, so
I think we're OK here to require that the lock-root be the
tag for the submitted token.

Cheers, 
Geoff

---

From: Jason Crawford <[email-masked]>
Date: Wed, 9 Oct 2002 02:42:28 -0400

> absolutely sure, then yes, it has to check the If header. 

I don't understand that answer.  It sounds like you're saying
that it's up to the server to decide what clauses should be 
checked.   Could you explain more?

> and make everything a MUST. 

OK.  Sounds right to me.

> Yes.  (I assume you meant "to be broken" rather than "from being 
broken"). 
Yes, that's what I meant.

> at least advise clients that they should use the lock-root for 

BTW... I meant the URL of the root of the *lock*.  :-)

Sounds fair enough.  We aren't using the If: header of UNLOCK now anyway
and this discussion is about the If: header.

> lock on the resource specified by the request-URL must be 

The request URL?   I guess that's okay.  I had actually proposed
the root of the lock rather than the request  URL.  I think lower
in this note you also said it should be the root of the lock.

> any member of the child collection. 

Sounds right.

>    beyond the one's the server requires. 

Okay, but you should clarify what you said near the top of this note 
because it
sounded to me like you said the server might not 
evaluate the assertions for some resources specified in the
If: header.

> token anywhere in the tagged list for the resource is sufficient. 

And what do we have to say anything about  NOT in an IF: header
or does that work out? 

> I believe this clarification should appear in 2518bis. 

You might want to say more about this in a newly named thread.
It will be lost in this thread. :-)  (I'd start the thread but I don't 
want to
misstate what you just tried to say. )

> tag for the submitted token. 

Okay... but I think a few paragraphs ago you suggested it
be on the request URI.  Do you want to alter that statement
when you reply?

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 9 Oct 2002 08:28:40 -0400

>    And ALL tag list productions would be evaluated, so that even
   >    if the server didn't think it was relevant, it still would be
   >    checked.  So for example I can do a GET on a resource with an
   >    IF: header and the IF: header would be checked despite the
   >    server thinking it is unnecessary to check for locks on a GET
   >    request.  Does this sound fine?
   > 
   > If a server knows that no condition specifiable in an If can
   > cause a GET to fail, then it can skip the If check.  But if it is
   > not absolutely sure, then yes, it has to check the If header.

My answer was poorly worded.  I meant to say that if the server can
tell just by scanning the If header that it doesn't apply to the GET,
then it can skip the If header.  For example, if the If is a tagged
list, and the tag did not identify the request-URL, since a GET only
applies to the request-URL, it can ignore that If header.

   > lock on the resource specified by the request-URL must be 

   The request URL?  I guess that's okay.  I had actually proposed the
   root of the lock rather than the request URL.  I think lower in
   this note you also said it should be the root of the lock.

Parsing problem (:-).  I meant: "the lock on (the resource specified by
the request-URL) must be submitted", not "(the lock on the resource)
specified by the request-URL must be submitted".

So yes, to address some interoperability problems that have been
reported, the proposal is to require that the tag in the If header be
the lock-root of the lock.

   >    beyond the one's the server requires. 

   Okay, but you should clarify what you said near the top of this
   note because it sounded to me like you said the server might not
   evaluate the assertions for some resources specified in the If:
   header.

I meant that it might be sufficient for the server to just
parse the If: header, and not actually evaluate them against
any resources.

   >    We need a spec'ing of what tag list entries are sufficient to
   >    be considered a submission.  That has to deal with NOT and any
   >    other expression constructs we might come up with.
   > 
   > I think it is simplest to just state that the appearance of the
   > lock token anywhere in the tagged list for the resource is
   > sufficient.

I could go either way, but I'd probably be inclined to not say
anything special about the NOT.  This means that putting a NOT
around a lock token is guaranteed to fail (i.e. because either it
is locked with that token, so the NOT fails, or it is not locked
with that token, so it is an invalid lock token, and it fails).
Alternatively, we could say that it is only a submission of the
lock token if it does not appear in a NOT, but all that buys the
client is the ability to have a request succeed only if the
resource is not locked by a particular lock token, which seems
like a pretty pointless semantics to support.  But I'm happy 
to do it either way.

   > I believe this clarification should appear in 2518bis. 

   You might want to say more about this in a newly named thread.  It
   will be lost in this thread. :-) (I'd start the thread but I don't
   want to misstate what you just tried to say. )

Good point.  Will do.

I'll keep the statement but clarify the parsing of the earlier
paragraph (:-).

Cheers,
Geoff

---

From: Jason Crawford <[email-masked]>
Date: Thu, 10 Oct 2002 00:26:46 -0400

> applies to the request-URL, it can ignore that If header. 

Wow.  I wouldn't have expected this as an answer.  It sounds
like the purpose of the If: header becomes for the server to
verify what it wants to.  That seems 
like a signficant change in philosophy from 2518.  2518 seems
to spend a lot of time talking about If: header and all it's
details but not about how it's used to submit lock tokens.  It's use
for lock token submission seems to simply be an afterthought.  It even
says the following when  it begins to talk about the If; header.

   The If header is intended to have similar functionality to the If-
   Match header defined in section 14.24 of [RFC2616].  However the If 
   header is intended for use with any URI which represents state 
   information, referred to as a state token, about a resource as well 
   as ETags.  A typical example of a state token is a lock token, and 
   lock tokens are the only state tokens defined in this specification. 

And I've taken this opening statement, and the fact that it never talks
about lock token submission in this section, to mean that the primary 
purpose of the If: header was for a client to verify various aspects
of server state (like If-Match) before doing an operation.  I'm not saying
that you're wrong to want to specify what you just have, but it seems 
to me that you are suggesting is a change in purpose/philosophy
because the client can no longer really fully use it for verifying
server state.    I want to bring
attention to that to be sure that's what you really want.

I'm going to stray a bit and say a bit about 2518 and say what I've
said above in a different way...

Above I outlined what I thought the *primary* purpose of the If:
header was in 2518.   But there are stray comments in the 2518
that make the If; header's purpose confused.  We've fixed one
of those in 2518bis.  But 2518bis still has the statement that the
server will only check the assertions on the URL's it chooses.
With that statement, the semantics and purpose of the If; header 
gets confusing.   It's like the server saying, 
   "you can ask me questions, but I'll only answer the one's 
   I want, and I'll only cooperate with your request if you ask 
   all the questions I want you to ask me."
It (2518) just doesn't make sense.  It makes it hard for us
and readers to figure out how to fill in gaps in the spec.  There
is no guiding philosophy and purpose.  It's difficult to build on 
that.

The proposal by Lisa and the interop folks, which I tried to
clearly guess at and describe, does fix this.  It provides
a clear purpose and semantics for the headers.  And it does 
a good job achieving compatibility.

As an alternative to that proposal, I think it's possible that 
you can achieve much of that by saying that the client can 
submit assertions against whatever resource it likes in 
the If: header, and the server will evaluate all of the If: header, 
and the server does also require that the client ask a few 
particular questions against particular resources.  It's not 
as simple as Lisa's solution, but it's at least an improvement 
over 2518. 

But if you say that the server only evalutes some of 
what the client submits, then you might as well abandon 
what appeared to be the primary purpose of 
the If: header in 2518.   If we do that, we should be 
aware the we're doing that and make sure we're 
comfortable with that.

> specified by the request-URL must be submitted". 

I think you didn't understand my question... 

A (depth) lock can lock 
many resources. Which locked resource/URL should be specified when 
submitting the lock token?   You've suggested both (1) the root and (2) 
the
request resource.  Another option
is to just submit it  on the resource whose being locked poses an
impediment, but there can be zillions of those in the case of operations
like the 2518-style DELETE in the presence of depth locks.  That leaves 
the first two options and I think only (1) can work universally.

> like a pretty pointless semantics to support.  But I'm happy 

I suspect that's the best approach. 

So I'd say...

All of the If; header is evaluated, 
and the token(s) in question must be "mentioned".  And I suspect we need
resolve on what resource it should be mentioned.    I'm voting tor the 
resource
that is the root of the lock. 

Am I nutz?  :-)

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 10 Oct 2002 12:46:50 -0400

On Wednesday, 10/09/2002 at 08:28 AST, "Clemm, Geoff" wrote:

   > if the server can tell just by scanning the If header that it
   > doesn't apply to the GET, then it can skip the If header.  For
   > example, if the If is a tagged list, and the tag did not identify
   > the request-URL, since a GET only applies to the request-URL, it
   > can ignore that If header.

   Wow.  I wouldn't have expected this as an answer.  It sounds like
   the purpose of the If: header becomes for the server to verify what
   it wants to.

That's certainly not what I meant to imply.  Let's try a
specific scenario.  A client does a "GET /coll/foo.html", with
a tagged list If header.  My server scans the If header,
and determines that none of the tags match "/coll/foo.html".
By section 9.4.2:

"If none of the resource productions match the current resource then
the header MUST be ignored."

So my server correctly ignores the If header, i.e. it ignores what
2518 requires it to ignore.  There is of course some wiggle room
around the term "match the current resource", but I believe that "the
current resource" and "match" is reasonably clear for the GET method
(i.e. write locks are ignored, and the only resource being read is the
one identified by the request-URL).

   That seems like a signficant change in philosophy from 2518.  2518
   seems to spend a lot of time talking about If: header and all it's
   details but not about how it's used to submit lock tokens.  It's
   use for lock token submission seems to simply be an afterthought.

I completely agree that we need to clarify exactly how the If header
should be used to submit lock tokens (in particular, to maximize
interoperability with existing servers).

   It even says the following when it begins to talk about the If;
   header.

      The If header is intended to have similar functionality to the
      If-Match header defined in section 14.24 of [RFC2616].  However
      the If header is intended for use with any URI which represents
      state information, referred to as a state token, about a
      resource as well as ETags.  A typical example of a state token
      is a lock token, and lock tokens are the only state tokens
      defined in this specification.

   And I've taken this opening statement, and the fact that it never
   talks about lock token submission in this section, to mean that the
   primary purpose of the If: header was for a client to verify
   various aspects of server state (like If-Match) before doing an
   operation.  I'm not saying that you're wrong to want to specify
   what you just have, but it seems to me that you are suggesting is a
   change in purpose/philosophy because the client can no longer
   really fully use it for verifying server state.  I want to bring
   attention to that to be sure that's what you really want.

Did my example above clarify that I was just talking about the
defined semantics of a tagged list?

This probably should go in a separate thread, since I believe what you
are questioning is the fact that 2518 says that in a tagged list
production, the conditions are only checked if the request is "applied
to" the resource identified by the tag.  This means we need to
carefully define what resources a given method "applies" to, so that
we can get consistent behavior across different servers.

One simple alternative is to declare that "all methods apply to
all resources" (for the purpose of the If header), which then 
would force a server to verify every tag list in the If header.

Just for interests sake, would any existing clients break if
a server implemented the If header in this way?  Does anyone
have an important use case where they want to submit If header
entries that they expect/want the server to ignore if the
current request is not "applied" to those resources?

If by "fix this", you mean clarify how to submit tokens, I agree, but
I think that it is easy to clarify this without creating a new header.
And I totally disagree that the new-header proposal does a good job of
achieving compatibility (with existing clients and servers).

Note that this does change the If header semantics defined in 2518
(which pretty clearly imply that a request does not "apply" to all
resources), but if this semantic change is not a problem for existing
clients and servers (e.g. if they don't really use the tagged list
form of the If anyway), then it is fine with me.

   But if you say that the server only evalutes some of what the
   client submits, then you might as well abandon what appeared to be
   the primary purpose of the If: header in 2518.  If we do that, we
   should be aware the we're doing that and make sure we're
   comfortable with that.

It appeared to me that the section 9.4.2 of 2518 intended that a
server only apply a subset (possibly empty) of the If header, namely,
the subset for the resources to which the method is being "applied".
So I'd turn it around, and say, if we are changing the semantics
of the If header so that it applies to all tagged lists, then we
need to be aware that we are doing that and comfortable with doing so.

   >    The request URL?  I guess that's okay.  I had actually
   >    proposed the root of the lock rather than the request URL.  I
   >    think lower in this note you also said it should be the root
   >    of the lock.
   > 
   > Parsing problem (:-).  I meant: "the lock on (the resource
   > specified by the request-URL) must be submitted", not "(the lock
   > on the resource) specified by the request-URL must be submitted".

   A (depth) lock can lock many resources.

Agreed.

   Which locked resource/URL
   should be specified when submitting the lock token? 

You submit the lock-root of the lock as the tag.

   You've
   suggested both (1) the root and (2) the request resource.

No, I've only suggested (1).  The sequence is:
- find the resource that the request-URL is mapped to.
- find the lock on that resource.
- submit the lock token with the lock-root of that lock as the tag.

So there are two URL's here ... the request-URL, and the
lock-root URL.  With a depth lock, the two URLs can be different.

Note that there is a somewhat subtle point here; namely, for If header
purposes, one of the resources to which an "update" operation
"applies" will always be the resource identified by the lock-root of
any lock on the resource.

   Another option is to just submit it on the resource whose being
   locked poses an impediment, but there can be zillions of those in
   the case of operations like the 2518-style DELETE in the presence
   of depth locks.  That leaves the first two options and I think only
   (1) can work universally.

I agree.

   So I'd say...

   All of the If; header is evaluated, and the token(s) in question
   must be "mentioned".  And I suspect we need resolve on what
   resource it should be mentioned.  I'm voting for the resource that
   is the root of the lock.

It sounds like we are in violent agreement that the lock-root
URL should be the tag for the If clause that mentions a particular
lock token.  It also sounds like we still need to spend some time
discussing what resources a method "applies" to, for If header
purposes.

Cheers,
Geoff