Subject: DAV:getlastmodified of collections

From: "Nevermann, Dr., Peter" <[email-masked]>
Date: Fri, 5 Sep 2003 18:19:09 +0200

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 5 Sep 2003 14:11:35 -0400

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:

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 5 Sep 2003 11:23:04 -0700

> 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.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 5 Sep 2003 15:33:22 -0400

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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Sep 2003 23:52:25 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Nevermann, Dr., Peter
> Sent: Friday, September 05, 2003 6:19 PM
> To: [email-masked]'
> Subject: DAV:getlastmodified of collections
>
>

Actually, it's not really required at all. A server should provide a
DAV:getlastmodified property for any resource for which it actually would
also provide the last-modified header upon GET. So a collection may have
GETtable content (in which case DAV:getlastmodified should be present), and
then also a server may not even have the last-modified date for a plain
resource (for instance if it's clockless).

> whenever the bindings change:

I agree although I have to point out that properties *also* are part of the
state of a collection, and the current consensus seems to be that the
last-modified date should not change when the content doesn't. So this is
non-obvious.

> - VERSION-CONTROL on existing version (the containing workspace)

Yes.

> Sorry for such a basic question, but I didn't find it in the specs.

No, it's good to ask these kinds of questions.

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Sep 2003 23:54:12 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Geoffrey M Clemm
> Sent: Friday, September 05, 2003 8:12 PM
> Subject: Re: DAV:getlastmodified of collections
>
>
>

Hm. Does it affect the state of a parent collection if it (the collection)
isn't version-controlled? In this case the state of the collection IMHO
doesn't (or doesn't need to) change.

> ...

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 5 Sep 2003 18:03:06 -0400

I was referring to the VERSION-CONTROL bullet in Peter's
original message, i.e. VERSION-CONTROL with a version argument
(which always creates a new version-controlled resource).

For VERSION-CONTROL without a version argument (which never
creates a new version-controlled resource), you are correct
that it does not affect the state of the parent collection.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 6 Sep 2003 00:08:11 +0200

I see.

But then we're missing the case of VERSION-CONTROL on a versionable but not
yet version-controlled resource that lives inside a versioned collection (in
which case I'd say the state of the parent collection *does* change).

Julian

> -----Original Message-----
> Sent: Saturday, September 06, 2003 12:03 AM
> To: [email-masked]
> Subject: RE: DAV:getlastmodified of collections
>
>
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 5 Sep 2003 15:16:56 -0700

This is a good point.  I was thinking that the GET response to a directory
was likely only a 
listing of its member files, and then Geoff's idea of getlastmodified would
fit this model.
However there are a number of other possibilities:

 - If the server includes information about a directory's members, that
could change.  E.g.
	File Name		Size		Last Modified
	file1.txt		123k		8/1/2003
	file2.txt		124k		8/2/2003
   A server that did a listing like this in response to a GET ought to
change its directory's
   getlastmodified value whenever the content changed. Obviously that might
include a PUT
   operation to a child as well as the other operations listed.

 - If the server returns a file like "index.html" in response to a GET for a
directory, then
   possibly the 'getlastmodified' property value for the directory should be
that of 
   the index.html file.

How many HTTP/WebDAV clients are there out there that do caching/synch based
on the 
Last-Modified header or the 'getlastmodified' property?  I am guessing there
are quite
a few because from what I've seen clients can't rely on ETag support in
Web/WebDAV servers.

Lisa

> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Friday, September 05, 2003 2:52 PM
> To: Nevermann, Dr., Peter; [email-masked]
> Subject: RE: getlastmodified of collections
> 
> 
> 
> > [mailto:[email-masked]]On
> Actually, it's not really required at all. A server should 
> provide a DAV:getlastmodified property for any resource for 
> which it actually would also provide the last-modified header 
> upon GET. So a collection may have GETtable content (in which 
> case DAV:getlastmodified should be present), and then also a 
> server may not even have the last-modified date for a plain 
> > part of the collection's state and it would make sense to set 
> > DAV:getlastmodified whenever the bindings change:
> 
> I agree although I have to point out that properties *also* 
> are part of the state of a collection, and the current 
> consensus seems to be that the last-modified date should not 
> change when the content doesn't. So this is non-obvious.
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 6 Sep 2003 11:46:28 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, September 06, 2003 12:17 AM
> To: 'Julian Reschke'; 'Nevermann, Dr., Peter'; [email-masked]
was likely only a
> listing of its member files, and then Geoff's idea of getlastmodified
would fit this model.

Yes.

could change.  E.g.
change its directory's
>    getlastmodified value whenever the content changed. Obviously that
might include a PUT
>    operation to a child as well as the other operations listed.

Correct.

>  - If the server returns a file like "index.html" in response to a GET for
a directory, then
>    possibly the 'getlastmodified' property value for the directory should
be that of

Yes.

> How many HTTP/WebDAV clients are there out there that do caching/synch
based on the
> Last-Modified header or the 'getlastmodified' property?  I am guessing
there are quite
Web/WebDAV servers.

I think most user agents will cache using the Last-Modified *header* when no
ETag is present. I however doubt that there are lots of WebDAV-aware clients
that actually use DAV:getlastmodified to cache (they'd still need to GET the
content, in which case they SHOULD use the "Last-Modified" header returned
by GET).

In general, all we can say reliably is that the Last-Modified date should
change when the GETtable content changes. Now the real issue here is: is the
timestamp allowed to change even though the content didn't. We ruled that
out for property changes (which I think is wrong), but seem to propose it
for other non-content changes here.

See also
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0122.html>,
part 2.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 8 Sep 2003 08:10:41 -0400

> which case I'd say the state of the parent collection *does* change).

I suggest we keep the semantics very simple, and say that 
DAV:getlastmodified
is changed only by adding a binding, removing a binding, or changing a 
binding
to new resource.  Putting an existing resource under version control does
none of these things, so it should not result in an update to 
DAV:getlastmodified.

Note that in general the "version-controlled state" of a collection will 
be
different from the "state" of a collection, i.e. adding and removing a 
binding
to a non-version-controlled resource does not change the 
version-controlled
state of a collection, but does change the state of the collection.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 8 Sep 2003 08:10:48 -0400

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.

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

Cheers,
Geoff

> listing of its member files, and then Geoff's idea of getlastmodified 
would
>    getlastmodified value whenever the content changed. Obviously that 
might
> How many HTTP/WebDAV clients are there out there that do caching/synch 
based
> Last-Modified header or the 'getlastmodified' property?  I am guessing 
there

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 8 Sep 2003 15:41:45 +0200

> Behalf Of Geoffrey M Clemm
> Sent: Monday, September 08, 2003 2:11 PM

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.

> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 8 Sep 2003 15:45:20 +0200

DAV:getlastmodified
binding
be
binding
version-controlled
> state of a collection, but does change the state of the collection.

This seems to imply that the version-controlled state is not a subset of the
state, or more precisely, that you can modify the version-controlled state
without changing the state. This IMHO seems to be a weird way to define the
state of a collection.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 8 Sep 2003 11:18:43 -0400

I believe that we have concluded that DAV:getlastmodified depends on
what the server returns on a GET on a collection, and therefore is not
something we can define (since what the server returns on a GET on a
collection is not defined).  So what we are really talking about in
this thread is a new property (which without much thought, I've named
DAV:bindings-last-modified).

This raises the key question: what will the client be using this new
property for.  I suggest it be used to keep the structure of a client
tree display synchronized with the names and resources on the server,
in which case the client doesn't care whether the version-controlled
state changes, as long as the named tree of resources is still valid.

Cheers,
Geoff

> > Geoffrey M Clemm
DAV:getlastmodified
binding
> > Note that in general the "version-controlled state" of a collection 
will be
binding
version-controlled

---

From: Chris Knight <[email-masked]>
Date: Tue, 09 Sep 2003 15:36:33 -0700

Geoffrey M Clemm wrote:

>collection is not defined).
>
Actually, since many servers do implement GET on a collection, how about 
saying "DAV:getlastmodified should be defined for collections if the 
server supports GET on collections and the value of the property would 
be the last time some operation changed what would be the result of a 
GET operation (and would be the value that would be compared against if 
a Last-Modified header was sent on said GET request)"?

Sorry, my brain is not thinking in protocol-spec-speak right now, but I 
think you get the idea.

Your other property for bindings would be useful as well, and I would 
guess that many implementations would make them equivalent (as a GET on 
a collection would return an HTML rendering of the bindings from that 
collection.)

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 9 Sep 2003 16:39:19 -0700

This sounds like the right general idea.

I'm starting to think that RFC2518 needs a new section, a non-normative
note or warning on the dangers of relying on the value of 
'getlastmodified'.  As far as I can tell:
 - some servers allow this to be modified by clients
 - on a MOVE, some servers set the destination getlastmodified to
   the source's previous value, others set it to the timestamp of the
   operation itself
 - on a COPY, same thing, but probably not on all the same servers
   that do the MOVE that way
 - some servers allow underlying file system operations to replace
   files with new files with *older* getlastmodified values
 - some servers modify getlastmodifed when props change
 - the behavior on directories is probably completely random

Thus, clients can't rely on the value of getlastmodified (or
the Last-Modified header) at all and should use ETags instead.
If the server doesn't support ETags the client is screwed.  
In that case, possibly the only reasonable thing is to throw
away your cached version anytime the last modified value changes
an iota, even if it changes to be *earlier* than your cached 
version.

Lisa

> [mailto:[email-masked]] On Behalf Of Chris Knight
> Sent: Tuesday, September 09, 2003 3:37 PM
> To: Geoffrey M Clemm
> Cc: [email-masked]
> Subject: Re: DAV:bindings-last-modified (was RE: 
> DAV:getlastmodified of collections)
> 
> 
> 
> Geoffrey M Clemm wrote:
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 9 Sep 2003 22:02:11 -0400

I agree with Lisa's points below, especially the last point, i.e.
that we should provide guidance to clients that they should always
check for equality of the Last-Modified value to what they
previously retrieved.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 9 Sep 2003 22:02:14 -0400

If one were to add language of the kind you describe below, I'd emphasize
that this is just implied by the definition of the Last-Modified header,
and not some new semantics defined for collections.

Cheers,
Geoff

Chris Knight <[email-masked]> wrote on 09/09/2003 06:36:33