Re: Status of RFC2518Bis (Was Re: Remaining issues with the bind draft -- process)

Well, Lisa,

you can't both say that you don't want to separate lock *and* then say 
that RFC2518bis is so far away that any new WebDAV client spec needs to 
clean up the lock mess on it's own. If you really think that BIND can 
not work in absence of lock clarifications, then you already accept that 
*some* lock-related work needs to be done outside RFC2518bis. And 
obviously, this work needs to be entirely compatible to what RFC2518bis 
is going to say, otherwise it's worthless.

Most of the voices I hear want to keep locking, although in a separate 
spec. Geoff and I have already volunteered to write that spec. The whole 
WG process is based on people doing voluntary work; so if you prefer to 
reject that offer, I'd like to see your plan how to proceed (including 
time estimates).

Some more comments inline...

> I don't think it's a great idea to split out locking, but I don't think 
> it's a terrible idea either.  It's not necessary to remove it, so the 
> conservative answer would be to leave it.  OTOH if we were to issue a 
> "WebDAV 100% required core features" RFC and a "WebDAV locking" RFC at 
> the same time, then it's mostly a case of document convenience and 
> perceptions.

Our proposal is to have a WebDAV locking protocol at "proposed" as soon 
as possible, then to issue a RFC2518bis (without locking) at "draft", 
and soon to follow with a LOCKING draft at "draft" (when we'll have 
actual implementation experience with the changes such as If header 
evaluation and DAV:lockroot). So we want to *speed* up the process, not 
slow it down.

> The situation with locking is not that bad, as Julian pointed out 
> particularly because lock-null resources have been removed.  We could 
> simplify further if we think there are still complex or 
> rarely-implemented parts (if header parsing being the most obvious 
> candidate there, or remove shared locks).  But many (most?) clients and 
> servers *do* implement locking, and do so successfully.  There's good 
> interoperability.  It's useful.  Many clients routinely lock files while 
> they're open and being edited.

That's correct. There are use cases for servers that do not need nor 
support locking, but locking is a useful feature, and it should be left 
in the *family* of WebDAV specs, just not necessarily in the base document.

> Given the discussion so far, I fall on the side of keeping RFC 2518 
> whole.  It's not an unmanageable size.  It encourages servers to 
> implement locking if they can, which helps the clients that find locking 
> useful, and is nice for such an important feature of distributed authoring.

So how about giving as an estimate for

- answers to the issues raised against the latest rfc2518bis (-05) and
- a release of a -06 draft?

Regards,

Julian

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

Received on Tuesday, 6 April 2004 19:22:57 UTC