- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Tue, 31 Jul 2001 19:21:09 +1000
- To: w3c-dist-auth@w3.org
On Tue, Jul 31, 2001 at 09:59:59AM +0100, Hall, Shaun wrote:
> I don't think LNRs should be changed at all.
>
> You could use a file to track the lock if you wish and you won't be
> deviating from the RFC.
>
> The RFC doesn't place restrictions on implementation (in this case LNRs) -
> you can basically use whatever you want, so why are you suggesting that the
> semantics should be changed ?
>
> Its an implementation problem, not a protocol problem.
My understanding of the current state of play is that the RFC allows
a LNR to be created which may be either a placeholder for a collection
or a non-collection resource.
Some implementations want to create a temporary file for a lock to store
properties or stop other systems behind the scenes creating the
same reseource - which wont work because MKCOL will then fail because
a file exists.
Some existing implementations (I think it was IIS and/or Apache) if
you unlock without doing a PUT or MKCOL leave a dead file behind.
I think this not conformant to the the RFC.
My general feeling was enough people said "LNR should stay", so it had
been recommended to change the RFC so that
(1) existing implementations could be considered conformant and
(2) new implementations could use a file simplifying compatibility
with other systems.
This is why I thought it had been proposed that the RFC be changed so
LNR's are only for PUT and not MKCOL, and so that servers were not
*required* to clean up if a LOCK was followed by an UNLOCK without
a PUT.
The above may be wrong - I don't have the RFC handy. The above is
simply what I understood of the current state of play.
Alan
Received on Tuesday, 31 July 2001 05:22:01 UTC