Re: Creating a separate Locking-bis protocol specification

Jim Whitehead wrote:
> Moving locking issues into another draft doesn't reduce the complexity of
> the locking issues; it just moves text. If an issue is contentious in
> 2518bis, it will still be contentious in 2518bis-lock. 

It reduces the amount of work for the editors of RFC2518bis (who seem to 
have trouble spending time on it). Also, as far as I can tell, almost 
all of the issues with locking have been resolved on the mailing list 
(see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>).

> Moving locking to a separate document won't speed the overall process,
> because approval of this document will still be gated on completion of the
> rest of the 2518bis edits, to ensure there aren't inconsistencies.

That would be only true if the intent would be to submit both of them as 
"Draft". *My* intent (when I made that proposal initially and while 
working on it) was to submit it as "Proposed", so RFC2518bis (base) and 
the locking spec can really become independent of each.

So the timeline would be something like:

#1: finish the separated locking spec, updating RFC2518, publish as 
"proposed"

#2: finish RFC2518bis minus locking, publish as "draft"

#3: advance the locking spec to draft as well (another competing spec to 
go to "draft" would be DeltaV).

As far as I can tell, once the WG agrees on that plan we could be done 
with #1 this spring.

> Locking should not be split out from the rest of 2518bis. 

I'd be tempted to agree if I had any idea about when work will continue 
on RFC2518bis.

Best regards, Julian

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

Received on Wednesday, 19 January 2005 01:24:58 UTC