W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 6 Apr 2004 15:57:28 -0700
Message-Id: <C73CCBAA-881D-11D8-970E-000A95B2BB72@osafoundation.org>
Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
To: Julian Reschke <julian.reschke@gmx.de>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT