Re: locking clarifications/extensions vs BIND draft vs RFC2518bis

+1.

//Stefan

Am 02.02.2004 um 15:15 schrieb Geoffrey M Clemm:

>
> 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:25:02 UTC