W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Deleting versions

From: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 6 Jun 2001 09:00:20 -0700
To: "Clemm, Geoff" <gclemm@rational.com>, "DeltaV" <ietf-dav-versioning@w3.org>
Are DeltaV servers then not required to support locking at all?  Lock-null
comes along with lock.  I can (barely) beleive that a server might implement
DeltaV but not support locking.  In fact, you acknowledge in section 14 that
lock-null may be implemented:

"Non-version-controlled bindings are not under version control, and
therefore can be added or deleted without checking out the
version-controlled collection.  This feature is essential for the support of
lock null resources, since a lock null resource is a temporary internal
member of a collection that should only exist for the duration of the lock,
and should not be captured in the version history of that collection."

You're doing what Greg (justly) accused you of and leaving things to be
inferred, or out of the spec entirely.  If DeltaV says nothing, then
implementors and servers that do locking and deltaV will be left without
guidance, on an issue over which the experts (heh) have argued.  Their
implementations will differ.

Why not state that MKCOLLECTION and MKACTIVITY can be used on lock-null
resources if they would be legal otherwise?  If you object, then please make
your arguments against the concept, but do not allow the spec to remain


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, June 06, 2001 8:07 AM
> To: DeltaV
> 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
> 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:
> > or
> >
> > 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 Wednesday, 6 June 2001 12:01:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC