Subject: resolving 057_LOCK_SEMANTICS

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jun 2004 19:53:21 +0200

Hi,

I have resolved 057_LOCK_SEMANTICS in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 
with the following changes (see previous mailing list discussion in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57>):

a) Define a generic precondition:

"(DAV:lock-submission-allowed): If the server restricts usage of the 
lock token inside an "If" request header to specific principals, the 
authenticated principal for this request MUST be one of them."

b) Change UNLOCK precondition DAV:lock-owner-matches to:

"(DAV:lock-removal-allowed): As dicussed above, the principal 
authenticated for the UNLOCK request MUST be allowed to remove the 
identified lock (note that servers that support the "WebDAV Access 
Control Protocol" should use the DAV:need-privileges precondition 
defined in section 7.1.1 of [RFC3744])."

c) Update "Write Locks and the If Request Header" as follows:

OLD:
    "In order to prevent these collisions a lock token MUST be submitted 
by an authorized principal in the If header for all locked resources 
that a method may interact with or the method MUST fail. For example, if 
a resource is to be moved and both the source and destination are locked 
then two lock tokens must be submitted, one for the source and the other 
for the destination."

NEW:
    "In order to prevent these collisions a lock token MUST be submitted 
in the If header for all locked resources that a method may interact 
with or the method MUST fail. For example, if a resource is to be moved 
and both the source and destination are locked then two lock tokens must 
be submitted, one for the source and the other for the destination.

Servers SHOULD restrict usage of the lock token to exactly the 
authenticated principal who created the lock. Servers MAY also allow 
other privileged authenticated principals or even unauthenticated 
principals to use the lock token."

Best regards, Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 18 Jun 2004 07:50:35 -0400

This is all fine with me, except I'd like to delete the "MAY"
clause from the last sentence in the update to (c).
Weakening this to a SHOULD is as far as we should go.
Explicitly adding in the MAY sentence looks too much like
encouragement to do the wrong thing.

Cheers,
Geoff

> with the following changes (see previous mailing list discussion in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57
> >):

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jun 2004 14:17:09 +0200

> encouragement to do the wrong thing.

Agreed. Saying

"Servers SHOULD do x, but MAY do not(x)"

isn't very useful.

Julian

---

From: <[email-masked]>
Date: Fri, 18 Jun 2004 15:14:47 +0200

Hello,

the auto-version property can currently hold 5 different values: Empty, checkout-checkin, checkout-unlock-checkin, checkout and
locked-checkout.

I would like to propose a new value, named something like: checkout-ignore-unlock. It will carry the same semantics as the
checkout value, but an unlock command will not issue an implicit check-in command, instead the resource stays in the checked-out
state and an explicit check-in command is required.

Use-case:

A document is controlled by a workflow process. Creating a document takes this document in the initial-author state, in which only
explicit check-in command should create new versions. If this newly created resource is implicitly put under version-control and
the auto-version property is set to the new suggested value, we can receive this behaviour. Now the document can be modified
either with an http client (via put) or with a WebDAV client (Lock - Put* - Unlock) and still the resource is never implicitly
checked-in. 
The same effect could be reached by an explicit check-out, but this will require an additional user interaction to issue the
check-out command, which we do not want to expose. Our user is then only required to use our state manipulation GUI tool, in case
of a real state change. The creation and manipulation of a new resource will feel like modification on the hard disc: create it,
modify it (with any tool) and then publish or change the state with an additional tool.

Does this make a more general sense, or would you think this is a too specific requirement to go into any new version of the
delta-v standard?

Best regards

Juergen Pill
Premium WebDAV Consultancy and Services 
www.webdav.info

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 18 Jun 2004 07:56:31 -0700

I'm a little confused.  If you don't want the user to have to go to the 
external state-manipulation tool, then why not use 
checkout-unlock-checkin?  I would think you would want the checkin to 
happen when editing is done, to publish the state.  Also note that the 
state is "published" regardless, in that any changes made by any client 
are visible on the resource checked out, whether or not it's checked in 
again -- it seems pretty clear in this case you're talking about 
in-place checkout.

The auto-version property is a bit of a hack to deal with 
non-DeltaV-aware clients that can never know when to check out and 
check in.  Adding more values to this property runs a risk of confusing 
DeltaV clients that are aware of this property but only know the values 
in the initial standard.  OTOH I'm not aware of any clients at all that 
use the value of this property as yet so it would be good to hear if 
there are any.

Lisa

On Jun 18, 2004, at 6:14 AM, <[email-masked]> wrote:

>
> Hello,
>
> the auto-version property can currently hold 5 different values: 
> Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> locked-checkout.
>
> I would like to propose a new value, named something like: 
> checkout-ignore-unlock. It will carry the same semantics as the
> checkout value, but an unlock command will not issue an implicit 
> check-in command, instead the resource stays in the checked-out
> A document is controlled by a workflow process. Creating a document 
> takes this document in the initial-author state, in which only
> explicit check-in command should create new versions. If this newly 
> created resource is implicitly put under version-control and
> the auto-version property is set to the new suggested value, we can 
> receive this behaviour. Now the document can be modified
> either with an http client (via put) or with a WebDAV client (Lock - 
> Put* - Unlock) and still the resource is never implicitly
> checked-in.
> The same effect could be reached by an explicit check-out, but this 
> will require an additional user interaction to issue the
> check-out command, which we do not want to expose. Our user is then 
> only required to use our state manipulation GUI tool, in case
> of a real state change. The creation and manipulation of a new 
> resource will feel like modification on the hard disc: create it,
> Does this make a more general sense, or would you think this is a too 
> specific requirement to go into any new version of the
> delta-v standard?
>
>
> Best regards
>
> Juergen Pill

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 19 Jun 2004 22:54:50 -0400

This new auto-version value only makes sense if the "checkin"
operation is used to promote a change in the workflow.  This is
probably non-optimal, since it doesn't let a client save an
intermediate state of the resource in the version history
(i.e. before it is ready to publish).  In addition, a step
in the workflow often requires changing multiple resources,
so you can't really infer from one being checked-in that the
task is complete.  So I would be against encouraging this 
model in the standard (and therefore would not
be in favor of standardizing on this new value).

WRT Lisa's question, he doesn't want the user to have to go to
the external state-manipulation tool to start a modification,
but he does expect the user to have to go to the external
state-manipulation tool to say "I'm finished with this task".
I agree that this is reasonable, but I'm against standardizing
on "checkin" to mean "I'm finished with this task".

Cheers,
Geoff

> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
> > modify it (with any tool) and then publish or change the state with an 

> > additional tool.

---

From: <[email-masked]>
Date: Mon, 21 Jun 2004 12:15:21 +0200

Hello Geoff,

The state machine was our initial motivation for this new auto-version property. Yes you are right the explicit check-in will
change the state, but return in the initial state again.

From the standard point of view we could argue that this new value would have for http and WebDAV clients the same post-condition,
namely the resource is kept checked-out. We would not tied together unlock and implicit checkin.

Anyway, there seems to be more points not to add it to the standard, than adding it to the standard. 

Best regards

Juergen Pill

  _____  

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Geoffrey M Clemm
Gesendet: Sonntag, 20. Juni 2004 04:55
An: [email-masked]
Betreff: Re: new auto-version value

Cheers, 
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 21 Jun 2004 08:23:34 -0700

Would another separate property work as well, or better?  A 'publish' 
property for manual setting, or an 'auto-publish' property indicating 
when the server should try to publish?  You might find support for that 
kind of thing orthogonal from versioning.

Lisa

On Jun 21, 2004, at 3:15 AM, <[email-masked]> wrote:

> Hello Geoff,
>
>
>
> The state machine was our initial motivation for this new auto-version 
> property. Yes you are right the explicit check-in will
> From the standard point of view we could argue that this new value 
> would have for http and WebDAV clients the same post-condition,
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Geoffrey M Clemm