W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: Creating a separate Locking-bis protocol specification

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 19 Jan 2005 01:42:31 +0100
Message-ID: <41EDACF7.1070209@gmx.de>
To: Ted Hardie <hardie@qualcomm.com>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, webdav <w3c-dist-auth@w3.org>

Ted Hardie wrote:
> 
> A working group has the opportunity when revising a standard
> to declare a previously optional aspect of the original spec to be
> mandatory.  It happens quite frequently in security documents
> (where there is almost a track of new algorithms starting as
> optional, becoming mandatory, then being deprecated), and
> it happens often enough in APPs contexts that no one would
> be surprised if a locking draft that succeeded RFC-2518's
> description of locking declared it mandatory.
> 
> I am not saying that this *should* happen, but the discussion
> of a successor document should take into account that this
> would be in scope for such a document.

Thanks for the clarification, Ted.

Personally, I think this would be a step into the wrong direction. There 
are scenarios out there today that work perfectly fine without locking, 
and there are servers that do not support locking at all, or do not 
support it for specific resources.

Making locking mandatory in future specs will not affect these servers 
(nor the clients that work with them). In the best (or worst?) case they 
will be upgraded to include other -bis features, claim compliance but 
still will not support locking.

On the other hand, clarifying that locking *is* optional, and publishing 
a much simpler base WebDAV spec (sans locking) my actually convince 
potential server implementers to implement those parts of RFC2518 
(namespace operations + metadata) and therefore increase WebDAV's 
acceptance.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 19 January 2005 00:43:16 GMT

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