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


From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 2 Jun 2004 09:45:09 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OF31CD8C21.B9D8B4D9-ON85256EA7.004A5DB7-85256EA7.004B8D5F@us.ibm.com>
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 
> (<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:45:46 UTC

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