Subject: RE: GULP (version 4)

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 9 Oct 2002 16:50:15 -0400

From: Stefan Eissing [mailto:[email-masked]]

   > > Geoff, you say in GULP4:
   > >
   > > - If a request would modify the content, dead properties, or
   > > bindings of a locked resource, the request MUST fail unless the
   > > lock-token for that lock is specified in the request.
   > >
   > > What are the "bindings of a locked resource"? The complete 
   > > DAV:parent-set of the resource or a specific binding or the
   > > bindings of the resource  and all its parents?

   > The bindings of a resource identify its internal members (and
   > therefore only a collection has bindings).  The bindings "to" a
   > resource would be identified in the DAV:parent-set.  I should
   > reword this to make sure nobody is confused ... any suggestions?

   How about:

   "If a request would modify the content, dead properties, or the set
   of bindings to children of a locked resource, the request MUST fail
   unless the lock-token for that lock is specified in the request."

Or how about:

"If a request would modify the content or dead properties of a locked
resource, or would modify the bindings of a locked collection, the
request MUST fail unless the lock-token for that lock is specified in
the request."

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 10 Oct 2002 09:24:40 +0200

Sounds good.

Am Mittwoch, 09.10.02, um 22:50 Uhr (Europe/Berlin) schrieb Clemm, 
Geoff:

>    > > Geoff, you say in GULP4:
>    > >
>    > > - If a request would modify the content, dead properties, or
>    > > bindings of a locked resource, the request MUST fail unless the
>    > > lock-token for that lock is specified in the request.
>    > >
>    > > What are the "bindings of a locked resource"? The complete 
>    > > DAV:parent-set of the resource or a specific binding or the
>    > > bindings of the resource  and all its parents?
>
>    > The bindings of a resource identify its internal members (and
>    > therefore only a collection has bindings).  The bindings "to" a
>    > resource would be identified in the DAV:parent-set.  I should
>    > reword this to make sure nobody is confused ... any suggestions?
>
>    How about:
>

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 10 Oct 2002 10:24:41 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Wednesday, October 09, 2002 10:50 PM
> To: 'Webdav WG'
> Subject: RE: GULP (version 4)
>
>

One more thing that comes to mind are locks on the resource. Are we missing
something else?

Proposal: split into two sentences, one defining the "state" of a resource,
the other saying:

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

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 10 Oct 2002 19:24:07 +0200

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

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 7:20 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> 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
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 10 Oct 2002 10:19:33 -0700

lisa

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 10 Oct 2002 13:40:02 -0700

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. 

lisa

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 10:24 AM
> To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> > > "If a request would modify the state of a resource, the request
MUST
> > fail

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 10 Oct 2002 23:20:40 +0200

Lisa,

> 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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Thursday, October 10, 2002 10:40 PM