W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Status code for creating lock-null resource

From: Jason Crawford <ccjason@us.ibm.com>
Date: Wed, 27 Jun 2001 18:13:12 -0400
To: "Dan Brotsky" <dbrotsky@Adobe.COM>
Cc: <w3c-dist-auth@w3.org>
Message-ID: <OF32D16FF3.B15B4A2B-ON85256A78.00751204@pok.ibm.com>

1. lock-null resources are just "regular resources" that are required
to respond to certain methods in certain ways.
I'd like to suggest that LNR's are *not* regular resources.  With one
exception that I've noticed, they are just "null resources" that have
a lock affecting them.

Think about a resource /b/ that has a depth lock and /b/a that is a
null resource.  Think about how /b/a behaves.  It's not a LNR resource,
it's just a totally normal "null resource" (or unmapped URL), but it
seems to have the same behavior as a LNR.  The exact same behavior.

Except for one thing...

The exception is that we've defined PROPFIND to not give a response
for /b/a but we have specified that PROPFIND give a response to a

That's the only exception, right?  (This is a genuine question.)

This being the case, I'd like to get away from talking about a LNR as a
normal resource or an particularly odd type of "null resource".  Instead
we can say that we are allowed to lock a null resource that has a parent
and that PROPFIND has special behavior for a null resource that has a lock
rooted on it.  If we can talk about something being "odd", we can talk
about PROPFIND being odd.

As we revise 2518, I think we should give servers much more
discretion about how they handle LOCK/UNLOCK pairs, and possibly we
Given what I've suggested above, I don't think we'd need special behavior
controling the creation/destruction of LNR by LOCK/UNLOCK methods since
there would be no creation/destruction to control.

Anyway... is LNR simply an illusion created by PROPFIND?  Do LNR have
any other behavior that distinguishes them from locked null resource?

Received on Wednesday, 27 June 2001 18:31:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:23 UTC