FW: [Moderator Action] RE: ETags

Accidentally caught by the spam filter.  I've added gclemm@rational.com to
the accept2 list.

- Jim

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Thursday, February 17, 2000 2:46 PM
To: WebDAV WG
Subject: [Moderator Action] RE: ETags


I agree with Kevin.  Whatever the spec says, it should say "MUST".
Leaving it as a MAY would be a disservice to clients.

Given the reasons described below, I vote that
the spec should say that modifying a property
(live or dead) of a resource MUST NOT modify the ETag or modification date.

Cheers,
Geoff


-----Original Message-----
From: Kevin Wiggen [mailto:wiggs@wiggenout.com]
Sent: Thursday, February 17, 2000 3:43 PM
To: Jim Whitehead; WebDAV WG
Subject: RE: ETags



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: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
Sent: Thursday, February 17, 2000 12:03 PM
To: WebDAV WG
Subject: FW: [Moderator Action] RE: ETags


Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Wednesday, February 16, 2000 7:56 PM
To: w3c-dist-auth@w3.org
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:wiggs@xythos.com]
> Sent: Wednesday, February 16, 2000 4:12 AM
> To: w3c-dist-auth@w3.org
> 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
>

Received on Friday, 18 February 2000 13:37:12 UTC