Subject: Re: Remaining issues with the bind draft -- process

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2004 17:16:25 +0200

Jason Crawford wrote:
> 
> 
> A new LOCKING document?  I'm not sure.  Admittedly LOCK'ing has been a 
> problem for a long time.   Tossing out lock-null resources was a big 
> help.   Is locking holding up 2518bis?  Does creating a new document 
> help?   Let's hear the pros and cons of having a separate document for 
> locking?

We talked about that in January 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>).

Primarily, it reduces the complexity of RFC2518bis, and allows us to 
both clarify and enhance locking without getting problems with 
RFC2518bis advancing in the standards ladder.

And yes, what's holding up 2518bis? The last draft was posted almost six 
months ago, to which I replied with a long list of issues. There was 
almost no feedback.

Regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 6 Apr 2004 12:13:46 -0700

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

On Apr 6, 2004, at 8:16 AM, Julian Reschke wrote:

>
> Jason Crawford wrote:
>> A new LOCKING document?  I'm not sure.  Admittedly LOCK'ing has been  
>> a problem for a long time.   Tossing out lock-null resources was a  
>> big help.   Is locking holding up 2518bis?  Does creating a new  
>> document help?   Let's hear the pros and cons of having a separate  
>> document for locking?
>
> And yes, what's holding up 2518bis? The last draft was posted almost  
> six months ago, to which I replied with a long list of issues. There  
> was almost no feedback.
>
> Regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2004 21:22:59 +0200

> even though it's a feature removal, may require recycling at proposed  

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

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 6 Apr 2004 15:57:28 -0700

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:

>> 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.
>> 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,
>
> 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.
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Apr 2004 01:21:52 +0200

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...

> the same time, then it's mostly a case of document convenience and 

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.

> 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.

> 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

---

From: "Stanley Guan" <[email-masked]>
Date: Mon, 12 Apr 2004 16:42:45 -0700

If a property is set with an empty content as shown below,
is it allowed?  If yes, is it equivalent to "remove"?

Thx,

-Stanley

<?xml version="1.0" encoding="UTF-8"?> 
<D:propertyupdate xmlns:D="DAV:"> 
    <D:set> 
        <D:prop xml:lang="en">
            <D:PropertyA/> 
        </D:prop> 
    </D:set> 
</D:propertyupdate>

---

From: Antony Blakey <[email-masked]>
Date: Tue, 13 Apr 2004 11:18:48 +0930

On 13/04/2004, at 9:12 AM, Stanley Guan wrote:

> is it allowed?

Yes. Although if that's your property, best not to use the DAV: 
namespace.

> If yes, is it equivalent to "remove"?

No. The property will be returned as you have set it i.e. an empty XML 
element, which is different from the property not existing.

Antony Blakey
-------------
He who would make his own liberty secure, must guard even his enemy 
from repression.
   -- Thomas Paine

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Apr 2004 09:47:26 +0200

Antony Blakey wrote:
> Yes. Although if that's your property, best not to use the DAV: namespace.
> 

Antony is right on both counts.

Furthermore it would be nice not to start new threads by replying to 
mails from toher threads, this messes up the threaded display both in 
email clients and the web archive...

Regards, Julian