- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Wed, 2 Jun 2004 08:00:24 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: nnw3c-dist-auth___at___w3.org@smallcue.com, Jason Crawford <ccjason@us.ibm.com>
On Jun 2, 2004, at 7:26 AM, Julian Reschke wrote: > > Jason Crawford wrote: > >> The old way of overloading If seems pretty lame. Can't new clients >> do both? > > Agreed, but it works (if it ain't broke, don't fix it). Why are we > adding completely new requirements for both servers and clients with > the inevitable interoperability issues if the present protocol does > what it's supposed to do? We have been conservative about changes in RFC2518bis, generally only changing things where interoperability testing shows that there is a problem. In this case, confusion over where to put the lock token in refresh requests came up in actual implementations and early interoperability testing. In addition, it was unclear what to do if multiple lock tokens appeared in the If header (the Lock-Token header allows only one). IOW, the present protocol didn't quite do what it was supposed to do. > IMHO the only thing we should say is that LOCK without a request body > *with* an If header will refresh all locks on the resource identified > by the request URI (possibly deprecating the use of the Time-Out > request header here -- I don't think there's a strong use case for > changing the timeout after the lock already exists; and as far as I > know existing servers do not support it anyway). > It doesn't really fit our shared lock model (such as it is) to refresh all locks on the resource. Some may have been taken out by other users. Lisa
Received on Wednesday, 2 June 2004 11:00:41 UTC