- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Tue, 6 Apr 2004 15:57:28 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
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. 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. 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. Lisa On Apr 6, 2004, at 12:22 PM, Julian Reschke wrote: > Lisa Dusseault wrote: > >> What's been holding up RFC2518bis is lack of clear consensus -- or a >> reliable way of determining it -- on several issues. When we're >> ready, we can reintroduce discussion on those issues and see if now >> there is a clear consensus or a way to determine one. >> The most high-level issue is whether RFC2518bis is intended to be a >> proposed standard or a draft standard. I believe this issue is >> implied by the proposal to remove locking from RFC2518 -- a change >> that big, even though it's a feature removal, may require recycling >> at proposed standard. > > Lisa, > > that proposal has been made *because* of the lack of process; not the > other way around. > > Locking has been optional in RFC2518, so there shouldn't be any > problem whatsoever having a RFC2518bis-minus-locking going to draft. > In fact it'll be easier because locking is the area that needs most > attention. > > That being said, what *is* your position regarding separating locking > into a separate document? > > Regards, Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 6 April 2004 18:58:43 UTC