W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2005

Re: BIND and live property value consistency

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 7 Jul 2005 16:42:42 -0400
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF8EF488ED.2D2162AB-ON85257037.00714E6A-85257037.0071C6B8@us.ibm.com>
As Julian states below, this is a very reasonable thread to pursue in
the context of RFC2518bis, and given that RFC2518bis
is a current high priority deliverable for this workgroup, it baffles me 
why we
are having this discussion in a BIND protocol thread.

Cheers,
Geoff

Lisa wrote on 07/07/2005 04:29:51 PM:

> 
> Well I think the MUST is better than nothing, but there's probably other 
 
> alternatives -- a careful SHOULD, or even a more nuanced requirement.
> 
> "WebDAV states that the getlastmodified property MAY be udpated when 
> changes are made to the resource even if the changes aren't to the 
> resource body, and this naturally includes changes to the resource's 
> bindings.  Note however that clients might use Last-Modified to 
> synchronize changes to resources, so servers MUST ensure that the value 
is 
> updated in order to allow synchronization to be correct.  For example, 
> when a binding to a resource with last-modified time T1 is replaced with 
a 
> binding to a resource with last-modified time T2, the server either has 
to 
> ensure that T2>T1 or update it accordingly."
> 
> Lisa
> 
> On Thu, 07 Jul 2005 10:23:09 -0700, Julian Reschke 
<julian.reschke@gmx.de> 
> wrote:
> 
> > 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
> 
> 
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> 
Received on Thursday, 7 July 2005 20:42:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:09 GMT