RE: Deleting versions

If a DeltaV server is also a DAV level 2 server (supports LOCK and 
UNLOCK), then it has to handle lock null resources - meaning it is 
possible to lock a null resource to create a lock null resource. In the 
spirit of RFC2518, we should allow all resource creation methods 
(MKWORKSPACE, MKACTIVITY, etc.) to operate successfully on a lock null 
resource converting them to the indicated resource type. That doesn't mean 
that all DeltaV methods have to operate on lock null resources. As with 
RFRC2518, we have to treat each one as a special case.





"Clemm, Geoff" <gclemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
06/06/2001 11:07 AM

 
        To:     DeltaV <ietf-dav-versioning@w3.org>
        cc: 
        Subject:        RE: Deleting versions

 

I agree that if a client is likely to get disconnected
in the middle of its MKWORKSPACE/LOCK request sequence, and if a server
lets you change the ACL's on a workspace but does not let
you create a workspace, and if a workspace can have its ACL's
updated by anyone other than the owner, then there is a use
case for issuing a MKWORKSPACE against a lock null resource.

But as you said earlier, RFC 2518 only constrains what HTTP
and DAV methods can be applied to a lock null resource,
so a compliant DelataV server can support this use case if it wishes.
We can't say it MUST support this use case, since a DeltaV
server is not required to support lock null resources at all.

Cheers,
Geoff 

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, June 05, 2001 7:43 PM
To: Clemm, Geoff; DeltaV
Subject: RE: Deleting versions


The problem is that the "client that got there before them" may have
permission to alter a workspace, but they may NOT have permission to 
CREATE
a workspace.

The problem is not that the other client locked it, but that they might
apply changes before you get a chance to prevent them!  I create a 
Workspace
(or a resource, or a collection).  I want to then set the ACLs so that I'm
the only one that can alter this resource, because it's MINE.  But, in
between the MKWORKSPACE and the subsequent LOCK, the other client comes in
and sets ACLs so that they can write the workspace and I can't!  Ouch.

Null resource went through similar discussions, and was kept for reasons
which apply to MKWORKSPACE the same way they apply to PUT, MKCOL.

lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, June 05, 2001 3:48 PM
> To: DeltaV
> Subject: RE: Deleting versions
>
>
>    From: Lisa Dusseault [mailto:lisa@xythos.com]
>
>    If somebody who's not supposed to, gets in and changes something in
>    between a MKWORKSPACE command and a ACL request, that's a serious
>    problem.  Null resources help avoid that.
>
>    It's not that somebody got their MKWORKSPACE request in ahead of
>    mine --that's not the purpose of null resources at all.
>
> My point was not that a lock can prevent somebody from
> creating the workspace ahead of you, but rather that
> someone locking "your" workspace is no different from
> someone creating a workspace by that name before you
> can lock that URL.
>
> In particular, we are discussing two alternative sequences:
>  LOCK/MKWORKSPACE/ACL/UNLOCK
> or
>  MKWORKSPACE/LOCK/ACL/UNLOCK
>
> In the first sequence, the LOCK may fail (because there already
> is a lock on that URL), so you tell the user "that workspace is
> already in use by another user".
>
> In the second sequence, either the MKWORKSPACE may fail (because
> somebody got in and created a workspace before you) or the LOCK
> may fail (because somebody got in and locked the workspace before
> you).  In either case, you still tell the user "that workspace is
> already in use by another user".
>
> So from the user's perspective, it doesn't matter whether
> or not their client did a LOCK/MKWORKSPACE or a
> MKWORKSPACE/LOCK.  Their request can fail because another
> client "got there before them".
>
> Cheers,
> Geoff

Received on Tuesday, 19 June 2001 17:21:15 UTC