Subject: Re: locking clarifications/extensions vs BIND draft vs RFC2518bis

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 2 Feb 2004 09:15:14 -0500

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
>

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 2 Feb 2004 15:22:10 +0100

+1.

//Stefan

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 02 Feb 2004 11:30:50 -0800

+1, for much the same reasons outlined in Geoff's post below.

Q: 2518 defines two levels of compliance, depending on whether locking 
is supported or not - would it make sense to try and extend this 
approach to cover all of the related specs?

Cheers,
Elias

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 2 Feb 2004 15:30:26 -0500

Yes, the specs all use the DAV: header to indicate what they support.
The only difference is that rather than using integers (1, 2), they use
strings.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2004 21:33:18 +0100

Elias Sinderson wrote:
 > ...

I thought that this is what they're doing already?

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 6 Feb 2004 14:27:13 -0800

Here's another idea.  What if we made locking required in the next
version of WebDAV?  Servers that support RFC2518 can always claim 
support for RFC2518 without changes but most servers support locking
anyway and wouldn't find this difficult.  For clients of course it's
no change at all.  Then WebDAV core would have almost no options.

lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Monday, February 02, 2004 12:33 PM
> To: Elias Sinderson
> Cc: [email-masked]
> Subject: Re: locking clarifications/extensions vs BIND draft 
> vs RFC2518bis
> 
> 
> 
> Elias Sinderson wrote:
> >

---

From: Julian Reschke <[email-masked]>
Date: Sat, 07 Feb 2004 09:31:56 +0100

> no change at all.  Then WebDAV core would have almost no options.

I think *that's' a bad idea. There are lots of servers that do not allow 
locking, or that do allow locking, but not on all resources.  Let's make 
things simpler, not more complicated.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 7 Feb 2004 11:55:35 -0500

I agree with Julian.  Implementing locking properly is not a trivial
task, and there will always be fine-grained resources for which locking
is not appropriate on a server that supports locking.  Interoperable
clients need to understand that locking may not be provided on all
servers, or on all resources on a server.

Cheers,
Geoff