Given the behavior of IIS5 and Apache/moddav2, 
it sounds we're pretty much stuck with the 2518 marshalling,
so I'd vote to just roll back the change in 2518bis.


Julian wrote on 06/02/2004 09:16:27 AM:

> Hi,
> I note that the issue above 
> (<>) 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 -- -- tel:+492512807760

Received on Wednesday, 2 June 2004 09:45:46 UTC