- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 Jun 2004 15:16:27 +0200
- To: w3c-dist-auth@w3.org
Hi, I note that the issue above (<http://www.webdav.org/wg/rfcdev/issues.htm>) mentions: "Another seems to be to specify what lock to refresh in a lock refresh request." RFC2518bis-05 (and possibly earlier versions) resolve this by using the "Lock-Token" header to indicate which lock to refresh (I think this was dicussed during an interop meeting; but this resolution doesn't appear on the issues list like it should!). I *do* agree that "Lock-Token" technically is a better choice to select the lock to be refreshed, however...: - RFC2518bis is unclear about whether you'll still need to specify the "If" header in the request (because one may argue that the LOCK refresh request is modifying the locked state of the resource) - RFC2518bis says it is "recommended" to support the old marshalling ("If" header). I think for backwards compatibilty with existing client this should be a "REQUIRED". Finally, I'm not so sure that this change really makes sense. As far as I can tell, no widely used server currently implements the new marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, clients will likely continue to use the old format anyway, because after all it works just fine; and IIS is unlikely to be upgraded anytime soon :-) So either 1) roll back the change in RFC2518bis, or 2) add both issue and resolution, and also clarify the issues mentioned above in new RFC2158bis text Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 2 June 2004 09:17:08 UTC