LOCK of resource in non-existent collection & 409 response

In the discussion of PUT, MKCOL, COPY, and MOVE it is made very clear that attempting to create a resource not all of whose parent collections exist MUST result in a 409 response.  But in the discussion of LOCK there is no such requirement.  Why?

At first I thought that perhaps the intent was to allow reserving a particular name, and only if that name was available (i.e., the lock succeeded) would the client create the intermediate collections.  But this scenario, aside from its doubtful utility, seems to contradict the language of section 7.4 which says that a (write-)lock-null resource MUST appear as a member of its parent collection (which doesn't exist in this case).

I realize that the 409 response is already mandated when an attempt to lock an existing collection (other than at depth 0) conflicts with existing locks on members (at some level).  But there is no possible confusion between this use of 409 and the one I am proposing.

So I propose the following clarifications:

1. In section 8.10.1, add the following paragraph:

A LOCK request on a non-existent resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict) response whose body is empty.

2. In section 8.10.7 add the following:

409 (Conflict) ­ Case 1. A non-existent resource cannot be locked at the destination until one or more intermediate collections have been created.  There MUST be no response body.
Case 2. A LOCK request (depth > 0) on an existing collection would conflict with existing locks on members of the collection.  The response body SHOULD be a multi-status indicating the members in conflict.

     dan

Dan Brotsky, tel 408-536-4150, page 888-461-0237
2 way email pager <mailto:page-dbrotsky@adobe.com>

Received on Tuesday, 11 July 2000 01:21:25 UTC