RE: Status code for creating lock-null resource

At 6:13 PM -0400 6/27/01, Jason Crawford wrote:
><<
>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.

Jason, I wasn't suggesting that LNRs, as *currently specified*, are 
regular resources.  I was trying to summarize the back-and-forth 
between Tim and Jim as concluding that they *should* be regular 
resources, that is, that LOCK of an unmapped-URI should create a 
(mostly) standard, no-content resource mapped to that URI.  Sorry if 
this wasn't clear from my message.

The reason for the (mostly) qualifier above, by the way, is that the 
no-content resource created by a LOCK call in this proposal would not 
start off as a collection but could become a collection if a MKCOL 
was then done.  (That's why I was also suggesting we needed a new 
value for the DAV:resourcetype property.)

Geoff is suggesting something slightly different: that LOCK not even 
be allowed on unmapped-URIs.  This also gets rid of LNRs and has the 
advantage that you always know whether something is a collection or 
not.  However it doesn't allow users to simultaneously create and 
LOCK resources for further editing, which bothers me.

>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

yes we have.  It gives a 404 (Not Found).

>but we have specified that PROPFIND give a response to a
>LNR.

well, a different response (207).

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

And the answer is no.  If you do a PUT on /b/a (in the unmapped case) 
it will succeed, but if you do a PUT on /b/a (in the LNR case) it 
will fail with a 423 Locked [or 412 Lock Token not specified as 
Precondition].  It's important not to forget that the big difference 
between an LNR and an NR is the L! :^)

>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.

I think the language about null resources makes these situations seem 
similar when they're not.  That's one of the reasons I like Tim's 
"unmapped-URI" language much more.  IMHO, there is no such thing as a 
"null resource;" there are only resources (some of which have content 
and some of which don't).  If you want locks to be on resources, 
which the spec does, then you either have to have LOCK  create a 
resource (my thinking) or you have to forbid LOCKs on URIs that 
aren't bound to a resource (Geoff's thinking).

Of course the other thought in the air is to make locks be on URIs 
and not resources at all.  But even in this case I think you want to 
disallow locks on unmapped-URIs, because such locks (given the 
semantics of PROPFIND, which is about resources not URIs) would not 
be discoverable nor would they be presentable as "resource state". 
These two outcomes would require a major revamp of the spec.

My guess about where we're going to end up is that LOCKs are 
requested on and attach to the *binding* between a URI and a 
resource, and that they control that resource regardless of which URI 
it is accessed through.  That would disallow LOCKs on unmapped-URIs, 
and it would also account for why LOCKs on a particular URI/resource 
binding are destroyed when that binding is destroyed (such as by a 
MOVE request).  It would also make it easy to say how LOCK and BIND 
are related (in the deltaV spec).

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Wednesday, 27 June 2001 19:55:55 UTC