- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Thu, 16 Aug 2001 01:45:15 -0400
- To: "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: w3c-dist-auth@w3c.org
<< From: Jason Crawford [mailto:ccjason@us.ibm.com] My opinion is that... The spec should not use the IF header for token presentation to the server. The IF header should only be used for client initiated assertion checking. The current use of IF for dual purposes just causes confusion (like I think your note indicates) and impedes our ability to potentially extend it later. We should transition to some other header for token presentation to the server. Or perhaps I just misunderstand the IF header and someone needs to clearly define it. :-) Jason: I don't see your concern here. The semantics of the If header is quite clearly defined in 2518, and says that if none of the state lists that apply to a resource match, then the request must fail with a 412. Although as indicated in a previous message, the "applies to a resource" is not well defined for no-tagged state lists, this is a general problem with the If header, and not a particular problem for lock tokens. >> If that were all it said, it would be much improved, but 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. 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? 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. If you use a 'not' construct, can it be considered to be submitted? 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? 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. J.
Received on Thursday, 16 August 2001 10:25:27 UTC