- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 07 Jul 2005 19:23:09 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, webdav <w3c-dist-auth@w3.org>
Lisa Dusseault wrote: > > > It's too bad about confusing existing clients when 'getlastmodified' > changes on some resource without any body changes (the client may be > completely unaware of bindings changse going on elsewhere), but I guess > that's a less bad approach than possibly causing synchronization errors. > > To me this seems like a perfect argument for requirements in the BIND > spec, not just implementation advice. Because of the synchronization > problems clients would have if implementors do it wrong, we should add: > > "WebDAV (RFC2518) states that the getlastmodified property value MAY be > updated when changes are made to the resource even if the changes > aren't to the resource body. However, because clients may synchronize > resources based on the value of this property, and because a binding to > one resource at URL A may replace another binding at the same address, > this requires a new getlastmodified date in order to trigger the client > to synchronize properly. Thus, the server MUST update the > getlastmodified property value whenever a new binding is added to an > existing resource as well as when REBIND is used." > > Lisa Lisa, in this case, MUST is wrong as well. A server may very well be aware of any resource mapped previously to that URI, so it *could* make a better decision. Anyway, this is a generic HTTP vs WebDAV issue, so please add it to the RFC2518bis issues list; and let's resolve it there. Best regards, Julian
Received on Thursday, 7 July 2005 17:23:18 UTC