W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001


From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Tue, 31 Jul 2001 19:21:09 +1000
To: w3c-dist-auth@w3.org
Message-ID: <20010731192109.K14768@io.mds.rmit.edu.au>
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.

Received on Tuesday, 31 July 2001 05:22:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC