Subject: FW: [Moderator Action] RE: ETags

From: Jim Whitehead <[email-masked]>
Date: Thu, 17 Feb 2000 12:03:11 -0800

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Wednesday, February 16, 2000 7:56 PM
To: [email-masked]
Subject: [Moderator Action] RE: ETags

A good reason to not change the etag or mod-date when a property changes
is that a property is often information about the resource, as opposed to
"being" the resource.  If I mark a resource as being "tested", I don't want
it to appear that the resource has changed (thus making it look like I need
to test it again).
A less compelling reason (but still a consideration) is to achieve
consistency
between dead and live properties.  You certainly don't want a change to the
"last access time" of a resource to modify the etag or "modification time"
of
that resource.
Add to this the fact that current implementations appear to not modify the
etag or
modification time when a dead property is modified, and I think we have a
pretty
case that neither the etag value nor the modification time should
be changed when a dead property is updated.

Cheers,
Geoff

> -----Original Message-----
> From: Kevin Wiggen [mailto:[email-masked]]
> Sent: Wednesday, February 16, 2000 4:12 AM
> To: [email-masked]
> Subject: ETags
> 
> 
> 
> I searched the spec and could not find any special details on handling
> ETags.
> 
> Should an ETag value be updated when a dead property is 
> changed?  On the
> same note, do most servers update the last-modified-date when a dead
> property is changed?  Does Webdav want to take a stand one 
> way or another?
> 
> 
> Curious,
> Kevin
>

---

From: Greg Stein <[email-masked]>
Date: Thu, 17 Feb 2000 12:18:43 -0800 (PST)

Sounds good. Maybe we can include in the 2518 update language something
like this:

"Adding, changing, or removing a property MAY alter the
DAV:getlastmodified property."

In other words, don't rely on it happening, but also don't rely on it NOT
happening.

(note that I don't discriminate between live/dead props)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Kevin Wiggen <[email-masked]>
Date: Thu, 17 Feb 2000 12:42:33 -0800

I could probably make up just as compelling reasons why the ETag and
Last-Modified-Date SHOULD change during a update of a dead property etc.

But

I agree that it seems that no other server can (or is) supporting this.  I
can pull this functionality out of Xythos.

I just read Greg's email, and I don't like putting the MAY in the spec.  A
client will never know what the server is doing.  I think we just need to
pick a position and put it in 2518.

I am fine with changing properties does not modify the ETag or
Last-Modified-Date.  But I think we should be consistent.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Whitehead
Sent: Thursday, February 17, 2000 12:03 PM
To: WebDAV WG
Subject: FW: [Moderator Action] RE: ETags

- Jim

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Wednesday, February 16, 2000 7:56 PM
To: [email-masked]
Subject: [Moderator Action] RE: ETags

Cheers,
Geoff

---

From: Greg Stein <[email-masked]>
Date: Thu, 17 Feb 2000 14:30:10 -0800 (PST)

I think that we have to say MAY. Consider the case where properties are
stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the
date will change when you store a property. While reasonable to state that
the server implementation is required to restore the modification date to
the original (before storing the property), I think that is getting into
dangerous territory. What if your backup solution is using the
modification time to backup that multi-stream file? Or maybe there is
another storage mechanism where a server couldn't restore the date(!).

Putting a MAY into the spec is fine. Yes, the client won't know what the
server is going to do, but that isn't that big of a deal. For most of the
live properties, the client won't always know what will happen when they
touch the resource.

Cheers,
-g

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 17 Feb 2000 16:01:11 -0800

Given that most filesystems allow you to update the modification date
directly whenever you want, I think the MAY language is fine.  Using the
modification date is always based on convention, for this reason.

However, if I had to choose, I would say updating a property SHOULD change
the modification date.  The properties should be considered part of the
resource entity.  Otherwise, for example, would the ACL for a resource not
apply to the properties, if they are not part of the resource entity?  Would
you have a second ACL restricting access to the properties, separate from
the ACL for the resource data itself?  The implications of the properties
NOT being part of the resource entity gets too yucky.

Perhaps WebDAV should RECOMMEND that the modification date be updated when
properties are updated, to set the convention, but not require it.

--Eric