- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 16 Aug 2001 12:24:13 -0400
- To: w3c-dist-auth@w3c.org
From: Jason Crawford [mailto:ccjason@us.ibm.com]
... it also says that we use the IF header for token presentation in
section 7.6:
In order to prevent these collisions a lock token MUST be
submitted by an authorized principal in the If header for all
locked resources that a method may interact with or the method
MUST fail.
And it says similar things other places in the spec.
But nowhere is it defined what "submitted" means.
I agree that this is not made clear, and should be. Let's try:
"Submitted" means "appears in an operator-free If header list
(e.g. no "not" operator in the list) that either is a tagged list
with a URI that identifies the locked resource, or is a no-tagged
list.
And what if all
the tokens necessary are included in the IF header, but only one of
them happens to be on the proper URI?
By the above definition, this would not succeed.
Since one matches the IF criteria, so we
consider the tokens to be duly sumbitted even if they guessed the wrong
URL
for most of the tokens.
Not by the above definition.
If you use a 'not' construct, can it be
considered to be submitted?
Not by the above definition.
What if we want to extend the spec to add more
sophisticated boolean logic support to the if header to test
pre-conditions? Then what does it mean to use the if header to submit a
token?
The "no operator in list" wording was to eliminate this concern.
There is too much behavior overloaded on the IF header. Let's let
the IF header do what you mentioned and use another means for
submitting lock tokens to assert our ownership of locks.
I agree with your point about the If header being excessively
overloaded, but for compatibility with existing implementations, I'd
try to fix the problem by clarifying how lock tokens should appear in
If headers, rather than defining a new header.
Cheers,
Geoff
Received on Thursday, 16 August 2001 12:15:20 UTC