- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Thu, 16 Aug 2001 18:13:03 -0400
- To: "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: w3c-dist-auth@w3c.org
<< 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. >> And I might find that acceptable, but I'd think the long term view is that we keep it seperate and orthogonal, so I'm going to continue to advocate a seperate header. First a question though: I did a quick read of the spec last night. Can there be more than one IF: header for a given request? Proposal: Let's propose a new header (for clarity of this note, let's call it "submitted-ltokens:"). We can work out what the syntax is for that after some discussion, but we could start with something similar to what Geoff proposed in his last note. This should provide a very clean spec, but we could optionally add some text to bring attention to the fact that token presentation has changed. With that spec in place, the implementations would want to implement a transition strategy. For servers, if the submitted-ltokens header is included, the prudent servers would only check that header for the purpose of token submission purposes. If the new header is not included in the request, the prudent server would check the IF header for token submission along the vaguely specified (aka unspecified) lines of 2518. In both cases, the IF header would be checked as documented by 2518 section 9.4. For prudent clients the transition strategy would be to simply submit both the new header and the if header. This would insure that they could work with old servers and new servers. Is this reasonable? J.
Received on Thursday, 16 August 2001 18:14:42 UTC