Subject: RE: GULP (version 4)

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 10 Oct 2002 14:57:08 -0700

"If we get the clarification right"?  A definition that involves
discussing properties, locks, and content in a way that is generic, will
result in a different conclusion for servers that do things differently.
The model can be 'clarified' for years and still be interpreted
differently.

Imagine we try to define a model for what constitutes a state change. 

 - What if a server, when you issue a DELETE, actually moves a file to
the trash can folder? What if the trash can folder is locked? Clearly,
it requires that lock token.

 - What a particular implementation decides that add a file to
/mydir/sub/dir actually changes a property value on /mydir?

 - What if the contents of a file are defined to import the contents of
another file?  The server implementation might define that as a content
change.

 - Does a collection's members state change if a file is renamed? 

 - Does a collection's members state change if a file is overwritten?  

My point is that models are hard to do right.  It's very tempting to
work on tweaking the model, when that might not be as effective as
simply specifying exactly what's supposed to happen in a particular
case.

In contrast, let's examine another way of "fixing" this problem by
putting additional specification requirements on the server.  Rather
than say a lock affects changing state in certain ways (the 'generic'
approach), we could define for each method what locks must be had.  For
example:

 - For DELETE requests, if the DELETE target is locked, or the DELETE
target parent is locked, those locks are affected.

 - For COPY requests, if the COPY target is locked, or the COPY target
parent is locked and the COPY target does not exist, those locks are
affected.

 - etc.

Let's go meta for a minute anyway.  There are at least two ways that
have been discussed to approach this "problem".  One way is to give the
client more leeway.  The other is to make things more restrictive for
the server - either through the generic approach of defining state, the
specific approach of describing requests.

Client implementers encountering this problem have asked for more client
leeway, NOT for more server restrictions.  I consider it perfectly valid
to restate the problem and try to find a different solution -- I do this
often and consider it a good design habit.  However, one must always be
careful to make sure one is really solving the right problem when one
does this.

lisa

> -----Original Message-----

> From: Julian Reschke [mailto:[email-masked]]

> Sent: Thursday, October 10, 2002 2:21 PM

> To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'

> Subject: RE: GULP (version 4)

> 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: [email-masked]

> > [mailto:[email-masked]]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:[email-masked]]

> > > 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:[email-masked]]

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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 11 Oct 2002 10:03:46 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lisa Dusseault
> Sent: Thursday, October 10, 2002 11:57 PM
> To: 'Webdav WG'
> discussing
> properties, locks, and content in a way that is generic, will result in a
> different conclusion for servers that do things differently.  The
> model can
> be 'clarified' for years and still be interpreted differently.

Then is hasn't been clarified.

If a specification defines locking, but doesn't define what operations on
locked resources require submission of the lock token, then in doubt a
client always has the choice of submitting the lock token. Servers that
don't require it will just ignore it. So where's the big issue with that?

>  - What if a server, when you issue a DELETE, actually moves a file to the
> trash can folder? What if the trash can folder is locked? Clearly, it
> requires that lock token.

Yes. Bad design. I don't see how anything you are proposing would help with
that problem? Either you need the lock token or not. I though the discussion
was about the topic on *how* to submit it.

Obviously, there always can be hidden server-specific dependencies on other
resources that may be locked. If the server wants to enforce these locks,
there's obviously no simple way for non-proprietary clients to interact with
it.

> /mydir/sub/dir actually changes a property value on /mydir?

That would be a computed live property that would better be not
lock-protected. If it is, generic clients will have a problem because they
won't expect this.

> another file?  The server implementation might define that as a content

That would be a bug (IMHO).

>  - Does a collection's members state change if a file is renamed?

The state of the collection changes. The state of the member doesn't.

>  - Does a collection's members state change if a file is overwritten?

The state of the collection doesn't change. The state of the member does.

> My point is that models are hard to do right.  It's very tempting  to work
on
> tweaking the model, when that might not be as effective as simply
specifying
> exactly what's supposed to happen in a particular case.

I think we don't have a choice but to define the model.

> In contrast, let's examine another way of "fixing" this problem by putting
> additional specification requirements on the server.  Rather than say a
lock
> affects changing state in certain ways (the 'generic' approach), we could
> define for each method what locks must be had.  For example:
target
> parent is locked, those locks are affected.

I'd prefer to have a generic model that explains all these requirements,
because it would also automatically apply to new methods. However, it surely
makes sense -- after getting the generic model right -- to write down what
this actually means for all specific methods. The important point is to get
the underlying model right first.

> Let's go meta for a minute anyway.  There are at least two ways that have
> been discussed to approach this "problem".  One way is to give the client
> more leeway.  The other is to make things more restrictive for the
server -
> either through the generic approach of defining state, the specific
approach
> of describing requests.

I don't agree. If you're talking about the "new" header, it doesn't give the
client any new freedom. It just allows a simpler syntax. It could use the If
header instead.

> leeway, NOT for more server restrictions.  I consider it perfectly valid
to
> restate the problem and try to find a different solution -- I do  this
often
> and consider it a good design habit.  However, one must always be  careful
to
> make sure one is really solving the right problem when one does this.

Yes. But the outcome might as well be that some existing protocol element
hasn't been understood properly and already does what the client implementor
is asking for. In particular, you *can* use the If header to submit any
number of lock tokens you have -- no matter whether they are required or
even in effect. If this doesn't work yet in practice, let's clarify the spec
and fix the implementations instead of inventing something new.

Julian