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

Lock null resources (was RE: Deleting versions)

From: <Tim_Ellison@uk.ibm.com>
Date: Tue, 5 Jun 2001 10:52:34 +0100
To: "DeltaV" <ietf-dav-versioning@w3.org>
Message-ID: <80256A62.00367662.00@d06mta07.portsmouth.uk.ibm.com>

"Lisa Dusseault" <lisa@xythos.com> wrote:
> > No, that's great!<g>  The lock null resource is a nonce concept
> > that is not required by Delta-V.
> Since the lock null resource is enshrined in RFC2518, I do not think
> it's merely a nonce concept (yes, I had to look it up :)

Sorry, what I meant was that "lock-null" resources are wierd.  The notion
was introduced for a unique purpose, and it is probably best if we tolerate
it but don't propogate it in Delta-V.

> But you have a point about the purpose, let me try again and see if I
> get it better:  the lock-null feature allows people to lock something
> before it's created so that there's no window, or gap, when somebody
> else can lock it (after it's created but before the creator has finished
> with it). Agreement?

Clients can't "lock something before it is created".  The problem is how to
reserve the namespace for a future resource.  Since HTTP deals with named
resources RFC2518 had to introduce a 'null' resource to get the namespace
locking without providing a meaningful resource entity.

> > I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a
> > more likely candidate since it is akin to MKCOL.  This would obviously
> > require a modification to RFC2518's statement that the lock null
> > MUST fail methods that are not in the named list.
> I agree.  Rather than relying on the not-fully-prescient wording of
> RFC2518, I'd suggest saying that MKWORKSPACE can be allowed on a
> write-locked null resource, but no other DeltaV methods.
> The modification to RFC2518 is not required because it states "any
> or DAV methods ".  DeltaV methods, obviously, are not covered by this,
> because if HTTP/1.1 was meant to be inclusive, then DAV wouldn't have
> called out explicitly.
> :)


Received on Tuesday, 5 June 2001 06:03:11 UTC

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