- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Fri, 5 Sep 2003 15:33:22 -0400
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: w3c-dist-auth@w3c.org
That's fine, but the binding spec needs to follow whatever decision is made by the spec defining DAV:getlastmodified (which is RFC2518). So the binding spec can't be clear on it until RFC2518 is clear on it. Cheers, Geoff "Lisa Dusseault" <lisa@xythos.com> wrote on 09/05/2003 02:23:04 PM: > > > > Lisa (or whoever is maintaining the 2518bis issues list): > > Can this be added to the 2518bis issues list? > > Yes. However, the bindings specification should also be clear how BIND and > UNBIND work with this. > > > > > Cheers, > > Geoff > > > > Peter wrote on 09/05/2003 12:19:09 PM: > > > > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified > > > property is not required to be defined for collections, but a server > > > MAY define it. Is that correct? > > > Then, probably the bindings of the collection are to be considered > > > part of the collection's state and it would make sense to set DAV: > > > getlastmodified whenever the bindings change: > > > - BIND, UNBIND (the coll identified by the req-URI) > > > - REBIND (the coll identified by the req-URI AND the 2nd > > involved coll) > > > - PUT returning 201 (the containing collection) > > > - MKCOL (the containing collection) > > > - DELETE (the containing collection) > > > - LOCK creating a lock-null resource (the containing collection) > > > - VERSION-CONTROL on existing version (the containing workspace) > > > Sorry for such a basic question, but I didn't find it in the specs. > > > Regards, > > > Peter > > > > > >
Received on Friday, 5 September 2003 15:59:43 UTC