FW: [Moderator Action] RE: ETags

Accidentally caught by the spam filter -- but, I've now added Douglas to the
accept2 list! :-)

- Jim

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


Sounds reasonable for the last-mod-date, but can we still do a MUST for the
e-tags?

    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 4:30 PM
To: WebDAV WG
Subject: RE: ETags


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

On Thu, 17 Feb 2000, Kevin Wiggen wrote:
> 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
> >
>

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

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