W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: Remaining issues with the bind draft -- process

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 5 Apr 2004 23:10:13 +0200
Message-Id: <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de>
Cc: Julian Reschke <julian.reschke@gmx.de>, Patrik Fältström <paf@cisco.com>, Webdav WG <w3c-dist-auth@w3c.org>
To: Lisa Dusseault <lisa@xythos.com>


Am 05.04.2004 um 22:15 schrieb Lisa Dusseault:
> [...]
> Except for the cases where it does matter, like BIND/UNBIND, MOVE and 
> DELETE.  The spec is not clear enough about which methods apply to the 
> binding and which apply to the resource, and when.  The spec doesn't 
> say whether LOCK behaves more like PUT, or more like BIND.

Well, the bind spec does not talk about LOCK. It defines how BIND, 
REBIND and UNBIND
work in the presence of locked resources.

RFC 2518 explicitly adresses the case where multiple URLs to a single 
resource do exist
(see 2518 Chapter 5.1). *RFC 2518* does not explain how LOCK and other 
methods
work in the presence of multiple URLs to the same resource.

The bind spec currently defines the behaviour of namespace operations 
in the presence
of bindings. Something which should have been done in RFC 2518, but 
nobody is
perfect. The bind spec is a good place to do so.

What is not a good idea is to throw the complete, current understanding 
of LOCK
into the bind spec. This is not a failure of the spec, but was 
deliberatly chosen as
the path of wisdom to follow.

LOCK and locked resources in RFC 2518 are, as we know today, 
incompletely specified
in RFC 2518 and have let to interoperability issues. Therefore all 
knowledge was agreed
upon in the GULP and it was also agreed that GULP should find its way 
into RFC 2518bis,
because that's where it should be.

So, it is inaccurate and definitely not helping anyone with any 
implementation issue to
request cleanup of LOCKs from the authors of the bind spec. I 
personally am waiting
for 2 years now that RFC 2518bis makes progress comparable to other 
specs of this
group.

//Stefan
Received on Monday, 5 April 2004 17:10:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT