FW: [Moderator Action] RE: ETags

Accidentally caught by the spam filter.

- Jim

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


We've got two issues here:

1) Should property updates change the mod-date?
2) Should property updates change the e-tag?

Re #1:
> 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.

Agreed.

Re #2:
> 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).

I disagree.  If you mark a resource as 'tested', it is a different entity
than the one not marked as 'tested'.  If we're doing any sort of
collaboration, I would not want my unmarked file (& props) to overwrite your
marked file (& props) because my application mistakenly thinks that these
entities are the same.
Furthermore, what about null resources (i.e. simple collections of
properties)?  If a property change doesn't indicate a new entity, then
there's no point in even having an e-tag -- all entities are the same.

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

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, 17 February, 2000 2:19 PM
To: WebDAV WG
Subject: Re: ETags


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

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

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

Received on Thursday, 17 February 2000 17:26:47 UTC