- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 Jun 2004 17:06:00 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: nnw3c-dist-auth___at___w3.org@smallcue.com, Jason Crawford <ccjason@us.ibm.com>
Lisa Dusseault wrote: > 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. I agree that it is confusing. However, popular clients and servers seems to agree on how it works, so why don't we just write that down? >> 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. Yep. It should refresh exactly those that have been submitted in the "If" header. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 2 June 2004 11:06:16 UTC