- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Wed, 20 Jun 2001 16:49:45 -0700
- To: "WebDAV WG" <w3c-dist-auth@w3.org>
> I agree with all of this. (Despite Section 3 of RFC2518 that > states clearly that a null resource is a resource.) When that was written, I had a different model in my head. In that model, a null resource was in fact a resource, but all this resource ever did was respond with "404" to everything. Pretty dull resource. But, I now think the "unmapped URL" is much closer to the idea I wanted to capture by this term. > > A lock-null resource is a null resource that has been locked. > > Or in the new phraseology, "a lock-null resource is an unmapped-URL that > has been locked". > > Hmm, that doesn't sound right does it? A resource is-a URL? Now a lock-null resource would be a *resource* with: * null (or undefined, take your pick) state * properties as defined in 7.4 That is, by reserving the name, you have explicitly created a mapping between a URL and some abstraction, whose state will be fleshed out later. > And not _all_ unmapped-URLs (in DAV compliant namespace) can be locked. > It seems that we need to augment "unmapped-URL" with "where the immediate > parent exists". Good point. > > Since a lock null resource has state, I would claim it is a > > resource. By the act of a client taking out a lock, they have > > likely made a mapping of a URL to a conceptual resource, and > > are int he process of fleshing out the computer representation > > of the conceptual resource. > > Agreed. Moving the server state of an 'unmapped-URL where the immediate > parent exists' from no resource to a resource should, IMHO, respond with > 201 Created. This makes sense to me. My concern is that it would still be nice for the first PUT after a lock-null is created to also return a 201. - Jim
Received on Wednesday, 20 June 2001 19:52:03 UTC