Re: DAV:getlastmodified of collections

Also, MOVE (on the collections containing the source and destination).
Also, COPY (on the collections containing any new resources created by the 
COPY).
One correction: VERSION-CONTROL affects the state of the collection
containing the resource being created, not on the containing workspace
(unless the workspace is the collection containing the resource).

I agree that this would be worth adding to 2518bis, i.e. saying that
"If a server supports DAV:getlastmodified for a collection, it must be
updated any time an internal member (2518's name for a binding) is
added or removed from a collection."

Lisa (or whoever is maintaining the 2518bis issues list):
Can this be added to the 2518bis issues list?

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 14:11:38 UTC