RE: getlastmodified of collections

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Geoffrey M Clemm
> Sent: Monday, September 08, 2003 2:11 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: getlastmodified of collections
>
>
>
> I agree with Lisa's observations below, and my conclusion is that since
> the behavior of GET on a collection is not defined, the behavior of
> DAV:getlastmodified should not be defined, since the purpose
> of the Last-Modified header is to support caching of the GET request.

To clarify: the behaviour of GET and the HTTP Last-Modified header *is*
defined by RFC2616. A collection may or may not have gettable
representations (as any other resource), but if it does, the Last-Modified
header must obey RFC2616's rules (that is, if it's present it must change
when the GETtable content changes). The behaviour for DAV:getlastmodified
follows automatically.

> So until 2518 defines server-independent behavior of GET on a collection
> 2518 should remain silent on DAV:getlastmodified on a collection.

Yes. In particular, if we see a use case for a last modified timestamp that
is not directly tied to content changes, we need to define a new one. This
may be optional (as all the other timestamps we have), so it shouldn't be a
problem getting it into RFC2518bis.

Maybe a topic for the interop event?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 8 September 2003 09:50:38 UTC