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

RE: DAV:getlastmodified of collections

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
Message-ID: <OF473FB777.701A454A-ON85256D98.006B3886-85256D98.006B6D24@us.ibm.com>

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 GMT

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