RE: Status code for creating lock-null resource

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" <Shaun.Hall@gbr.xerox.com> 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

Received on Friday, 15 June 2001 10:50:21 UTC