FW: [Moderator Action] RE: ETags

Accidentally caught by the spam filter. (Yes, I am working on adding Douglas
to the accept2 list! :-)

- Jim

-----Original Message-----
From: Douglas Steen [mailto:dsteen@ekeeper.com]
Sent: Thursday, February 17, 2000 1:13 PM
To: WebDAV WG
Subject: [Moderator Action] RE: ETags


My vote:

#1) Changing properties MUST change the e-tag
#2) Changing properties MUST NOT change the last-mod-date

If you consider the last-mod-date to be the last time the FILE was modified,
then this would imply that dead properties ARE part of the entity, but NOT
part of the file.  By extension, the last-mod-date of a null resource would
be inconsequential, but the e-tag of a null resource would not be.

    Douglas R. Steen
    dsteen@eKeeper.Com
    Drag-and-Drop Web Content Management
    http://www.eKeeper.com

-----Original Message-----
From: Kevin Wiggen [mailto:wiggs@wiggenout.com]
Sent: Thursday, 17 February, 2000 2: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 Thursday, 17 February 2000 17:27:30 UTC