W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004


From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 02 Jun 2004 15:16:27 +0200
Message-ID: <40BDD32B.1020304@gmx.de>
To: w3c-dist-auth@w3.org


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 

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

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