W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

RE: Interop issue: Proposal for fixing lock token provision

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 8 Oct 2002 09:08:18 -0400
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25EE3@SUS-MA1IT01>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Monday, 10/07/2002 at 10:25 AST, "Clemm, Geoff"  wrote:
   > 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.

   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.

   > 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.

   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.

Received on Tuesday, 8 October 2002 09:08:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:27 UTC