RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent
>
> Here is a proposal I think someone else posted a while back.

Very close:

> - LOCK on existing resource stays as is
>
> - LOCK on unmapped URI should (must? can?) create a
> non-collection resource

MUST if the namespace is kept consistent.

> - UNLOCK on the same URI without a PUT should (can?) delete the resource

Same holds true for LOCK timeout. should or can is the question.

> - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad).
>
> This allows implementations to create a file in the underlying file
> system if they want to.
>
> In order to completely remove the concept of LNR, PROPFIND must be
> cleaned up too. Here are some alternatives:
>
> (1) I would say a LOCK on a unmapped URI MUST create a resource
> and lock it.
>     That way it will appear in PROPFIND's. A PUT on the resource
> would then
>     say 200, not 201.

That's what I would expect.

> (2) If a LOCK creates a temporary file, PROPFIND returns it. If a
> LOCK does
>     not create a temporary file, PROPFIND does not return it.
>
> (3) Keep more of the current semantics. PROPFIND returns info about LNR
>     resources.  If your implementation creates a temporary file, then your
>     implementation does not have to worry about LNR (but it stays in
>     the standard as a concept).

That makes life of clients unnecessary difficult.

> I was actually going to propose a new optional flag to say for locks
> that the intent is to create a non-collection resource or a collection
> resource (where non-collection is the default for backwards
> compatibility). The idea is in order to be able to create a temporary
> placeholder resource in the underlying file system, get the client to
> say in advance whether it is going to PUT or MKCOL. Have a default
> value of PUT means MS Word will probably be conformant as is (or pretty
> close) for example.
>
> [removed neuronal interference patterns]

The question is what to do with such resources when they are unlocked
or the lock times out. Possibilities:

1. If the resource disappears, WebDAV still has the concepts of LNRs and
servers have to track resources created by a LOCK.

2. If the resource stays as an empty file, the concept of LNRs can be
removed
completely from the spec. Additionally, servers would have no need to
track resources created by LOCK.

I favour the second approach. It gives most bang for less bugs.

//Stefan

Received on Thursday, 2 August 2001 04:19:01 UTC