Re: locking clarifications/extensions vs BIND draft vs RFC2518bis

I agree with Julian, and strongly advocate approach #1
(take locking out, keep bind out, make everything more modular, for the 
following reasons):

- WebDAV is already a family of specs (3253, ACL, redirect, ordering),
each of which defines an optional feature-package beyond what is defined
in the base spec.  It would be more consistent to handle locking
(which is an optional feature-package) the same way.

- Having a smaller "base WebDAV spec" I believe will make WebDAV more
accessible to new implementors, since the base spec will be less daunting 
in
size.  You don't have to read/understand the locking extensions to
understand versioning, ACL, redirect, or ordering, but the current 
packaging of locking in with the base protocol makes it look like you do.

- It allows us to make more rapid progress on getting the locking
functionality standardized (i.e. it doesn't have to wait until we've
resolved all the other issues in 2518bis).

Cheers,
Geoff


Julian wrote on 01/17/2004 03:52:29 AM:

> 
> In an off-list mail, Jim Whitehead wrote:
> 
>  > I'm tempted to just put BIND right into 2518bis -- worst case
>  > we recycle at
>  > Proposed, which I don't see as being a major adoption
>  > impediment anymore (we
>  > could perhaps call it WebDAV v2, to make it clear that we're making
>  > progress).
> 
> Well, I think that would be a radical change to our strategy...
> 
> Seems that opinions vary between
> 
> 1) take locking out, keep BIND out, make everyhing more modular and
> 2) keep locking in, add BIND, publish RFC2518+BIND (staying at the 
> "proposed level")
> 
> I'd definifively vote for 1).
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

Received on Monday, 2 February 2004 09:15:59 UTC