Subject: RE: Status code for creating lock-null resource

From: [email-masked]
Date: Fri, 15 Jun 2001 15:46:02 +0100

Lock nulls don't deserve the effort of the debate <g>, but I know that
Shaun is a reasonable person so as a courtesty to him...
JimW: there's a couple of typos that need fixing too.

"Hall, Shaun" <[email-masked]> wrote:
> Let us remind ourselves about a few things here (in conjunction
> with null resource emails):
>
> 1) Locking's purpose it to avoid conflict, the lost update problem
> etc (RFC2518 sec 6).

Agreed.

> 2) A null resource MUST NOT appear as a member of its parent
> collection (RFC2518 sec 3).

That's interesting, because Section 7.4 (which I was reading) states that
it MUST appear as a member of its parent collection.<g>
By copy to JimW.  Please add this to the RFC2518 issues list.

I'd have thought that the correct answer was that it MUST appear as a
member of its parent, otherwise the namespace is not reserved.

> 3) A null resource MUST respond with a 404 for ALL methods
> other than PUT, MKCOL, OPTIONS and LOCK (RFC 2518 sec 3).

And UNLOCK.
Geeze, there's another for the list Jim<g>.

Good job you read section 3 Shaun.

> 4) Lock null resources (LNRs) are there to reserve name (RFC2518
> sec 7.4). They are there so a client can reserve the name *before
> they create the resource* (store the "entity"). Admittedly, a
> server may use a file to represent the LNR, but thats an
> implementation detail. Since the name is reserved, it avoids
> potential conflict when the entity is actually stored e.g. with
> a PUT.

I couldn't find the bit about "before they create the resource".
The use of a file is a red herring, I have never suggested that any DAV
server has to use files at all, in fact the opposite, I've always objected
to such statements.
If a lock null resource is not a resource, then what is it?

> 5) Methods performed on LNRs other than PUT, MKCOL, OPTIONS,
> PROPFIND, LOCK and UNLOCK MUST respond with a 404 or 405 (RFC
> 2518 sec 7.4).

Agreed.  The lock-null resource is dictated to respond to methods in a
certain way -- but so are other resource types that are defined in DeltaV
versioning for example.

> 6) If you UNLOCK an LNR, the resource is returned to the null
> resource state (RFC 2518 sec 7.4). This may mean a server
> actually deletes the "file" it used to represent the LNR, but
> thats another implementation detail.

Agreed.  The implementation is irrelevant here.

> The client should assume nothing about how the server implements
> the protocol, in these cases, null resources and LNRs.

Agreed again, it could all be in memory, in a RDBMS, whatever, I don't
care.  However, when a lock-null resource is created, there is a resource
and it has a URI.  The "null resource state" is also a term introduced by
RFC2518 and not properly defined.

> A few people interpret 2) and 3) to mean that a null resource
> doesn't physically exist, which IMHO is convenient. As far as
> the client is concerned, a null resource doesn't exist as per
> 3), and an LNR doesn't exist as per 5).

We can have a very interesting discussion about lock-null resources and
null resources ... I happen to believe that the ideas are bogus but the
problem to solve (your point (1) above) is real.

Tim

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 15 Jun 2001 11:51:13 -0700

> By copy to JimW.  Please add this to the RFC2518 issues list.

Actually, the specification is correct, though it takes a careful read to
see that.

There is a difference between a "null" resource, and a "lock null" resource.
The definition of a "null" resource, as given in Section 3, is correct. Lock
null resources are defined in Section 7.4. A null resource does not belong
to its parent collection, and does not respond to UNLOCK. Perhaps a better
way to express this concept is that what we termed a "null resource" is
really an "unmapped URL". That is, the URL is not mapped to a resource. This
avoids the philosophical question of "is a null resource a resource"? By
calling it an unmapped URL, a "null resource" is clearly not a resource.

A lock-null resource is a null resource that has been locked.  A lock null
resource has diferent properties that a null resource. Specifically, it has
at least the lock discovery properties, and it is a member of its parent's
collection.

> If a lock null resource is not a resource, then what is it?

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.

- Jim