RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

> Say the MKCOL is executed first, then the LOCK (LNR) second. The MKCOL
> succeeds and creates a collection that isn't locked. The LOCK request
> (attempting to create an LNR) is then performed on this newly created
> collection. What will happen? Since LOCK requests do not
> distinguish locking
> null resources from existing resources, the server will most
> likely lock the
> newly created collection.

THIS is, I believe, an actual problem.  Even with lock-null resources the
way they are, clients MUST be able to tell the difference between a LOCK
that created a new thing, and a LOCK that locked an existing thing.  There's
a simple way to do this: 201 vs. 200.  I believe it was only an oversight
that the list of error codes for lock does not include 201, and I consider
it an errata for 2518.

> This could cause problems for the user
> who created
> the collection because they are not the owner of the lock.

Assuming the user could tell if they created a new collection or not --
what's the problem?

> The above wouldn't happen if you used LNRs for MKCOL as well, because the
> 2nd LOCK request would fail.

I do not think that is correct.  The second lock request would lock the
existing collection -- as you said two paragraphs up.

Lisa