Subject: locking clarifications/extensions vs BIND draft vs RFC2518bis

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jan 2004 15:03:33 +0100

Hi,

I've been thinking about the best way to get the BIND spec out without 
neglecting the fact that the interaction between locks and multiple 
bindings could use a clarification :-)

Several approaches come to mind...:

1) Add a section to the BIND spec. From a procedural point of view that 
would be easiest, but it would IMHO be short-sighted. The aforementioned 
clarification should be independant of the BIND spec, and in particular 
needs to be compatible to whatever RFC2518bis will say when it's finished.

2) Come up with a separate spec that updates RFC2518 and just summarizes 
all that we changed or intend to change regarding locking (like 
deprecation of lock-null resources, fixes to LOCK and lock refresh, If 
header syntax, and lockdiscovery extensions). That would still be a 
"draft standard" as RFC2518, but it would make things easier for 
RFC2518bis as well, because all these changes would be written down in a 
spec that came out prior to the revision, so wouldn't be "new" anymore. 
It would also encourage implementors to actually *implement* these 
changes and extensions *before* RFC2518bis comes out.

3) A drastic approach would be to de-couple locking entirely from 
RFC2518 ("updating" RFC2518 again). That would look similar to how 
RFC3253 is organized (locking would become an optional module, and 
everything that needs to be said about locking would reside in that 
separate document). Of course that approach would have a significant 
impact on RFC2518bis, because optimally, it wouldn't say anything about 
locking anymore either.

 From a purely technical point of view, choice 3) has a lot of appeal. 
Separating the specs should make both more accessible, the base spec 
would be MUCH simpler, and both specs would be easier to update. Also, 
getting people to implement basic WebDAV minus locking may be a lot 
easier if it's decoupled. Of course, that's also the option that would 
cause the biggest amount of editorial work...

On the other hand, I'd understand if people think that we shouldn't mess 
around too much with both RFC2518 and RFC2518bis. In that case, I see 
option 2) as a workable alternative. Of course, that approach only makes 
sense if we can make that activity an official WebDAV working group work 
item.

Feedback appreciated,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jan 2004 21:00:17 +0100

Jason wrote in an off-list mail:

 > > 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).
 >
 > I assume there are platforms that would have difficulty implementing
 > bindings so I suspect we'd want it to be optional.  I'd think
 > that'd be
 > easier as a separate draft.   But I think it's fine, and in

I can't imagine problems implementing bindings. I *can* imagine problems 
implenting *multiple* bindings to the same resource. That's fine. The 
BIND spec doesn't require servers to actually support multiple bindings, 
it just defines how these must work (and how they can be 
discovered/authored) *if* they are supported.

 > fact advisible,
 > to establish the basic vocabulary of bindings in 2518 and let
 > the bindings
 > draft just cover the optional issues and clarifications for bindings
 > and multiple bindings.

I do agree that RFC2518bis *should* remove any inconsistencies with 
BIND, where present. Note that one major problem was the definition for 
DELETE, which (in RFC2518) required to remove all other bindings to the 
resource as well. AFAIK, this has been fixed in RFC2518bis.

So besides the fact that RFC2518bis talks about "internal members" 
rather than bindings, I'm not really sure that anything *needs* to be 
fixed. Geoff?

Regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jan 2004 21:12:01 +0100

In an off-list mail, Geoff Clemm wrote:

 > I would strongly advocate separating locking from base WebDAV
 > functionality
 > 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).

I agree on all these points. However, for this plan to work we need

- buy-in from the RFC2518bis authors (Lisa and Jason),
- volunteers for the new document and
- broad support from the working group members (that is, this mailing list)

Regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Jan 2004 09:52:29 +0100

In an off-list mail, Jim Whitehead wrote:

 > I'm tempted to just put BIND right into 2518bis -- worst case
 > we recycle at

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 17 Jan 2004 07:53:34 -0500

I am willing to work with Jason on this document.

Cheers,
Geoff

Julian wrote on 01/16/2004 03:12:01 PM:

>  > less daunting in size.  You don't have to
>  > read/understand the locking extensions to

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 17 Jan 2004 07:56:41 -0500

Actually, I meant to say "I am willing to work with Julian on this 
document",
(but I am in fact also willing to work with Jason on this document :-).

Cheers,
Geoff