- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 10 Oct 2002 23:20:40 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Lisa, > Yes. I'm saying that even if we define what the state of a resource is, > servers will handle things differently and clients will constantly have > to reissue requests in order to get the right lock tokens. Why that? If we get the clarification right, the only issue would be non-conforming implementations. And obviously there's no way we can guarantee interoperability if implementations do not comply with the spec. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, October 10, 2002 10:40 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: GULP (version 4) > > > > > lisa > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Thursday, October 10, 2002 10:24 AM > > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > Subject: RE: GULP (version 4) > > > > Lisa, > > > > please re-read my mail. > > > > I was saying that we need to define what the state of a resource is. > > > > In particular its > > > > - content > > - internal members (depth 0 lock on collections) > > - dead properties > > - locks > > - *some* live properties (such as DAV:label) -- this is where it'll > get > > hairy, I guess > > > > Julian > > > > -- > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Thursday, October 10, 2002 7:20 PM > > > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > > Subject: RE: GULP (version 4) > > > > > > > > > > > > > "If a request would modify the state of a resource, the request > MUST > > > fail > > > > unless the lock-token for that lock is specified in the request." > > > > > > This isn't much more specific than the current "is affected by" > > > language. It leaves it entirely up to the server to decide what > > > modifying the state of a resource is. Does modifying membership > count? > > > (Is modifying membership blocked by a depth 0 lock?) Does modifying > > > property values count? > > > > > > This is exactly where clients have had problems submitting simple > > > requests to server implementations that each have a different idea > what > > > resources have state modified by the request. > > > > > > lisa > > > >
Received on Thursday, 10 October 2002 17:21:23 UTC