From w3c-dist-auth-request@w3.org  Tue Jun  1 00:53:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07153
	for <webdav-archive@lists.ietf.org>; Tue, 1 Jun 2004 00:53:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6E3E3A17D0; Tue,  1 Jun 2004 00:53:03 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 671CAA1919
	for <w3c-dist-auth@listhub.w3.org>; Tue,  1 Jun 2004 00:53:00 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BV1Gl-0005rO-AS
	for w3c-dist-auth@w3.org; Tue, 01 Jun 2004 00:52:59 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i514qq2t008899 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 31 May 2004 21:52:52 -0700
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by bandage.seagull.net (8.12.10) with ESMTP id i514qpQe008843 sender ccjason@us.ibm.com; Mon, 31 May 2004 21:52:51 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i514qe18435920; Tue, 1 Jun 2004 00:52:40 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i514rKrL113650; Tue, 1 Jun 2004 00:53:20 -0400
To: nnw3c-dist-auth___at___w3.org@smallcue.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OF42489894.EE5A9D61-ON85256EA6.001A53BC-85256EA6.001AC6C5@us.ibm.com>
Date: Tue, 1 Jun 2004 00:52:30 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF199 | April 27, 2004) at 06/01/2004 00:52:40, Serialize complete at 06/01/2004 00:52:40
Content-Type: multipart/alternative; boundary="=_alternative 001A957885256EA6_="
Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/OF42489894.EE5A9D61-ON85256EA6.001A53BC-85256EA6.001AC6C5@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8536
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040601045303.6E3E3A17D0@frink.w3.org>
Resent-Date: Tue,  1 Jun 2004 00:53:03 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 001A957885256EA6_=
Content-Type: text/plain; charset="us-ascii"

On Monday, 05/31/2004 at 07:17 AST, Geoffrey M Clemm/Lexington/IBM@IBMUS 
wrote:
> Changing back is fine with me. 

Also fine with me.

--=_alternative 001A957885256EA6_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">On Monday, 05/31/2004 at 07:17 AST, Geoffrey M Clemm/Lexington/IBM@IBMUS wrote:<br>
&gt; Changing back is fine with me. </font>
<br>
<br><font size=2 face="sans-serif">Also fine with me.</font>
<br>
--=_alternative 001A957885256EA6_=--



From w3c-dist-auth-request@w3.org  Wed Jun  2 09:17:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20557
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 09:17:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 65D34A11B2; Wed,  2 Jun 2004 09:17:12 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 396EBA12DF
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 09:17:08 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVVc3-0008O4-HC
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 09:16:59 -0400
Received: (qmail 17091 invoked by uid 65534); 2 Jun 2004 13:16:28 -0000
Received: from p508247A6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.71.166)
  by mail.gmx.net (mp014) with SMTP; 02 Jun 2004 15:16:28 +0200
X-Authenticated: #1915285
Message-ID: <40BDD32B.1020304@gmx.de>
Date: Wed, 02 Jun 2004 15:16:27 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BDD32B.1020304@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8537
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602131712.65D34A11B2@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 09:17:12 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I note that the issue above 
(<http://www.webdav.org/wg/rfcdev/issues.htm>) mentions:

"Another seems to be to specify what lock to refresh in a lock refresh 
request."

RFC2518bis-05 (and possibly earlier versions) resolve this by using the 
"Lock-Token" header to indicate which lock to refresh (I think this was 
dicussed during an interop meeting; but this resolution doesn't appear 
on the issues list like it should!).

I *do* agree that "Lock-Token" technically is a better choice to select 
the lock to be refreshed, however...:

- RFC2518bis is unclear about whether you'll still need to specify the 
"If" header in the request (because one may argue that the LOCK refresh 
request is modifying the locked state of the resource)

- RFC2518bis says it is "recommended" to support the old marshalling 
("If" header). I think for backwards compatibilty with existing client 
this should be a "REQUIRED".

Finally, I'm not so sure that this change really makes sense. As far as 
I can tell, no widely used server currently implements the new 
marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, 
clients will likely continue to use the old format anyway, because after 
all it works just fine; and IIS is unlikely to be upgraded anytime soon :-)

So either

1) roll back the change in RFC2518bis, or

2) add both issue and resolution, and also clarify the issues mentioned 
above in new RFC2158bis text

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Wed Jun  2 09:45:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21892
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 09:45:49 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 62FAAA0AE4; Wed,  2 Jun 2004 09:45:50 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EE0A6A0AE4
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 09:45:45 -0400 (EDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVW3t-0005uY-QY
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 09:45:45 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i52DjE4N429858
	for <w3c-dist-auth@w3.org>; Wed, 2 Jun 2004 09:45:14 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i52Djs5p045786
	for <w3c-dist-auth@w3.org>; Wed, 2 Jun 2004 09:45:54 -0400
In-Reply-To: <40BDD32B.1020304@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF31CD8C21.B9D8B4D9-ON85256EA7.004A5DB7-85256EA7.004B8D5F@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 2 Jun 2004 09:45:09 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF285 | May 28, 2004) at
 06/02/2004 09:45:00,
	Serialize complete at 06/02/2004 09:45:00
Content-Type: multipart/alternative; boundary="=_alternative 004B8D5E85256EA7_="
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/OF31CD8C21.B9D8B4D9-ON85256EA7.004A5DB7-85256EA7.004B8D5F@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8538
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602134550.62FAAA0AE4@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 09:45:50 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 004B8D5E85256EA7_=
Content-Type: text/plain; charset="US-ASCII"

Given the behavior of IIS5 and Apache/moddav2, 
it sounds we're pretty much stuck with the 2518 marshalling,
so I'd vote to just roll back the change in 2518bis.

Cheers,
Geoff

Julian wrote on 06/02/2004 09:16:27 AM:

> 
> Hi,
> 
> I note that the issue above 
> (<http://www.webdav.org/wg/rfcdev/issues.htm>) mentions:
> 
> "Another seems to be to specify what lock to refresh in a lock refresh 
> request."
> 
> RFC2518bis-05 (and possibly earlier versions) resolve this by using the 
> "Lock-Token" header to indicate which lock to refresh (I think this was 
> dicussed during an interop meeting; but this resolution doesn't appear 
> on the issues list like it should!).
> 
> I *do* agree that "Lock-Token" technically is a better choice to select 
> the lock to be refreshed, however...:
> 
> - RFC2518bis is unclear about whether you'll still need to specify the 
> "If" header in the request (because one may argue that the LOCK refresh 
> request is modifying the locked state of the resource)
> 
> - RFC2518bis says it is "recommended" to support the old marshalling 
> ("If" header). I think for backwards compatibilty with existing client 
> this should be a "REQUIRED".
> 
> Finally, I'm not so sure that this change really makes sense. As far as 
> I can tell, no widely used server currently implements the new 
> marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, 
> clients will likely continue to use the old format anyway, because after 

> all it works just fine; and IIS is unlikely to be upgraded anytime soon 
:-)
> 
> So either
> 
> 1) roll back the change in RFC2518bis, or
> 
> 2) add both issue and resolution, and also clarify the issues mentioned 
> above in new RFC2158bis text
> 
> Best regards, Julian
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

--=_alternative 004B8D5E85256EA7_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Given the behavior of IIS5 and Apache/moddav2, </tt></font>
<br><font size=2><tt>it sounds we're pretty much stuck with the 2518 marshalling,</tt></font>
<br><font size=2><tt>so I'd vote to just roll back the change in 2518bis.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/02/2004 09:16:27 AM:<br>
<br>
&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; I note that the issue above <br>
&gt; (&lt;http://www.webdav.org/wg/rfcdev/issues.htm&gt;) mentions:<br>
&gt; <br>
&gt; &quot;Another seems to be to specify what lock to refresh in a lock
refresh <br>
&gt; request.&quot;<br>
&gt; <br>
&gt; RFC2518bis-05 (and possibly earlier versions) resolve this by using
the <br>
&gt; &quot;Lock-Token&quot; header to indicate which lock to refresh (I
think this was <br>
&gt; dicussed during an interop meeting; but this resolution doesn't appear
<br>
&gt; on the issues list like it should!).<br>
&gt; <br>
&gt; I *do* agree that &quot;Lock-Token&quot; technically is a better choice
to select <br>
&gt; the lock to be refreshed, however...:<br>
&gt; <br>
&gt; - RFC2518bis is unclear about whether you'll still need to specify
the <br>
&gt; &quot;If&quot; header in the request (because one may argue that the
LOCK refresh <br>
&gt; request is modifying the locked state of the resource)<br>
&gt; <br>
&gt; - RFC2518bis says it is &quot;recommended&quot; to support the old
marshalling <br>
&gt; (&quot;If&quot; header). I think for backwards compatibilty with existing
client <br>
&gt; this should be a &quot;REQUIRED&quot;.<br>
&gt; <br>
&gt; Finally, I'm not so sure that this change really makes sense. As far
as <br>
&gt; I can tell, no widely used server currently implements the new <br>
&gt; marshalling (I just tested IIS5, Apache/moddav2 and our own). Also,
<br>
&gt; clients will likely continue to use the old format anyway, because
after <br>
&gt; all it works just fine; and IIS is unlikely to be upgraded anytime
soon :-)<br>
&gt; <br>
&gt; So either<br>
&gt; <br>
&gt; 1) roll back the change in RFC2518bis, or<br>
&gt; <br>
&gt; 2) add both issue and resolution, and also clarify the issues mentioned
<br>
&gt; above in new RFC2158bis text<br>
&gt; <br>
&gt; Best regards, Julian<br>
&gt; <br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; <br>
</tt></font>
--=_alternative 004B8D5E85256EA7_=--



From w3c-dist-auth-request@w3.org  Wed Jun  2 10:17:15 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24066
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:17:15 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9FC3CA0AA3; Wed,  2 Jun 2004 10:17:16 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4C0FDA0AA3
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 10:17:13 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVWYL-00032f-6U
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 10:17:13 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i52EHBJe019098 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Wed, 2 Jun 2004 07:17:11 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bandage.seagull.net (8.12.10) with ESMTP id i52EHAGK019004 sender ccjason@us.ibm.com; Wed, 2 Jun 2004 07:17:11 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i52EGr4N457216; Wed, 2 Jun 2004 10:16:53 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i52EHN5p075682; Wed, 2 Jun 2004 10:17:23 -0400
To: nnw3c-dist-auth___at___w3.org@smallcue.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OFE0B53AC3.9CC6FA89-ON85256EA7.004DBC3D-85256EA7.004E6900@us.ibm.com>
Date: Wed, 2 Jun 2004 10:16:29 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF199 | April 27, 2004) at 06/02/2004 10:16:42, Serialize complete at 06/02/2004 10:16:42
Content-Type: multipart/alternative; boundary="=_alternative 004E4EDB85256EA7_="
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/OFE0B53AC3.9CC6FA89-ON85256EA7.004DBC3D-85256EA7.004E6900@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8539
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602141716.9FC3CA0AA3@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 10:17:16 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 004E4EDB85256EA7_=
Content-Type: text/plain; charset="us-ascii"

> > I *do* agree that "Lock-Token" technically is a better choice to 
select 
> > the lock to be refreshed, however...:
> > 
> > - RFC2518bis is unclear about whether you'll still need to specify the 

> > "If" header in the request (because one may argue that the LOCK 
refresh 
> > request is modifying the locked state of the resource)
> > 
> > - RFC2518bis says it is "recommended" to support the old marshalling 
> > ("If" header). I think for backwards compatibilty with existing client 

> > this should be a "REQUIRED".
> > 
> > Finally, I'm not so sure that this change really makes sense. As far 
as 
> > I can tell, no widely used server currently implements the new 
> > marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, 
> > clients will likely continue to use the old format anyway, because 
after 
> > all it works just fine; and IIS is unlikely to be upgraded anytime 
soon :-)
> > 
> > So either
> > 
> > 1) roll back the change in RFC2518bis, or
> > 
> > 2) add both issue and resolution, and also clarify the issues 
mentioned 
> > above in new RFC2158bis text

The old way of overloading If seems pretty lame.   Can't new clients do 
both?
Can't new servers detect which approach in being used?

I wouldn't require servers to support the old way.  Supporting the old way 
is common sense but at some point we should encourage the movement to the 
new approach.

J.
--=_alternative 004E4EDB85256EA7_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; &gt; I *do* agree that &quot;Lock-Token&quot; technically is a better choice to select <br>
&gt; &gt; the lock to be refreshed, however...:<br>
&gt; &gt; <br>
&gt; &gt; - RFC2518bis is unclear about whether you'll still need to specify the <br>
&gt; &gt; &quot;If&quot; header in the request (because one may argue that the LOCK refresh <br>
&gt; &gt; request is modifying the locked state of the resource)<br>
&gt; &gt; <br>
&gt; &gt; - RFC2518bis says it is &quot;recommended&quot; to support the old marshalling <br>
&gt; &gt; (&quot;If&quot; header). I think for backwards compatibilty with existing client <br>
&gt; &gt; this should be a &quot;REQUIRED&quot;.<br>
&gt; &gt; <br>
&gt; &gt; Finally, I'm not so sure that this change really makes sense. As far as <br>
&gt; &gt; I can tell, no widely used server currently implements the new <br>
&gt; &gt; marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, <br>
&gt; &gt; clients will likely continue to use the old format anyway, because after <br>
&gt; &gt; all it works just fine; and IIS is unlikely to be upgraded anytime soon :-)<br>
&gt; &gt; <br>
&gt; &gt; So either<br>
&gt; &gt; <br>
&gt; &gt; 1) roll back the change in RFC2518bis, or<br>
&gt; &gt; <br>
&gt; &gt; 2) add both issue and resolution, and also clarify the issues mentioned <br>
&gt; &gt; above in new RFC2158bis text</font>
<br>
<br><font size=2 face="sans-serif">The old way of overloading If seems pretty lame. &nbsp; Can't new clients do both?</font>
<br><font size=2 face="sans-serif">Can't new servers detect which approach in being used?</font>
<br><font size=2 face="sans-serif"><br>
I wouldn't require servers to support the old way. &nbsp;Supporting the old way is common sense but at some point we should encourage the movement to the new approach.</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
--=_alternative 004E4EDB85256EA7_=--



From w3c-dist-auth-request@w3.org  Wed Jun  2 10:26:58 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24871
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:26:57 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D7330A086A; Wed,  2 Jun 2004 10:26:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C0A28A086A
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 10:26:54 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVWhi-0004be-Mr
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 10:26:54 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i52EQrkQ022173 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 2 Jun 2004 07:26:53 -0700
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i52EQqSj022054 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 2 Jun 2004 07:26:53 -0700
Received: (qmail 5762 invoked by uid 65534); 2 Jun 2004 14:26:41 -0000
Received: from p508247A6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.71.166) by mail.gmx.net (mp025) with SMTP; 02 Jun 2004 16:26:41 +0200
Message-ID: <40BDE39E.6080700@gmx.de>
Date: Wed, 02 Jun 2004 16:26:38 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Jason Crawford <ccjason@us.ibm.com>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BDE39E.6080700@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8540
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602142658.D7330A086A@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 10:26:58 -0400 (EDT)


Jason Crawford wrote:

> The old way of overloading If seems pretty lame.   Can't new clients do 
> both?

Agreed, but it works (if it ain't broke, don't fix it). Why are we 
adding completely new requirements for both servers and clients with the 
inevitable interoperability issues if the present protocol does what 
it's supposed to do?

> Can't new servers detect which approach in being used?

They could, if we clearly define how. So far we haven't.

> I wouldn't require servers to support the old way.  Supporting the old 
> way is common sense but at some point we should encourage the movement 
> to the new approach.

Well, that would break Microsoft Office. I don't think people will be 
very interested in a spec revision that doesn't work with it.

IMHO the only thing we should say is that LOCK without a request body 
*with* an If header will refresh all locks on the resource identified by 
the request URI (possibly deprecating the use of the Time-Out request 
header here -- I don't think there's a strong use case for changing the 
timeout after the lock already exists; and as far as I know existing 
servers do not support it anyway).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun  2 10:37:25 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25773
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:37:25 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C946AA0C67; Wed,  2 Jun 2004 10:37:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3629EA0672
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 10:37:23 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVWrq-00068K-Sh
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 10:37:23 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i52EbMkQ026864 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 2 Jun 2004 07:37:22 -0700
Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i52EbKF2026841 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 2 Jun 2004 07:37:20 -0700
Received: (qmail 30726 invoked by uid 65534); 2 Jun 2004 14:37:09 -0000
Received: from p508247A6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.71.166) by mail.gmx.net (mp009) with SMTP; 02 Jun 2004 16:37:09 +0200
Message-ID: <40BDE60E.1040400@gmx.de>
Date: Wed, 02 Jun 2004 16:37:02 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jason Crawford <ccjason@us.ibm.com>,
        nnw3c-dist-auth___at___w3.org@smallcue.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BDE60E.1040400@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8541
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602143725.C946AA0C67@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 10:37:25 -0400 (EDT)


Julian Reschke wrote:

> IMHO the only thing we should say is that LOCK without a request body 
> *with* an If header will refresh all locks on the resource identified by 
> the request URI (possibly deprecating the use of the Time-Out request 
> header here -- I don't think there's a strong use case for changing the 
> timeout after the lock already exists; and as far as I know existing 
> servers do not support it anyway).

Make that... "...will refresh all locks on the resource identified by 
the request URI that have been submitted in the 'If' header..."

Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun  2 11:00:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26643
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:00:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0E4EFA10C9; Wed,  2 Jun 2004 11:00:44 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6D3AFA13F4
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 11:00:41 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVXEP-0001I3-7X
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 11:00:41 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i52F0ePS002263 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Wed, 2 Jun 2004 08:00:40 -0700
Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i52F0evk002253 sender lisa@osafoundation.org for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 2 Jun 2004 08:00:40 -0700
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i52ExeJL011639 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 2 Jun 2004 07:59:42 -0700
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com,
        Jason Crawford <ccjason@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 2 Jun 2004 08:00:24 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8542
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602150044.0E4EFA10C9@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 11:00:44 -0400 (EDT)


On Jun 2, 2004, at 7:26 AM, Julian Reschke wrote:

>
> Jason Crawford wrote:
>
>> The old way of overloading If seems pretty lame.   Can't new clients 
>> do both?
>
> Agreed, but it works (if it ain't broke, don't fix it). Why are we 
> adding completely new requirements for both servers and clients with 
> the inevitable interoperability issues if the present protocol does 
> what it's supposed to do?

We have been conservative about changes in RFC2518bis, generally only 
changing things where interoperability testing shows that there is a 
problem.  In this case, confusion over where to put the lock token in 
refresh requests came up in actual implementations and early 
interoperability testing.  In addition, it was unclear what to do if 
multiple lock tokens appeared in the If header (the Lock-Token header 
allows only one).  IOW, the present protocol didn't quite do what it 
was supposed to do.

> IMHO the only thing we should say is that LOCK without a request body 
> *with* an If header will refresh all locks on the resource identified 
> by the request URI (possibly deprecating the use of the Time-Out 
> request header here -- I don't think there's a strong use case for 
> changing the timeout after the lock already exists; and as far as I 
> know existing servers do not support it anyway).
>

It doesn't really fit our shared lock model (such as it is) to refresh 
all locks on the resource.  Some may have been taken out by other 
users.

Lisa



From w3c-dist-auth-request@w3.org  Wed Jun  2 11:06:37 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26876
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:06:36 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E375AA0C3D; Wed,  2 Jun 2004 11:06:18 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B8D70A1C67
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 11:06:16 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVXJo-0001sM-H4
	for w3c-dist-auth@w3.org; Wed, 02 Jun 2004 11:06:16 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i52F6FGu004628 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 2 Jun 2004 08:06:15 -0700
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i52F6EmM004590 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 2 Jun 2004 08:06:14 -0700
Received: (qmail 12123 invoked by uid 65534); 2 Jun 2004 15:06:02 -0000
Received: from p508247A6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.71.166) by mail.gmx.net (mp009) with SMTP; 02 Jun 2004 17:06:02 +0200
Message-ID: <40BDECD8.7090009@gmx.de>
Date: Wed, 02 Jun 2004 17:06:00 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com,
        Jason Crawford <ccjason@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BDECD8.7090009@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8543
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602150618.E375AA0C3D@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 11:06:18 -0400 (EDT)


Lisa Dusseault wrote:

> We have been conservative about changes in RFC2518bis, generally only 
> changing things where interoperability testing shows that there is a 
> problem.  In this case, confusion over where to put the lock token in 
> refresh requests came up in actual implementations and early 
> interoperability testing.  In addition, it was unclear what to do if 
> multiple lock tokens appeared in the If header (the Lock-Token header 
> allows only one).  IOW, the present protocol didn't quite do what it was 
> supposed to do.

I agree that it is confusing. However, popular clients and servers seems 
to agree on how it works, so why don't we just write that down?

>> IMHO the only thing we should say is that LOCK without a request body 
>> *with* an If header will refresh all locks on the resource identified 
>> by the request URI (possibly deprecating the use of the Time-Out 
>> request header here -- I don't think there's a strong use case for 
>> changing the timeout after the lock already exists; and as far as I 
>> know existing servers do not support it anyway).
>>
> 
> It doesn't really fit our shared lock model (such as it is) to refresh 
> all locks on the resource.  Some may have been taken out by other users.

Yep. It should refresh exactly those that have been submitted in the 
"If" header.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun  2 11:16:53 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27145
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:16:53 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 12D5FA06B1; Wed,  2 Jun 2004 11:16:53 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 69654A06B1
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 11:16:50 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVXU2-0003cN-9j
	for w3c-dist-auth@w3c.org; Wed, 02 Jun 2004 11:16:50 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i52FFeJL012375
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 2 Jun 2004 08:15:42 -0700
In-Reply-To: <40BDECD8.7090009@gmx.de>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 2 Jun 2004 08:16:22 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8544
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602151653.12D5FA06B1@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 11:16:53 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On Jun 2, 2004, at 8:06 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> We have been conservative about changes in RFC2518bis, generally only 
>> changing things where interoperability testing shows that there is a 
>> problem.  In this case, confusion over where to put the lock token in 
>> refresh requests came up in actual implementations and early 
>> interoperability testing.  In addition, it was unclear what to do if 
>> multiple lock tokens appeared in the If header (the Lock-Token header 
>> allows only one).  IOW, the present protocol didn't quite do what it 
>> was supposed to do.
>
> I agree that it is confusing. However, popular clients and servers 
> seems to agree on how it works, so why don't we just write that down?

One problem is that popular clients and servers only do exclusive 
locks, so current practice is not sufficient to answer the unanswered 
questions in RFC2518.  We could cut shared locks from WebDAV, require 
that only one resource's lock may be updated by a LOCK refresh request, 
and that would codify existing practice.  I believe that works even for 
collection locks since a collection lock may not overlap another 
exclusive lock.  So the new requirements would be something like:

  - The LOCK refresh request MUST address the resource that was locked 
(the root of the lock)
  - The If header on the LOCK refresh request MUST contain one (and only 
one) lock token, the token for the lock that is to be refreshed
  - The server MUST reject the request if the request-URI and token do 
not match

Lisa



From w3c-dist-auth-request@w3.org  Wed Jun  2 11:34:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28808
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:34:38 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9A0FFA166C; Wed,  2 Jun 2004 11:34:40 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B438CA1912
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 11:34:38 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVXlG-0005uw-B2
	for w3c-dist-auth@w3c.org; Wed, 02 Jun 2004 11:34:38 -0400
Received: (qmail 28895 invoked by uid 65534); 2 Jun 2004 15:34:07 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10)
  by mail.gmx.net (mp027) with SMTP; 02 Jun 2004 17:34:07 +0200
X-Authenticated: #1915285
Message-ID: <40BDF36D.1040703@gmx.de>
Date: Wed, 02 Jun 2004 17:34:05 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org>
In-Reply-To: <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BDF36D.1040703@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8545
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602153440.9A0FFA166C@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 11:34:40 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> One problem is that popular clients and servers only do exclusive locks, 
> so current practice is not sufficient to answer the unanswered questions 
> in RFC2518.  We could cut shared locks from WebDAV, require that only 
> one resource's lock may be updated by a LOCK refresh request, and that 
> would codify existing practice.  I believe that works even for 
> collection locks since a collection lock may not overlap another 
> exclusive lock.  So the new requirements would be something like:
> 
>  - The LOCK refresh request MUST address the resource that was locked 
> (the root of the lock)

Yes.

>  - The If header on the LOCK refresh request MUST contain one (and only 
> one) lock token, the token for the lock that is to be refreshed

I'd say it's harmless if it contains more lock tokens. The server can 
figure out which one actually identifies a lock on the request resource.

>  - The server MUST reject the request if the request-URI and token do 
> not match

Yes.

Seems that we agree except for the minor point above; in practice I 
don't think that clients *will* submit multiple lock tokens in a refresh 
request, so this shouldn't be an issue.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun  2 11:54:13 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29622
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:54:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DD590A1CA8; Wed,  2 Jun 2004 11:54:14 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B3EB2A1CC0
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 11:54:12 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVY4C-0000eV-Gy
	for w3c-dist-auth@w3c.org; Wed, 02 Jun 2004 11:54:12 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i52Fr1JL014246
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 2 Jun 2004 08:53:04 -0700
In-Reply-To: <40BDF36D.1040703@gmx.de>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDF36D.1040703@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0790B052-B4AD-11D8-AF1F-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 2 Jun 2004 08:53:45 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/0790B052-B4AD-11D8-AF1F-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8546
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602155414.DD590A1CA8@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 11:54:14 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Well, the bigger issue then is whether to toss out shared locks.  If 
they're not interoperably implemented, and if we're indeed trying to go 
to draft standard, then they need to go.

lisa

On Jun 2, 2004, at 8:34 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> One problem is that popular clients and servers only do exclusive 
>> locks, so current practice is not sufficient to answer the unanswered 
>> questions in RFC2518.  We could cut shared locks from WebDAV, require 
>> that only one resource's lock may be updated by a LOCK refresh 
>> request, and that would codify existing practice.  I believe that 
>> works even for collection locks since a collection lock may not 
>> overlap another exclusive lock.  So the new requirements would be 
>> something like:
>>  - The LOCK refresh request MUST address the resource that was locked 
>> (the root of the lock)
>
> Yes.
>
>>  - The If header on the LOCK refresh request MUST contain one (and 
>> only one) lock token, the token for the lock that is to be refreshed
>
> I'd say it's harmless if it contains more lock tokens. The server can 
> figure out which one actually identifies a lock on the request 
> resource.
>
>>  - The server MUST reject the request if the request-URI and token do 
>> not match
>
> Yes.
>
> Seems that we agree except for the minor point above; in practice I 
> don't think that clients *will* submit multiple lock tokens in a 
> refresh request, so this shouldn't be an issue.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun  2 14:45:11 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09051
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 14:45:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BB999A1499; Wed,  2 Jun 2004 14:45:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 7EAE6A1499
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 14:45:09 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVajd-0005FO-6Z
	for w3c-dist-auth@w3c.org; Wed, 02 Jun 2004 14:45:09 -0400
Received: (qmail 21366 invoked by uid 65534); 2 Jun 2004 18:44:37 -0000
Received: from pD9E51099.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.153)
  by mail.gmx.net (mp011) with SMTP; 02 Jun 2004 20:44:37 +0200
X-Authenticated: #1915285
Message-ID: <40BE2014.1040503@gmx.de>
Date: Wed, 02 Jun 2004 20:44:36 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDF36D.1040703@gmx.de> <0790B052-B4AD-11D8-AF1F-000A95B2BB72@osafoundation.org>
In-Reply-To: <0790B052-B4AD-11D8-AF1F-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/40BE2014.1040503@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8547
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602184511.BB999A1499@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 14:45:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> Well, the bigger issue then is whether to toss out shared locks.  If 
> they're not interoperably implemented, and if we're indeed trying to go 
> to draft standard, then they need to go.

We discussed that before. We have both servers (Apache/moddav, SAP 
Netweaver, Xythos??) and clients (Adobe GoLive, SAP Netweaver) 
implementing them, so there doesn't seem to be any issue with it...

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun  2 14:54:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10179
	for <webdav-archive@lists.ietf.org>; Wed, 2 Jun 2004 14:54:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A0B6DA1CA8; Wed,  2 Jun 2004 14:54:22 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 08169A1CA8
	for <w3c-dist-auth@listhub.w3.org>; Wed,  2 Jun 2004 14:54:20 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVasV-0006yH-Pw
	for w3c-dist-auth@w3c.org; Wed, 02 Jun 2004 14:54:19 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i52IrHJL024463
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 2 Jun 2004 11:53:19 -0700
In-Reply-To: <40BE2014.1040503@gmx.de>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDF36D.1040703@gmx.de> <0790B052-B4AD-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BE2014.1040503@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <36397488-B4C6-11D8-AF1F-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 2 Jun 2004 11:54:01 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05
X-Archived-At: http://www.w3.org/mid/36397488-B4C6-11D8-AF1F-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8548
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040602185422.A0B6DA1CA8@frink.w3.org>
Resent-Date: Wed,  2 Jun 2004 14:54:22 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I keep forgetting that, because it hasn't been done in interop tests, 
to my knowledge.  Here's what we'll need:
  - Interop test reports from a couple independent pairs of 
server/clients, outlining what tests worked
  - Explanation of how servers refresh locks if the client submits 
multiple lock tokens in the If header in a LOCK refresh request
  - Any other clarifications necessary for shared locks...

Lisa

On Jun 2, 2004, at 11:44 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Well, the bigger issue then is whether to toss out shared locks.  If 
>> they're not interoperably implemented, and if we're indeed trying to 
>> go to draft standard, then they need to go.
>
> We discussed that before. We have both servers (Apache/moddav, SAP 
> Netweaver, Xythos??) and clients (Adobe GoLive, SAP Netweaver) 
> implementing them, so there doesn't seem to be any issue with it...
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Jun  3 03:04:15 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14078
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 03:04:15 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7B7EEA05C5; Thu,  3 Jun 2004 03:04:15 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 82065A11D6
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 03:04:11 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVmGp-000819-5v
	for w3c-dist-auth@w3.org; Thu, 03 Jun 2004 03:04:11 -0400
Received: (qmail 14802 invoked by uid 65534); 3 Jun 2004 07:03:38 -0000
Received: from pD953521B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.82.27)
  by mail.gmx.net (mp011) with SMTP; 03 Jun 2004 09:03:38 +0200
X-Authenticated: #1915285
Message-ID: <40BECD48.5010108@gmx.de>
Date: Thu, 03 Jun 2004 09:03:36 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: BIND spec progress, extracting LOCK from RFC2518(bis), was: [Fwd:  I-D ACTION:draft-reschke-webdav-locking-01.txt]
X-Archived-At: http://www.w3.org/mid/40BECD48.5010108@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8549
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603070415.7B7EEA05C5@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 03:04:15 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

as far as I can tell, the working group hasn't come to a conclusion 
about how to proceed with the BIND spec (see summary 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#49> 
from almost two months ago). Also note that the updated charter 
(<http://www.ietf.org/html.charters/webdav-charter.html>) for the 
working group had a goal for last-calling BIND last month that we've 
already missed.

To speed things up, I have experimentally extracted LOCKING from RFC2518 
and added all open issues related to locking from the RFC2518 issues 
list. This is 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-00.html>.

The derived issues list is here: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>. 
In general, it should match the locking related part of the original 
issues list.

Revision 01 (just published: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-01.html>) 
  has some of the trivial issues resolved; also reorganizing the content 
has started. In particular:

    Add and resolve issue "rfc2606-compliance".  Resolve issues
    "extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL",
    "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS",
    "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02",
    "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL",
    "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION",
    "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC",
    "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK",
    "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS",
    "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and
    "111_MULTIPLE_TOKENS_PER_LOCK".  Add issue "import-gulp".  Start work
    on moving text from RFC2518 excerpts into new sections.  Define new
    compliance class "locking" (similar to "bis" in RFC2518bis, but only
    relevant to locking).  Reformatted "GULP" into separate subsections
    for easier reference.

As usual, edits are ongoing on 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>.

My goals are to drive all locking-related open issues to conclusion as 
soon as possible: this may either mean agreeing on a specific protocol 
or text change; or by explicitly rejecting the issue. This activity is 
useful to the working group no matter whether we actually *do* a 
stand-alone locking spec, or we keep it inside RFC2518bis.

Personally I think that extracting it from RFC2518 makes a lot of sense, 
and I'll try to demonstrate the benefits while I'm working on this 
(non-working-group) draft.


Best regards, Julian



-------- Original Message --------
From: - Thu Jun 03 08:08:42 2004
X-UIDL: 02676066e63b0b9c6baea229004c1384
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-Path: <i-d-announce-bounces@ietf.org>
X-Flags: 0000
Delivered-To: GMX delivery to julian.reschke@gmx.de
Received: (qmail 26364 invoked by uid 65534); 3 Jun 2004 04:19:06 -0000
Received: from megatron.ietf.org (EHLO megatron.ietf.org) (132.151.6.71) 
  by mx0.gmx.net (mx015) with SMTP; 03 Jun 2004 06:19:06 +0200
Received: from localhost.localdomain ([127.0.0.1] 
helo=megatron.ietf.org)	by megatron.ietf.org with esmtp (Exim 4.32)	id 
1BViS7-00066r-AZ; Wed, 02 Jun 2004 22:59:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)	by 
megatron.ietf.org with esmtp (Exim 4.32) id 1BVc6B-00072t-Ji	for 
i-d-announce@megatron.ietf.org; Wed, 02 Jun 2004 16:12:31 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org 
(8.9.1a/8.9.1a) with ESMTP id QAA16333	for <i-d-announce@ietf.org>; Wed, 
2 Jun 2004 16:12:14 -0400 (EDT)
Message-Id: <200406022012.QAA16333@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Wed, 02 Jun 2004 16:12:14 -0400
Subject: I-D ACTION:draft-reschke-webdav-locking-01.txt
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
	Author(s)	: J. Reschke
	Filename	: draft-reschke-webdav-locking-01.txt
	Pages		: 52
	Date		: 2004-6-2
	
This document specifies a set of methods and headers ancillary to
    HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
    RFC2518) for the management of resource locking (collision
    avoidance).  It updates those sections from RFC2518 that specify
    WebDAV's locking features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-01.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-reschke-webdav-locking-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-reschke-webdav-locking-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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



From w3c-dist-auth-request@w3.org  Thu Jun  3 07:12:24 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01722
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:12:23 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 70AD2A0D00; Thu,  3 Jun 2004 07:12:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2985DA0A3A
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 07:12:20 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVq8y-0004Tc-0S
	for w3c-dist-auth@w3c.org; Thu, 03 Jun 2004 07:12:20 -0400
Received: (qmail 29456 invoked by uid 65534); 3 Jun 2004 11:11:48 -0000
Received: from p50824291.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.66.145)
  by mail.gmx.net (mp025) with SMTP; 03 Jun 2004 13:11:48 +0200
X-Authenticated: #1915285
Message-ID: <40BF0770.7070304@gmx.de>
Date: Thu, 03 Jun 2004 13:11:44 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        Jason Crawford <ccjason@us.ibm.com>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDF36D.1040703@gmx.de>
In-Reply-To: <40BDF36D.1040703@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
X-Archived-At: http://www.w3.org/mid/40BF0770.7070304@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8550
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603111223.70AD2A0D00@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 07:12:23 -0400 (EDT)
Content-Transfer-Encoding: 7bit


OK,

here's my attempt to summarize what Lisa and I discussed. I think this 
should be used as resolution for the following issues:

- LOCK_BODY_SHOULD_BE_MUST
- LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

Note that the description below does *not* change the original 
semantics; it's just a clarification that seems to be in sync with 
current implementations (and that's what we should be looking for when 
updating the protocol)...:

1) A LOCK request with message body is a LOCK create request. A LOCK 
request without a message body is a LOCK refresh request.

2) A LOCK refresh request refreshes those locks on the request resource 
whose lock tokens are submitted in the "If" header and whose lock-root 
is the resource identified by the request URI. A server MAY support 
using the Time-Out header to set a new timeout, but clients can not rely 
on that behaviour.

2a) In the case of a shared lock it's technically feasable to submit 
lock tokens for multiple locks to be refreshed in one "If" header. The 
semantics for that seem to be clear from 2), but it's doubtful whether a 
client will ever want to do that. IMHO it doesn't make any sense to put 
in the additional wording to forbid it, though (that's where I disagreed 
with Lisa...).

Note that if we stick with this resolution, the LOCK refresh changes in 
RFC2518bis-05 will need to be rolled back.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Jun  3 07:20:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02267
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:20:39 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 29A1AA1477; Thu,  3 Jun 2004 07:20:37 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9D43CA12D9
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 07:20:30 -0400 (EDT)
Received: from smtpgtw.c1-group.de ([145.253.159.161])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BVqGr-0005dk-4X
	for w3c-dist-auth@w3.org; Thu, 03 Jun 2004 07:20:29 -0400
Received: from holhhsrvmsx01.c1-group.dom ([192.168.110.1])
 by smtpgtw.c1-group.de (SAVSMTP 3.1.1.32) with SMTP id M2004060313231905394
 for <w3c-dist-auth@w3.org>; Thu, 03 Jun 2004 13:23:19 +0200
Received: from c1-fse.de ([192.168.105.64]) by holhhsrvmsx01.c1-group.dom with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 3 Jun 2004 13:19:57 +0200
Message-ID: <40BEFE16.4090606@c1-fse.de>
Date: Thu, 03 Jun 2004 12:31:50 +0200
From: Daniel Florey <dflorey@c1-fse.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917
X-Accept-Language: de, en, en-us, da, ar-bh
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Jun 2004 11:19:57.0782 (UTC) FILETIME=[B3EEFF60:01C4495C]
Subject: Locking spec
X-Archived-At: http://www.w3.org/mid/40BEFE16.4090606@c1-fse.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8551
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603112037.29A1AA1477@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 07:20:37 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,
first of all I want to thank Julian for his great work on the webdav
protocols. His page is *the* resource regarding WebDAV for many
developers working on the apache Slide project.
Now I want to decrease my popularity and ask for forgiveness in advance
by making the following proposal:
I'd like to add transaction support to the locking spec as described in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_esdk_arch_webdav_transactions.asp

I know that this is thew wrong place for long term transactions as
everyone would prefer a method called TRANSACTION or something similar,
but as IIS and Exchange are using the LOCK method to implement
transactions, I'd like to see it in the locking spec. Maybe it would be
an idea to have some basic locking features (current locking spec) and
advanced locking (transactions)?
My personal goal is to achieve full Exchange/IIS compatibility
regarding  WebDAV in the distant future with the Slide project. We are
currently working on a full JCA implementation working with Slide and
hopefully with IIS/Exchange. As this is open source, everyone could use
this Connector lateron, if transactions are support in the "locking" way.
We have already implemented full exchange compliant notifications, but
this is a different story...

Regards,
Daniel





From w3c-dist-auth-request@w3.org  Thu Jun  3 10:42:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16903
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 10:42:25 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 75D2DA13BA; Thu,  3 Jun 2004 10:42:26 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D972CA13BA
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 10:42:21 -0400 (EDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVtQD-0005Yl-Mx
	for w3c-dist-auth@w3.org; Thu, 03 Jun 2004 10:42:21 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i53Efo61654304
	for <w3c-dist-auth@w3.org>; Thu, 3 Jun 2004 10:41:50 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i53EgVY5088972
	for <w3c-dist-auth@w3.org>; Thu, 3 Jun 2004 10:42:31 -0400
In-Reply-To: <40BEFE16.4090606@c1-fse.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF6C96202A.5A2CEA5C-ON85256EA8.004F0DE0-85256EA8.0050BB01@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 3 Jun 2004 10:41:43 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF285 | May 28, 2004) at
 06/03/2004 10:41:35,
	Serialize complete at 06/03/2004 10:41:35
Content-Type: multipart/alternative; boundary="=_alternative 0050BAF985256EA8_="
Subject: Re: Locking spec
X-Archived-At: http://www.w3.org/mid/OF6C96202A.5A2CEA5C-ON85256EA8.004F0DE0-85256EA8.0050BB01@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8552
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603144226.75D2DA13BA@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 10:42:26 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0050BAF985256EA8_=
Content-Type: text/plain; charset="US-ASCII"

Daniel points out one of the important reasons for not putting
transaction support in the locking spec, i.e., transactions are
semantically very different from locks.  The fact that IIS/Exchange
chose to syntactically overload the LOCK method with transaction
support does not provide a compelling reason to bundle them into
a single spec (even if we do eventually decide to standardize on
that syntactic overload).

Another reason for not putting transaction support into the
locking spec is that the maturity of those two proposals is very
different: the locking spec is clarifying/updating existing
standard behavior, while transactions would introduce new WebDAV
semantics/behavior.  The way IIS/Exchange defines/supports transactions
will certainly be an important factor in any WebDAV transaction support,
but will not be an overriding factor.

So I encourage you to try to organize a design team for standardizing
WebDAV transaction support, but I'm against extending the domain of
the locking spec to include transaction support.

Cheers,
Geoff

Daniel wrote on 06/03/2004 06:31:50 AM:

> I'd like to add transaction support to the locking spec as described in
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/wss/wss/_esdk_arch_webdav_transactions.asp
> 
> I know that this is thew wrong place for long term transactions as
> everyone would prefer a method called TRANSACTION or something similar,
> but as IIS and Exchange are using the LOCK method to implement
> transactions, I'd like to see it in the locking spec. Maybe it would be
> an idea to have some basic locking features (current locking spec) and
> advanced locking (transactions)?

--=_alternative 0050BAF985256EA8_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Daniel points out one of the important reasons for
not putting</tt></font>
<br><font size=2><tt>transaction support in the locking spec, i.e., transactions
are</tt></font>
<br><font size=2><tt>semantically very different from locks. &nbsp;The
fact that IIS/Exchange</tt></font>
<br><font size=2><tt>chose to syntactically overload the LOCK method with
transaction</tt></font>
<br><font size=2><tt>support does not provide a compelling reason to bundle
them into</tt></font>
<br><font size=2><tt>a single spec (even if we do eventually decide to
standardize on</tt></font>
<br><font size=2><tt>that syntactic overload).</tt></font>
<br>
<br><font size=2><tt>Another reason for not putting transaction support
into the</tt></font>
<br><font size=2><tt>locking spec is that the maturity of those two proposals
is very</tt></font>
<br><font size=2><tt>different: the locking spec is clarifying/updating
existing</tt></font>
<br><font size=2><tt>standard behavior, while transactions would introduce
new WebDAV</tt></font>
<br><font size=2><tt>semantics/behavior. &nbsp;The way IIS/Exchange defines/supports
transactions</tt></font>
<br><font size=2><tt>will certainly be an important factor in any WebDAV
transaction support,</tt></font>
<br><font size=2><tt>but will not be an overriding factor.</tt></font>
<br>
<br><font size=2><tt>So I encourage you to try to organize a design team
for standardizing</tt></font>
<br><font size=2><tt>WebDAV transaction support, but I'm against extending
the domain of</tt></font>
<br><font size=2><tt>the locking spec to include transaction support.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Daniel wrote on 06/03/2004 06:31:50 AM:<br>
<br>
&gt; I'd like to add transaction support to the locking spec as described
in<br>
&gt; http://msdn.microsoft.com/library/default.asp?url=/library/en-<br>
&gt; us/wss/wss/_esdk_arch_webdav_transactions.asp<br>
&gt; <br>
&gt; I know that this is thew wrong place for long term transactions as<br>
&gt; everyone would prefer a method called TRANSACTION or something similar,<br>
&gt; but as IIS and Exchange are using the LOCK method to implement<br>
&gt; transactions, I'd like to see it in the locking spec. Maybe it would
be<br>
&gt; an idea to have some basic locking features (current locking spec)
and<br>
&gt; advanced locking (transactions)?<br>
</tt></font>
--=_alternative 0050BAF985256EA8_=--



From w3c-dist-auth-request@w3.org  Thu Jun  3 12:59:32 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24915
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 12:59:32 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B062DA155C; Thu,  3 Jun 2004 12:59:32 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 57E4FA155C
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 12:59:30 -0400 (EDT)
Received: from agminet01.oracle.com ([141.146.126.228])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVvYw-0004iy-7l
	for w3c-dist-auth@w3.org; Thu, 03 Jun 2004 12:59:30 -0400
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12])
	by agminet01.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i53GrVBU020158;
	Thu, 3 Jun 2004 09:54:47 -0700
Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1])
	by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i53GrUUl027324;
	Thu, 3 Jun 2004 10:53:30 -0600
Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-27.us.oracle.com [130.35.170.27])
	by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i53GrUWD027307;
	Thu, 3 Jun 2004 10:53:30 -0600
Message-ID: <00b301c4498b$4b8a67a0$1baa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Daniel Florey" <dflorey@c1-fse.de>, <w3c-dist-auth@w3.org>
References: <40BEFE16.4090606@c1-fse.de>
Date: Thu, 3 Jun 2004 09:53:28 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Subject: Re: Locking spec
X-Archived-At: http://www.w3.org/mid/00b301c4498b$4b8a67a0$1baa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8553
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603165932.B062DA155C@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 12:59:32 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Another model for transactions would be something like the COMPOUND method
in NFSv4.  I thought MSFT also implemented batching versions of some other
WebDAV methods, and that could address both requirements in a way that has
already been approved by the IETF.


----- Original Message ----- 
From: "Daniel Florey" <dflorey@c1-fse.de>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, June 03, 2004 3:31 AM
Subject: Locking spec


>
> Hi,
> first of all I want to thank Julian for his great work on the webdav
> protocols. His page is *the* resource regarding WebDAV for many
> developers working on the apache Slide project.
> Now I want to decrease my popularity and ask for forgiveness in advance
> by making the following proposal:
> I'd like to add transaction support to the locking spec as described in
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_esdk_arch_webdav_transactions.asp
>
> I know that this is thew wrong place for long term transactions as
> everyone would prefer a method called TRANSACTION or something similar,
> but as IIS and Exchange are using the LOCK method to implement
> transactions, I'd like to see it in the locking spec. Maybe it would be
> an idea to have some basic locking features (current locking spec) and
> advanced locking (transactions)?
> My personal goal is to achieve full Exchange/IIS compatibility
> regarding  WebDAV in the distant future with the Slide project. We are
> currently working on a full JCA implementation working with Slide and
> hopefully with IIS/Exchange. As this is open source, everyone could use
> this Connector lateron, if transactions are support in the "locking" way.
> We have already implemented full exchange compliant notifications, but
> this is a different story...
>
> Regards,
> Daniel
>
>
>
>



From w3c-dist-auth-request@w3.org  Thu Jun  3 14:25:44 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00773
	for <webdav-archive@lists.ietf.org>; Thu, 3 Jun 2004 14:25:43 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 287BCA22B9; Thu,  3 Jun 2004 14:25:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8EE5AA22B9
	for <w3c-dist-auth@listhub.w3.org>; Thu,  3 Jun 2004 14:25:39 -0400 (EDT)
Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BVwuJ-0003nC-FE
	for w3c-dist-auth@w3.org; Thu, 03 Jun 2004 14:25:39 -0400
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i53IPUL14045
	for <w3c-dist-auth@w3.org>; Thu, 3 Jun 2004 11:25:30 -0700 (PDT)
Message-ID: <40BF6D19.8030100@cse.ucsc.edu>
Date: Thu, 03 Jun 2004 11:25:29 -0700
From: Elias Sinderson <elias@cse.ucsc.edu>
Reply-To: w3c-dist-auth@w3.org
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <40BEFE16.4090606@c1-fse.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: New Methods   (was: Locking spec)
X-Archived-At: http://www.w3.org/mid/40BF6D19.8030100@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8554
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040603182543.287BCA22B9@frink.w3.org>
Resent-Date: Thu,  3 Jun 2004 14:25:43 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Daniel Florey wrote:

> [...] I'd like to add transaction support to the locking spec as 
> described in
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_esdk_arch_webdav_transactions.asp 
>

I reading about the support for transactions at the URL included above, 
I also saw that MS has introduced 'WebDAV notifications' as well. The 
new methods they have developed to support this are SUBSCRIBE, 
UNSUBSCRIBE, NOTIFY and POLL, and describe each as being a 'WebDAV 
method'. Note further that MS has also defined batch versions of COPY, 
MOVE, DELETE, PROPFIND and PROPPATCH: BCOPY, BMOVE, BDELETE, BPROPFIND 
and BPROPPATCH.

I'm of the opinion that these methods aren't and should not be described 
as 'WebDAV methods', for the obvious reason that they have not been 
developed by the IETF WebDAV working group. Unfortunately, I'm not sure 
what can be done about it either.


Elias



From w3c-dist-auth-request@w3.org  Fri Jun  4 06:36:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27456
	for <webdav-archive@lists.ietf.org>; Fri, 4 Jun 2004 06:36:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5B0C3A1564; Fri,  4 Jun 2004 06:34:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 38E93A0F4E
	for <w3c-dist-auth@listhub.w3.org>; Fri,  4 Jun 2004 06:34:08 -0400 (EDT)
Received: from smtpgtw.c1-group.de ([145.253.159.161])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWC18-0001T8-Qd
	for w3c-dist-auth@w3.org; Fri, 04 Jun 2004 06:33:43 -0400
Received: from holhhsrvmsx01.c1-group.dom ([192.168.110.1])
 by smtpgtw.c1-group.de (SAVSMTP 3.1.1.32) with SMTP id M2004060412363306957
 for <w3c-dist-auth@w3.org>; Fri, 04 Jun 2004 12:36:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C44A1F.5414AB69"
Date: Fri, 4 Jun 2004 12:33:08 +0200
Message-ID: <E97201E5738B1840AAB0F64944F2D40540FCBC@holhhsrvmsx01.c1-group.dom>
X-MS-TNEF-Correlator: <E97201E5738B1840AAB0F64944F2D40540FCBC@holhhsrvmsx01.c1-group.dom>
Thread-Topic: New Methods   (was: Locking spec)
Thread-Index: AcRJmDANGfVEqOE/TyKigyEm659KiAAhIU/Q
From: "Florey, Daniel" <dflorey@c1-fse.de>
To: <w3c-dist-auth@w3.org>
Subject: AW: New Methods   (was: Locking spec)
X-Archived-At: http://www.w3.org/mid/E97201E5738B1840AAB0F64944F2D40540FCBC@holhhsrvmsx01.c1-group.dom
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8555
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040604103425.5B0C3A1564@frink.w3.org>
Resent-Date: Fri,  4 Jun 2004 06:34:25 -0400 (EDT)


This is a multi-part message in MIME format.

------_=_NextPart_001_01C44A1F.5414AB69
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Elias,
you are right, this methods indeed are no WebDAV-methods.
But we have to face the fact, that the most widely spread =
WebDAV-software on client side is MS office and on server side (beside =
apache) is MS IIS/Exchange.
There is no problem with MS word as it is using a the basic WebDAV =
methods, but if you want to use Outlook via Web Access, the server needs =
to support many of the MS specific methods. This methods are also used =
by Evolution, a popular linux PIM-software. The exchange adapter is open =
source since a few weeks, so it will be even more popular in future.
So my proposal woud be to work out some drafts, that specifiy this =
batch, notification, transaction and search methods in a MS compatible =
way.
To put the transaction stuff into the locking spec is no good idea =
anyway, so if we decide to start new drafts for the above methods, it =
would be the better way to specify them in different drafts.
Anyone interested in this?
Regards,
Daniel
=20
=20
________________________________

Von: w3c-dist-auth-request@w3.org im Auftrag von Elias Sinderson
Gesendet: Do 03.06.2004 20:25
An: w3c-dist-auth@w3.org
Betreff: New Methods (was: Locking spec)




Daniel Florey wrote:

> [...] I'd like to add transaction support to the locking spec as
> described in
> =
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/wss/ws=
s/_esdk_arch_webdav_transactions.asp
>

I reading about the support for transactions at the URL included above,
I also saw that MS has introduced 'WebDAV notifications' as well. The
new methods they have developed to support this are SUBSCRIBE,
UNSUBSCRIBE, NOTIFY and POLL, and describe each as being a 'WebDAV
method'. Note further that MS has also defined batch versions of COPY,
MOVE, DELETE, PROPFIND and PROPPATCH: BCOPY, BMOVE, BDELETE, BPROPFIND
and BPROPPATCH.

I'm of the opinion that these methods aren't and should not be described
as 'WebDAV methods', for the obvious reason that they have not been
developed by the IETF WebDAV working group. Unfortunately, I'm not sure
what can be done about it either.


Elias




------_=_NextPart_001_01C44A1F.5414AB69
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgkKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJgAAAEFXOiBOZXcgTWV0aG9kcyAg
ICh3YXM6IExvY2tpbmcgc3BlYykA+AsBBYADAA4AAADUBwYABAAMACEACAAFAB8BASCAAwAOAAAA
1AcGAAQADAAhAAgABQAfAQEJgAEAIQAAAEMwQzdGNDlGQUE3NThFNDJBREExM0UwRkJFQkJFQjky
AJkHAQOQBgCoEwAANwAAAAMANgAAAAAAQAA5AGmrFFQfSsQBHgA9AAEAAAAFAAAAQVc6IAAAAAAC
AUcAAQAAADcAAABjPVVTO2E9IDtwPUMxLUdyb3VwO2w9SE9MSEhTUlZNU1gwMS0wNDA2MDQxMDMz
MDhaLTQ1MTgAAB4ASQABAAAAIgAAAE5ldyBNZXRob2RzICAgKHdhczogTG9ja2luZyBzcGVjKQAA
AEAATgCAsrklmEnEAR4AWgABAAAAHQAAAHczYy1kaXN0LWF1dGgtcmVxdWVzdEB3My5vcmcAAAAA
AgFbAAEAAABXAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAdzNjLWRpc3QtYXV0aC1yZXF1ZXN0
QHczLm9yZwBTTVRQAHczYy1kaXN0LWF1dGgtcmVxdWVzdEB3My5vcmcAAAIBXAABAAAAIgAAAFNN
VFA6VzNDLURJU1QtQVVUSC1SRVFVRVNUQFczLk9SRwAAAB4AXQABAAAAEAAAAEVsaWFzIFNpbmRl
cnNvbgACAV4AAQAAAEAAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABFbGlhcyBTaW5kZXJzb24A
U01UUABlbGlhc0Bjc2UudWNzYy5lZHUAAgFfAAEAAAAYAAAAU01UUDpFTElBU0BDU0UuVUNTQy5F
RFUAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcAAQAAAB0AAAB3M2MtZGlzdC1hdXRoLXJlcXVlc3RA
dzMub3JnAAAAAB4AaAABAAAABQAAAFNNVFAAAAAAHgBpAAEAAAATAAAAZWxpYXNAY3NlLnVjc2Mu
ZWR1AAAeAHAAAQAAACIAAABOZXcgTWV0aG9kcyAgICh3YXM6IExvY2tpbmcgc3BlYykAAAACAXEA
AQAAABsAAAABxEmYMA0Z9USo4T9PIqKDISbrn0qIACEhT9AAHgB0AAEAAAAVAAAAdzNjLWRpc3Qt
YXV0aEB3My5vcmcAAAAAHgAaDAEAAAAPAAAARmxvcmV5LCBEYW5pZWwAAB4AHQ4BAAAAIgAAAE5l
dyBNZXRob2RzICAgKHdhczogTG9ja2luZyBzcGVjKQAAAAIBCRABAAAAyAwAAMQMAACIKgAATFpG
dQcNy2cDAAoAcmNwZzEyNYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xAD
AFAEVghVB7IR1Q5RAwHdENcyBgAGwxHVMwRGENlZEu9mNBBvEXs1A8ZUfGFoA3ECgBHjCO8J9zt7
HB8OMDUdPx0REeEMYGNnAFALCQFkMzYRYAulNLIgEAIqXA6yAZBnFPAXCqMR4yJoNBTwPCFEAE9D
VFlQRSBIAFRNTCBQVUJMAElDICItLy9XRDNDJgBEVEQlFDOELjImAEVOIj4jbfMjDyhBMTgkcCUi
J48on40rEDMiACnwRUFEKk0vDvErby3vKXQ2DvA8TShFVEEHsEEw4D0ipkcJ8ASQYXQFsCIXEGhP
TlQnUFQxcAXhRaJ4GOFuZ2UGUnYTMQczwQCQAiAgNi41LsA2OTQ0LjAnfi9PCSmDNzckcFRJVEza
RSpONA7wB8JNEUAa4AZkBCA58Ch3YXM6ICBMb2NrC4BnIFRzcAWQKSjuNSRwL/83zzX/KsU5ETxw
LM8rH0BEgjURYDxCT0RZP70jIXFA32c5NiRwREkgViBpZD1FME9XCEFSZQtQeVRleBB0NTgwN3Ag
ZGl0cj1AYHI/sEAjACEgnwAARuEKsUfSGOBccQMh/0dFEWBCn0OvRLZGr0e/SMq5P/k2NEyqSP8p
dDQp0ZJGMlEgZgDQZT0HE2IgG5M9IzBTszrwabp6UsAyTJsYMAMwYxPwpwOyAdBI2UhpMvBsBzDU
cywo/DVEwS9SQkyZ/0ynTusBwEynCqJZiAqAKPz+MCyRJmBFAFjfUN9KT0tf/0xvTX9Zv0+fXt9R
v1LGVC/rVTRV7XkIYCAKwDNwBRCyZw6wLCA5oAQAIAeAnzmkC4ABAAmAa6NubyIcA1VhYFNXZWJE
QVb6LWy1LldvWH9Zj1qfW6//XL9dz2Z/X+9g/2IPYx9kLz9lP2ZPZ19ob2l/Ve1Cdf0FQHczcBjw
M8BsUG3wUpJ/bFEzcFKRbDMx4IWTBGBz/wVAbh95UgPwAQBF4DrxHqDmYW2Ab2VzbwGAOjBrwf00
UWNXEAnwBUAAkAEAP9viOCIAJm5iOwACgHt3+FwnYQFAf1cEAIs/jE/3jVoF4YnQZg3gM3AAcG2A
fzRRhy95UhkgM7OK8joQYpsHkJPyYQqwGOBlKY4B8QXSSUlTJ0AzFXBPcV//cm9zf3SPdZ92r39f
eM953/9673v/fQ9+H38vgD+BT4JffVXeVIWwa8FsgW3hiPBvaQJgZW2EkGk5oAXSd38FsG2BbREF
QGyBki+fYnXrAJA60WGFk2I6QA3giUX7bKZsQGKEcQaQa2M6MIrBN4UhrmAzcE+EcBuwb2vvM/AH
MIlCEXBjUrAEEGxA/60fn2KFopN1MbAJgAQghSHwc3VwcBvBbKAAcIjA/4nQhZMF4TsCBpCvUW/W
qmH/bIlrsrN/n2IHQInAsaJtgPJiiMBFdgbwhHA0QWxAc67AtjBwdQtgBcBXEG7kdXglYElNibeW
X5dv752fjo+Pn6oIIEYQMyW5r/W6s2SUsHQTMWyBvKAJ8P868AhhhXGucZGCUoAH0YSgvGVrsFG7
EayxA/BsAyD/lEDEIDPAA6AEYGvBvJYLgPvEv59TZoRwCHC+IJk/mk//m1+cb8A/no+fn6Cvob+i
z3+j36Tvpf+nD6gfqS/ZIlPdbfBtiMCrMbYwc1MRrDD+dbtxhQOsMbJQCGCK0QNw+8Sv0rRkMdAB
gLBRhkO3db+IwGxiwR/CL41aryB0GOD/bEBt4LwQkWEx4Lwj1LAAcf+F8TRCkbIZIArAGODgX9LD
v2y4a6DjX+RvkF0FoG0KsPe8EKthsSF5vj+/T5h/zP//zg/PH9Av2N/ST9Nf1G/Vf//Wj9ef2K/Z
v9rP29+pf6sR74RxhaLniobwdQ9AbSGFIb+Fouj/+AIbsDqoqsVnsjD/bYCIga7AtpHuwciU+pCE
of8PILeglAG10gyQtlExsMgg/+G0UoAyAAUvumgVQITxr/f7yOLf0GzfBK7yEUDGUu7B/7XDt4Pi
8quByrH5kJFQqpH/isEL3+F47v/wD/Ef8i/zP//0T/Vf/g/3f/iP+Z/6r/u/v/zP/d/+7///AQ+D
bkG2oP80UKqxisCqkYbwbXHKsWxi/j8TXxRvFX8WjxefGK8Zv/8ibxvfHO8d/x8PIB8hLyI/3yNP
JF8lb4N9RbBnyoCwQf8pDyofKy8sPy1PLl8vbzgf/zGPMp8zrzS/Nc823zfvOP+3Og87H4N9RLFA
iqBsPZ//Pq8/v0DPQd9C70P/TK9GH/9HL0g/SU9KX0tvTH9Nj06f/0+vg31SD1MfWU/rb+x/Xx//
VY9Wn1evZ69Zz1rfW+9c//9eD2tvYC9wj2JPY19kb3fv/2aPb598z3lfemJx03qve7//f599337v
aQ9qH3XPbD9tT/9uX29vhw9xj3Kfc690v47fs4/vkPxIUiigDSBJ6FBRxDA9LTGCrDF1gGMZdYBq
XA5hstBcfiDeX5oSmdGTsMqwZYuzlPD/lF+Vb4zvjf+bj5yfkS+SPz+TT4m/dt+fb4BPgVJUYW+5
ELaAgj+DQjWDn4d+PK5CgquZwaunVugQOqFcHjKeQa1KVCkPcDNjLZMQ8ASALWG8AGgtEUDUcXUo
IUCxwC7J8Acg6xGfoRJpEKBBBKDngQcgq7vQ6tBFvRBhuUBTyrBVCFByvbBup6wxhZFCflKCqZqT
mz+sj62fuYJHd7LgEVAIUHSvH7AvsTdExQfQMLMwMDYuJpCeIcezn6ESJpA6MjW2z7ff/7jvuf+7
DycGvP++D7E/skN/sxXCL8M/xE/FX8ZvzoRCv+pQEUAEsMf/yQ/KF04KscpN6lUoD4BzOsB/oQP6
TAbZKcvvzP/OD4Tfhe//2n/Yj9mfig+LH4wvnc/cn/+njuQP5R+gT6Ff5xym/94n/9Lx3uzpodo/
6P/vmqYw5uD+UO3f7ujrX+xvgLep34NRc1DPUdEgRgbAEUAQUHf8cm8oQNIM3p/fr92/+r9T+8+H
nWd0iMk+yflbwi4CYF0gSScOgJqg8msJ82FkDoDV3/CStUEkbnOBUHRptaFzdfxwcAtgEXAPwQuS
+PDXSP0IgHP8v/3P/t//7wD/ylP5tmBzY3pQDxAoYgevCL9fCc8K3wvvylPO70HwZGgJ0cE9Iojw
dHA6LwAvbXNkbi5taU0NcG+2kLUwLmOpkC/FmqBitVByeS+2YHnwB5mQFsC2AHA/dXJsBj0XF7yg
LXVzL3eKcxl0X7LgZGtf7qABpIBfd2ViZGF2al8FCXMYEiKCrFHRZB0D0maZoLZAsiB7SFkAUEVS
TElOSyB/FX8WjxefGK8ZvxrPG9V9nn2DUZmgtoC0IFxjmQH/mZCk2R7fH+8g/yIPIx8kL98b4+dv
83rn/9J6QYKgDg//Dx8QLxE/Ek80rzK/M883b/s4fzmNSQOv8IOyoANw12Ldl5BvsmAGYwXGZvkA
AzA3G0kHcD+kVR5gDdFjbI51tmAC0D9hdmUsOn//O488nnpwtpA9j/CDBUDU0PPVEEGRTVMVELYB
tkCi8E3VMHWBYALQJ1cssESqQaKAbvlwaR0QY0GQHRuyJwdx+UBR4GwuIH5UBoBDP0RPOZyawNTQ
bf/VBUavBMMGgPkwSEBDAA0xv0MA+PDXsALQBkEFx2iyEAcHcLKgtiBVQlNDUjhJQkVDL0zfOY1V
ToNTaNSgT1RJRlkHcIeXwE+P8INQT0xMV7D7WEINRiA+8KSASwINoD8jX0mWVA9VHzmcTxQnS4BO
//lxeeAqQAZxQKFISViP8JLvRlMpgZqxAtBiQZBbIUMAB7aAQUMogCBDT1BZR1P/XX85jU1PVleh
RJBFTEVUV6FQUmTgGkYegERYM2kCUEFU7ENI1b/wdEJk09GAaCT6QmiGQmkGZS9mPzmcWEL7bUNq
Ey5t327vOZ9x/3MP/TzKJ7TwZKEGclHQtkAFgj9qj1CkQZS8kE8HUyFuJ/sGIFhCc6mAmZFKEltx
DTi/dM9132/9thBJpk8VJ1ewz3j/8JJAg3hCYnYFgCtA/iA+4baRSCRQ6HyUvKB9n7d+r3PsUYhi
+TAGcklosNxGIEm1ge/wknf5ANdTTmf5YAXQS4BVbkCBdOx1bkGQ+LB5V7B3wnyS3wXAsqCGH4cv
c+x3SEJKgN8FoHzStqAGkD9kaQYgiu//8JJbkGCCcb+P33PflV+Wb/+Xf5iPmZ+ap7XTmz+cT5pf
/56/n8+g39tf50/zW+Iu8h//pA/hNObh8eHl7+b/qc/v/xuur+nsNfXR0yBPRFkvMc3S8LC/s0E3
rLFIVBRNTBxAfbVwHgA1EAEAAABEAAAAPEU5NzIwMUU1NzM4QjE4NDBBQUIwRjY0OTQ0RjJENDA1
NDBGQ0JDQGhvbGhoc3J2bXN4MDEuYzEtZ3JvdXAuZG9tPgAeAEcQAQAAAA8AAABtZXNzYWdlL3Jm
YzgyMgAACwDyEAEAAAAfAPMQAQAAAFwAAABBAFcAJQAzAEEAIABOAGUAdwAgAE0AZQB0AGgAbwBk
AHMAIAAgACAAKAB3AGEAcwAlADMAQQAgAEwAbwBjAGsAaQBuAGcAIABzAHAAZQBjACkALgBFAE0A
TAAAAAsA9hAAAAAAQAAHMI6SS7UcSsQBQAAIMH3SG1QfSsQBAwDeP69vAAADAPE/BwQAAB4A+D8B
AAAADwAAAEZsb3JleSwgRGFuaWVsAAACAfk/AQAAAF8AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA
AAAAAAAAL089QzEtR1JPVVAvT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJ
RU5UUy9DTj1ERkxPUkVZAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/
AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAAD
ABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAAAAgAAABERkxPUkVZAB4AMUABAAAACAAAAERG
TE9SRVkAHgAyQAEAAAAdAAAAdzNjLWRpc3QtYXV0aC1yZXF1ZXN0QHczLm9yZwAAAAAeADNAAQAA
ABMAAABlbGlhc0Bjc2UudWNzYy5lZHUAAB4AOEABAAAACAAAAERGTE9SRVkAHgA5QAEAAAACAAAA
LgAAAAMAdkD/////CwApAAAAAAALACMAAAAAAAMABhAhpnyHAwAHEHMGAAADABAQAAAAAAMAERAA
AAAAHgAIEAEAAABlAAAASElFTElBUyxZT1VBUkVSSUdIVCxUSElTTUVUSE9EU0lOREVFREFSRU5P
V0VCREFWLU1FVEhPRFNCVVRXRUhBVkVUT0ZBQ0VUSEVGQUNULFRIQVRUSEVNT1NUV0lERUxZU1BS
RQAAAAACAX8AAQAAAEQAAAA8RTk3MjAxRTU3MzhCMTg0MEFBQjBGNjQ5NDRGMkQ0MDU0MEZDQkNA
aG9saGhzcnZtc3gwMS5jMS1ncm91cC5kb20+AHYv

------_=_NextPart_001_01C44A1F.5414AB69--



From w3c-dist-auth-request@w3.org  Fri Jun  4 10:23:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13399
	for <webdav-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:23:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B6DB4A1DCD; Fri,  4 Jun 2004 10:23:12 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C5DC7A1DCD
	for <w3c-dist-auth@listhub.w3.org>; Fri,  4 Jun 2004 10:23:10 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWFbC-0006MP-LT
	for w3c-dist-auth@w3.org; Fri, 04 Jun 2004 10:23:10 -0400
Received: (qmail 22823 invoked by uid 65534); 4 Jun 2004 14:22:39 -0000
Received: from brmn-d9b8facf.pool.mediaWays.net (EHLO [217.184.250.207]) (217.184.250.207)
  by mail.gmx.net (mp025) with SMTP; 04 Jun 2004 16:22:39 +0200
X-Authenticated: #1915285
Message-ID: <40C0668C.302@gmx.de>
Date: Fri, 04 Jun 2004 14:09:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Florey, Daniel" <dflorey@c1-fse.de>
Cc: w3c-dist-auth@w3.org
References: <E97201E5738B1840AAB0F64944F2D40540FCBC@holhhsrvmsx01.c1-group.dom>
In-Reply-To: <E97201E5738B1840AAB0F64944F2D40540FCBC@holhhsrvmsx01.c1-group.dom>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: AW: New Methods   (was: Locking spec)
X-Archived-At: http://www.w3.org/mid/40C0668C.302@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8556
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040604142312.B6DB4A1DCD@frink.w3.org>
Resent-Date: Fri,  4 Jun 2004 10:23:12 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Florey, Daniel wrote:
> Hi Elias,
> you are right, this methods indeed are no WebDAV-methods.
> But we have to face the fact, that the most widely spread WebDAV-software on client side is MS office and on server side (beside apache) is MS IIS/Exchange.
> There is no problem with MS word as it is using a the basic WebDAV methods, but if you want to use Outlook via Web Access, the server needs to support many of the MS specific methods. This methods are also used by Evolution, a popular linux PIM-software. The exchange adapter is open source since a few weeks, so it will be even more popular in future.
> So my proposal woud be to work out some drafts, that specifiy this batch, notification, transaction and search methods in a MS compatible way.
> To put the transaction stuff into the locking spec is no good idea anyway, so if we decide to start new drafts for the above methods, it would be the better way to specify them in different drafts.
> Anyone interested in this?

Interested: sure.

However, given the fact that the working group seems to have trouble 
focusing on it's milestones (as described in the charter), I'd like to 
ask everybody to *also* help us to get these other tasks finished -- as 
of now this means BIND (then REDIRECT) and RFC2518bis (where I feel that 
we should try to resolve all locking related issues first in case we 
make the decision to extract locking into a separate spec).

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Fri Jun  4 10:23:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13448
	for <webdav-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:23:49 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 53FA6A1D3C; Fri,  4 Jun 2004 10:23:50 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A054EA1DD8
	for <w3c-dist-auth@listhub.w3.org>; Fri,  4 Jun 2004 10:23:48 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWFbo-0006S7-Fh
	for w3c-dist-auth@w3.org; Fri, 04 Jun 2004 10:23:48 -0400
Received: (qmail 19979 invoked by uid 65534); 4 Jun 2004 14:23:17 -0000
Received: from brmn-d9b8facf.pool.mediaWays.net (EHLO [217.184.250.207]) (217.184.250.207)
  by mail.gmx.net (mp016) with SMTP; 04 Jun 2004 16:23:17 +0200
X-Authenticated: #1915285
Message-ID: <40C07D8C.5010902@gmx.de>
Date: Fri, 04 Jun 2004 15:47:56 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/40C07D8C.5010902@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8557
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040604142350.53FA6A1D3C@frink.w3.org>
Resent-Date: Fri,  4 Jun 2004 10:23:50 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

RFC2518, section 8.10.10 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) 
currently shows an example where the multistatus response body contains 
a DAV:lockdiscovery property...:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
           <D:status>HTTP/1.1 403 Forbidden</D:status>
      </D:response>
      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:propstat>
                <D:prop><D:lockdiscovery/></D:prop>
                <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
      </D:response>
    </D:multistatus>

The text then goes on...:

"Note also that the lockdiscovery property for the Request-URI has been 
included as required."

This seems to address a requirement from 8.10.1:

"The response MUST contain the value of the lockdiscovery property in a 
prop XML element."

(RFC2518bis-05 contains the same language).

Questions:

1) What's the benefit to get the DAV:lockdiscovery property in case the 
request fails? Shouldn't we just say that it MUST be returned on 
successful method execution and leave it at that?

2) Is anybody actually implementing this? Are there clients relying on 
it? (I don't think so, but I'll check). If nobody is actually doing 
this, we should remove that.

3) *If* we want to keep this, we'll have to think about that example:

      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:propstat>
                <D:prop><D:lockdiscovery/></D:prop>
                <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
      </D:response>

After all, the "424" status is on the resource itself, not the 
DAV:lockdiscovery property. So it really would need to be....:

      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>

...and then we'd need a way to put in the DAV:lockdiscovery property in 
a way that doesn't break the DTD for the response element.


Feedback appreciated,

Julian




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



From w3c-dist-auth-request@w3.org  Fri Jun  4 11:40:05 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17570
	for <webdav-archive@lists.ietf.org>; Fri, 4 Jun 2004 11:40:04 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A4A31A0524; Fri,  4 Jun 2004 11:40:05 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8A819A1798
	for <w3c-dist-auth@listhub.w3.org>; Fri,  4 Jun 2004 11:39:33 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BWGn7-00038s-Ah
	for w3c-dist-auth@w3.org; Fri, 04 Jun 2004 11:39:33 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i54Fd218432332
	for <w3c-dist-auth@w3.org>; Fri, 4 Jun 2004 11:39:02 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i54FdhZK114114
	for <w3c-dist-auth@w3.org>; Fri, 4 Jun 2004 11:39:43 -0400
In-Reply-To: <40C07D8C.5010902@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF6AE8B649.A408831A-ON85256EA9.0055453B-85256EA9.0055F7D4@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 4 Jun 2004 11:38:44 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF285 | May 28, 2004) at
 06/04/2004 11:38:46,
	Serialize complete at 06/04/2004 11:38:46
Content-Type: multipart/alternative; boundary="=_alternative 0055F7D185256EA9_="
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/OF6AE8B649.A408831A-ON85256EA9.0055453B-85256EA9.0055F7D4@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8558
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040604154005.A4A31A0524@frink.w3.org>
Resent-Date: Fri,  4 Jun 2004 11:40:05 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0055F7D185256EA9_=
Content-Type: text/plain; charset="US-ASCII"

I don't think anything needs to be changed here.
I'm not sure what you had in mind by saying
"it MUST be returned on successful execution",
since the whole point is to indicate what existing
lock caused the LOCK request to fail, i.e. this
property is returned only for the failure case.

WRT the marshalling, I agree that this is not a
consistent way of using the propstat syntax
(i.e. the status is not about the property,
but that was just a convenient place to put it).
So if nobody implements this,
we certainly could define a cleaner marshalling,
but if any client/server does implement it, then we
should leave it alone.

Cheers,
Geoff


Julian wrote on 06/04/2004 09:47:56 AM:

> RFC2518, section 8.10.10 
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) 
> currently shows an example where the multistatus response body contains 
> a DAV:lockdiscovery property...:
> 
>     HTTP/1.1 207 Multi-Status
>     Content-Type: text/xml; charset="utf-8"
>     Content-Length: xxxx
> 
>     <?xml version="1.0" encoding="utf-8" ?>
>     <D:multistatus xmlns:D="DAV:">
>       <D:response>
>            <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
>            <D:status>HTTP/1.1 403 Forbidden</D:status>
>       </D:response>
>       <D:response>
>            <D:href>http://webdav.sb.aol.com/webdav/</D:href>
>            <D:propstat>
>                 <D:prop><D:lockdiscovery/></D:prop>
>                 <D:status>HTTP/1.1 424 Failed Dependency</D:status>
>            </D:propstat>
>       </D:response>
>     </D:multistatus>
> 
> The text then goes on...:
> 
> "Note also that the lockdiscovery property for the Request-URI has been 
> included as required."
> 
> This seems to address a requirement from 8.10.1:
> 
> "The response MUST contain the value of the lockdiscovery property in a 
> prop XML element."
> 
> (RFC2518bis-05 contains the same language).
> 
> Questions:
> 
> 1) What's the benefit to get the DAV:lockdiscovery property in case the 
> request fails? Shouldn't we just say that it MUST be returned on 
> successful method execution and leave it at that?
> 
> 2) Is anybody actually implementing this? Are there clients relying on 
> it? (I don't think so, but I'll check). If nobody is actually doing 
> this, we should remove that.
> 
> 3) *If* we want to keep this, we'll have to think about that example:
> 
>       <D:response>
>            <D:href>http://webdav.sb.aol.com/webdav/</D:href>
>            <D:propstat>
>                 <D:prop><D:lockdiscovery/></D:prop>
>                 <D:status>HTTP/1.1 424 Failed Dependency</D:status>
>            </D:propstat>
>       </D:response>
> 
> After all, the "424" status is on the resource itself, not the 
> DAV:lockdiscovery property. So it really would need to be....:
> 
>       <D:response>
>            <D:href>http://webdav.sb.aol.com/webdav/</D:href>
>            <D:status>HTTP/1.1 424 Failed Dependency</D:status>
>       </D:response>
> 
> ...and then we'd need a way to put in the DAV:lockdiscovery property in 
> a way that doesn't break the DTD for the response element.
> 
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

--=_alternative 0055F7D185256EA9_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I don't think anything needs to be changed here.</tt></font>
<br><font size=2><tt>I'm not sure what you had in mind by saying</tt></font>
<br><font size=2><tt>&quot;it MUST be returned on successful execution&quot;,</tt></font>
<br><font size=2><tt>since the whole point is to indicate what existing</tt></font>
<br><font size=2><tt>lock caused the LOCK request to fail, i.e. this</tt></font>
<br><font size=2><tt>property is returned only for the failure case.</tt></font>
<br>
<br><font size=2><tt>WRT the marshalling, I agree that this is not a</tt></font>
<br><font size=2><tt>consistent way of using the propstat syntax</tt></font>
<br><font size=2><tt>(i.e. the status is not about the property,</tt></font>
<br><font size=2><tt>but that was just a convenient place to put it).</tt></font>
<br><font size=2><tt>So if nobody implements this,</tt></font>
<br><font size=2><tt>we certainly could define a cleaner marshalling,</tt></font>
<br><font size=2><tt>but if any client/server does implement it, then we</tt></font>
<br><font size=2><tt>should leave it alone.</tt></font>
<br>
<br><font size=2><tt>Cheers,<br>
Geoff</tt></font>
<br>
<br>
<br><font size=2><tt>Julian wrote on 06/04/2004 09:47:56 AM:<br>
<br>
&gt; RFC2518, section 8.10.10 <br>
&gt; (&lt;http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10&gt;)
<br>
&gt; currently shows an example where the multistatus response body contains
<br>
&gt; a DAV:lockdiscovery property...:<br>
&gt; <br>
&gt; &nbsp; &nbsp; HTTP/1.1 207 Multi-Status<br>
&gt; &nbsp; &nbsp; Content-Type: text/xml; charset=&quot;utf-8&quot;<br>
&gt; &nbsp; &nbsp; Content-Length: xxxx<br>
&gt; <br>
&gt; &nbsp; &nbsp; &lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;
?&gt;<br>
&gt; &nbsp; &nbsp; &lt;D:multistatus xmlns:D=&quot;DAV:&quot;&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;D:response&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:href&gt;http://webdav.sb.aol.com/webdav/secret&lt;/D:href&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:status&gt;HTTP/1.1
403 Forbidden&lt;/D:status&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;/D:response&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;D:response&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:href&gt;http://webdav.sb.aol.com/webdav/&lt;/D:href&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:propstat&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;D:status&gt;HTTP/1.1
424 Failed Dependency&lt;/D:status&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/D:propstat&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;/D:response&gt;<br>
&gt; &nbsp; &nbsp; &lt;/D:multistatus&gt;<br>
&gt; <br>
&gt; The text then goes on...:<br>
&gt; <br>
&gt; &quot;Note also that the lockdiscovery property for the Request-URI
has been <br>
&gt; included as required.&quot;<br>
&gt; <br>
&gt; This seems to address a requirement from 8.10.1:<br>
&gt; <br>
&gt; &quot;The response MUST contain the value of the lockdiscovery property
in a <br>
&gt; prop XML element.&quot;<br>
&gt; <br>
&gt; (RFC2518bis-05 contains the same language).<br>
&gt; <br>
&gt; Questions:<br>
&gt; <br>
&gt; 1) What's the benefit to get the DAV:lockdiscovery property in case
the <br>
&gt; request fails? Shouldn't we just say that it MUST be returned on <br>
&gt; successful method execution and leave it at that?<br>
&gt; <br>
&gt; 2) Is anybody actually implementing this? Are there clients relying
on <br>
&gt; it? (I don't think so, but I'll check). If nobody is actually doing
<br>
&gt; this, we should remove that.<br>
&gt; <br>
&gt; 3) *If* we want to keep this, we'll have to think about that example:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &lt;D:response&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:href&gt;http://webdav.sb.aol.com/webdav/&lt;/D:href&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:propstat&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;D:prop&gt;&lt;D:lockdiscovery/&gt;&lt;/D:prop&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;D:status&gt;HTTP/1.1
424 Failed Dependency&lt;/D:status&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/D:propstat&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;/D:response&gt;<br>
&gt; <br>
&gt; After all, the &quot;424&quot; status is on the resource itself, not
the <br>
&gt; DAV:lockdiscovery property. So it really would need to be....:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &lt;D:response&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:href&gt;http://webdav.sb.aol.com/webdav/&lt;/D:href&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;D:status&gt;HTTP/1.1
424 Failed Dependency&lt;/D:status&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;/D:response&gt;<br>
&gt; <br>
&gt; ...and then we'd need a way to put in the DAV:lockdiscovery property
in <br>
&gt; a way that doesn't break the DTD for the response element.<br>
&gt; <br>
&gt; <br>
&gt; Feedback appreciated,<br>
&gt; <br>
&gt; Julian<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; <br>
</tt></font>
--=_alternative 0055F7D185256EA9_=--



From w3c-dist-auth-request@w3.org  Sat Jun  5 06:36:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06117
	for <webdav-archive@lists.ietf.org>; Sat, 5 Jun 2004 06:36:48 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 99789A0AD3; Sat,  5 Jun 2004 06:36:49 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 26CAFA0AD3
	for <w3c-dist-auth@listhub.w3.org>; Sat,  5 Jun 2004 06:36:47 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWYXe-0001Ak-R6
	for w3c-dist-auth@w3.org; Sat, 05 Jun 2004 06:36:47 -0400
Received: (qmail 6208 invoked by uid 65534); 5 Jun 2004 10:36:14 -0000
Received: from pD9E51333.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.19.51)
  by mail.gmx.net (mp009) with SMTP; 05 Jun 2004 12:36:14 +0200
X-Authenticated: #1915285
Message-ID: <40C1A21B.3000209@gmx.de>
Date: Sat, 05 Jun 2004 12:36:11 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF6AE8B649.A408831A-ON85256EA9.0055453B-85256EA9.0055F7D4@us.ibm.com>
In-Reply-To: <OF6AE8B649.A408831A-ON85256EA9.0055453B-85256EA9.0055F7D4@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/40C1A21B.3000209@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8559
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040605103649.99789A0AD3@frink.w3.org>
Resent-Date: Sat,  5 Jun 2004 06:36:49 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> I don't think anything needs to be changed here.
> I'm not sure what you had in mind by saying
> "it MUST be returned on successful execution",
> since the whole point is to indicate what existing
> lock caused the LOCK request to fail, i.e. this
> property is returned only for the failure case.

In RFC2518, the requirement is independant from the success of the LOCK 
request: "The response MUST contain the value of the lockdiscovery 
property in a prop XML element." 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>).

1) For a successful LOCK creation, returning the element makes a lot of 
sense, because the client can check the actual state of the lock (did 
the server accept my Timeout header? what did it persist in the 
DAV:owner property?). I think that part is widely implemented and if 
fact used by popular clients such as MS Office (it checks the response 
body to decide whether the created lock is really what it wanted). 
Therefore we should keep that part, and this is why I was saying "MUST 
be returned on success".

2) For a failed LOCK request, there are (at least) two scenarios:

2a) The resource at the request URI can not be locked, for instance 
because it already has a conflicting lock. In that case, I'd expect a 
4xx status code, and RFC2518 does not define a way to send back 
DAV:lockdiscovery. If we require the server to send back a 207 with 
response body in this case, this really needs to be stated explicitly 
because it's far from obvious.

2b) The client tries a deep lock, and some of the descendants of the 
resource identified by the request URI can not be locked. In that case 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>), 
the text requires a 409 and a multistatus body (this is a bug in both 
RFC2518 and RFC2518bis, it should be 207, 
see...:<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>). 
In that case, the DAV:lockdiscovery property for the resource at the 
request URI will usually be empty, and it escapes me why anybody would 
want to send that back to the client.

> WRT the marshalling, I agree that this is not a
> consistent way of using the propstat syntax
> (i.e. the status is not about the property,
> but that was just a convenient place to put it).
> So if nobody implements this,
> we certainly could define a cleaner marshalling,
> but if any client/server does implement it, then we
> should leave it alone.

Let's find out.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Sat Jun  5 09:22:52 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13148
	for <webdav-archive@lists.ietf.org>; Sat, 5 Jun 2004 09:22:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 425B1A11CE; Sat,  5 Jun 2004 09:22:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 52E9EA11CE
	for <w3c-dist-auth@listhub.w3.org>; Sat,  5 Jun 2004 09:22:50 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWb8M-0001wI-6E
	for w3c-dist-auth@w3.org; Sat, 05 Jun 2004 09:22:50 -0400
Received: (qmail 30537 invoked by uid 65534); 5 Jun 2004 13:22:19 -0000
Received: from p50824A5F.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.74.95)
  by mail.gmx.net (mp026) with SMTP; 05 Jun 2004 15:22:19 +0200
X-Authenticated: #1915285
Message-ID: <40C1C908.1060403@gmx.de>
Date: Sat, 05 Jun 2004 15:22:16 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Issue DEEP_LOCK_ERROR_STATUS
X-Archived-At: http://www.w3.org/mid/40C1C908.1060403@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8560
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040605132252.425B1A11CE@frink.w3.org>
Resent-Date: Sat,  5 Jun 2004 09:22:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I just tested server behaviour for the issue "DEEP_LOCK_ERROR_STATUS" 
(<http://www.webdav.org/wg/rfcdev/issues.htm> and also 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-01.html#rfc.issue.037_DEEP_LOCK_ERROR_STATUS>). 
Results:

- Microsoft IIS: does not support collection locks ("<body><h2>HTTP/1.1 
403 Forbidden</h2><br><h
3>LOCKing a collection is not allowed</h3></body>")

- Apache/moddav: as described in 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>, so 
status 207 instead of 409.

- SAP Netweaver: see Apache/moddav.

- Sharemation (Xythos server): see Apache/moddav

I conclude that the spec text (requiring a 409 with multistatus) is 
indeed wrong; and that it should say 207.

Jason, could you please update the issues list with that resolution?

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Sat Jun  5 17:00:00 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06227
	for <webdav-archive@lists.ietf.org>; Sat, 5 Jun 2004 16:59:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C2D81A1530; Sat,  5 Jun 2004 17:00:00 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4EF3FA16A3
	for <w3c-dist-auth@listhub.w3.org>; Sat,  5 Jun 2004 16:59:58 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BWiGk-00037N-6B
	for w3c-dist-auth@w3.org; Sat, 05 Jun 2004 16:59:58 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i55KxRD6810038
	for <w3c-dist-auth@w3.org>; Sat, 5 Jun 2004 16:59:27 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i55L0KbE146160
	for <w3c-dist-auth@w3.org>; Sat, 5 Jun 2004 17:00:21 -0400
In-Reply-To: <40C1A21B.3000209@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 5 Jun 2004 16:59:09 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/05/2004 16:59:09,
	Serialize complete at 06/05/2004 16:59:09
Content-Type: multipart/alternative; boundary="=_alternative 00734D9785256EAA_="
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8561
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040605210000.C2D81A1530@frink.w3.org>
Resent-Date: Sat,  5 Jun 2004 17:00:00 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 00734D9785256EAA_=
Content-Type: text/plain; charset="US-ASCII"

Julian Reschke <julian.reschke@gmx.de> wrote on 06/05/2004 06:36:11 AM:

> Geoffrey M Clemm wrote:
> 
> > I don't think anything needs to be changed here.
> > I'm not sure what you had in mind by saying
> > "it MUST be returned on successful execution",
> > since the whole point is to indicate what existing
> > lock caused the LOCK request to fail, i.e. this
> > property is returned only for the failure case.
> 
> In RFC2518, the requirement is independant from the success of the LOCK 
> request: "The response MUST contain the value of the lockdiscovery 
> property in a prop XML element." 

By "this property", I meant the property on the nested resource that
returned 424 because that nested resource was already locked.
I agree that a lockdiscovery property for the resource identified
by the request-URL must always be returned, whether or not the request
succeeded.

> 1) For a successful LOCK creation, returning the element makes a lot of 
> sense, because the client can check the actual state of the lock (did 
> the server accept my Timeout header? what did it persist in the 
> DAV:owner property?). I think that part is widely implemented and if 
> fact used by popular clients such as MS Office (it checks the response 
> body to decide whether the created lock is really what it wanted). 
> Therefore we should keep that part, and this is why I was saying "MUST 
> be returned on success".

Yes, I agree.

> 2) For a failed LOCK request, there are (at least) two scenarios:
> 
> 2a) The resource at the request URI can not be locked, for instance 
> because it already has a conflicting lock. In that case, I'd expect a 
> 4xx status code, and RFC2518 does not define a way to send back 
> DAV:lockdiscovery. If we require the server to send back a 207 with 
> response body in this case, this really needs to be stated explicitly 
> because it's far from obvious.

Well, it is stated in section 8.10.4, but I agree that it is not clearly
stated, since the only way to guess how to marshall it is by extrapolation
from example 8.10.10.

> 2b) The client tries a deep lock, and some of the descendants of the 
> resource identified by the request URI can not be locked. In that case 
> 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>), 
> the text requires a 409 and a multistatus body (this is a bug in both 
> RFC2518 and RFC2518bis, it should be 207, 
> 
see...:<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3
> >). 

Yes, that inconsistency in the spec doesn't contribute much in the way
of clarity (:-).

> In that case, the DAV:lockdiscovery property for the resource at the 
> request URI will usually be empty, and it escapes me why anybody would 
> want to send that back to the client.

It might not be empty because there might already be a shallow
lock on that collection.  So returning the lockdiscovery property
tells the client definitively whether or not there already is a
lock on the request URL resource, which is useful information when
dealing with the failure.

> > WRT the marshalling, I agree that this is not a
> > consistent way of using the propstat syntax
> > (i.e. the status is not about the property,
> > but that was just a convenient place to put it).
> > So if nobody implements this,
> > we certainly could define a cleaner marshalling,
> > but if any client/server does implement it, then we
> > should leave it alone.
> 
> Let's find out.

Yup.

Cheers,
Geoff


--=_alternative 00734D9785256EAA_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote
on 06/05/2004 06:36:11 AM:<br>
<br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; <br>
&gt; &gt; I don't think anything needs to be changed here.<br>
&gt; &gt; I'm not sure what you had in mind by saying<br>
&gt; &gt; &quot;it MUST be returned on successful execution&quot;,<br>
&gt; &gt; since the whole point is to indicate what existing<br>
&gt; &gt; lock caused the LOCK request to fail, i.e. this<br>
&gt; &gt; property is returned only for the failure case.<br>
&gt; <br>
&gt; In RFC2518, the requirement is independant from the success of the
LOCK <br>
&gt; request: &quot;The response MUST contain the value of the lockdiscovery
<br>
&gt; property in a prop XML element.&quot; </tt></font>
<br>
<br><font size=2><tt>By &quot;this property&quot;, I meant the property
on the nested resource that</tt></font>
<br><font size=2><tt>returned 424 because that nested resource was already
locked.</tt></font>
<br><font size=2><tt>I agree that a lockdiscovery property for the resource
identified</tt></font>
<br><font size=2><tt>by the request-URL must always be returned, whether
or not the request</tt></font>
<br><font size=2><tt>succeeded.</tt></font>
<br><font size=2><tt><br>
&gt; 1) For a successful LOCK creation, returning the element makes a lot
of <br>
&gt; sense, because the client can check the actual state of the lock (did
<br>
&gt; the server accept my Timeout header? what did it persist in the <br>
&gt; DAV:owner property?). I think that part is widely implemented and
if <br>
&gt; fact used by popular clients such as MS Office (it checks the response
<br>
&gt; body to decide whether the created lock is really what it wanted).
<br>
&gt; Therefore we should keep that part, and this is why I was saying &quot;MUST
<br>
&gt; be returned on success&quot;.</tt></font>
<br>
<br><font size=2><tt>Yes, I agree.<br>
<br>
&gt; 2) For a failed LOCK request, there are (at least) two scenarios:<br>
&gt; <br>
&gt; 2a) The resource at the request URI can not be locked, for instance
<br>
&gt; because it already has a conflicting lock. In that case, I'd expect
a <br>
&gt; 4xx status code, and RFC2518 does not define a way to send back <br>
&gt; DAV:lockdiscovery. If we require the server to send back a 207 with
<br>
&gt; response body in this case, this really needs to be stated explicitly
<br>
&gt; because it's far from obvious.</tt></font>
<br>
<br><font size=2><tt>Well, it is stated in section 8.10.4, but I agree
that it is not clearly</tt></font>
<br><font size=2><tt>stated, since the only way to guess how to marshall
it is by extrapolation</tt></font>
<br><font size=2><tt>from example 8.10.10.<br>
<br>
&gt; 2b) The client tries a deep lock, and some of the descendants of the
<br>
&gt; resource identified by the request URI can not be locked. In that
case <br>
&gt; (&lt;http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3&gt;),
<br>
&gt; the text requires a 409 and a multistatus body (this is a bug in both
<br>
&gt; RFC2518 and RFC2518bis, it should be 207, <br>
&gt; see...:&lt;http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3<br>
&gt; &gt;). </tt></font>
<br>
<br><font size=2><tt>Yes, that inconsistency in the spec doesn't contribute
much in the way</tt></font>
<br><font size=2><tt>of clarity (:-).</tt></font>
<br><font size=2><tt><br>
&gt; In that case, the DAV:lockdiscovery property for the resource at the
<br>
&gt; request URI will usually be empty, and it escapes me why anybody would
<br>
&gt; want to send that back to the client.</tt></font>
<br>
<br><font size=2><tt>It might not be empty because there might already
be a shallow</tt></font>
<br><font size=2><tt>lock on that collection. &nbsp;So returning the lockdiscovery
property</tt></font>
<br><font size=2><tt>tells the client definitively whether or not there
already is a</tt></font>
<br><font size=2><tt>lock on the request URL resource, which is useful
information when</tt></font>
<br><font size=2><tt>dealing with the failure.</tt></font>
<br><font size=2><tt><br>
&gt; &gt; WRT the marshalling, I agree that this is not a<br>
&gt; &gt; consistent way of using the propstat syntax<br>
&gt; &gt; (i.e. the status is not about the property,<br>
&gt; &gt; but that was just a convenient place to put it).<br>
&gt; &gt; So if nobody implements this,<br>
&gt; &gt; we certainly could define a cleaner marshalling,<br>
&gt; &gt; but if any client/server does implement it, then we<br>
&gt; &gt; should leave it alone.<br>
&gt; <br>
&gt; Let's find out.<br>
</tt></font>
<br><font size=2><tt>Yup.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br><font size=2><tt><br>
</tt></font>
--=_alternative 00734D9785256EAA_=--



From w3c-dist-auth-request@w3.org  Sun Jun  6 05:55:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20680
	for <webdav-archive@lists.ietf.org>; Sun, 6 Jun 2004 05:55:55 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 87E05A1986; Sun,  6 Jun 2004 05:55:55 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EDE6CA1986
	for <w3c-dist-auth@listhub.w3.org>; Sun,  6 Jun 2004 05:55:52 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BWuNc-0002ds-OF
	for w3c-dist-auth@w3.org; Sun, 06 Jun 2004 05:55:52 -0400
Received: (qmail 3209 invoked by uid 65534); 6 Jun 2004 09:55:19 -0000
Received: from pD9FF0660.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.6.96)
  by mail.gmx.net (mp017) with SMTP; 06 Jun 2004 11:55:19 +0200
X-Authenticated: #1915285
Message-ID: <40C2E9FA.1090801@gmx.de>
Date: Sun, 06 Jun 2004 11:55:06 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com>
In-Reply-To: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/40C2E9FA.1090801@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8562
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040606095555.87E05A1986@frink.w3.org>
Resent-Date: Sun,  6 Jun 2004 05:55:55 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

 > ...
>  > > I don't think anything needs to be changed here.
>  > > I'm not sure what you had in mind by saying
>  > > "it MUST be returned on successful execution",
>  > > since the whole point is to indicate what existing
>  > > lock caused the LOCK request to fail, i.e. this
>  > > property is returned only for the failure case.
>  >
>  > In RFC2518, the requirement is independant from the success of the LOCK
>  > request: "The response MUST contain the value of the lockdiscovery
>  > property in a prop XML element."
> 
> By "this property", I meant the property on the nested resource that
> returned 424 because that nested resource was already locked.
> I agree that a lockdiscovery property for the resource identified
> by the request-URL must always be returned, whether or not the request
> succeeded.

Well, the 424 is returned for the request resource (because it has a 
failed dependancy). The non-424 status (in the RFC2518 example 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> it's 
a 403) comes without the DAV:lockdiscovery property (and I do agree that 
it may be useful here, but that's not what the spec says).

> ...
>  > 2) For a failed LOCK request, there are (at least) two scenarios:
>  >
>  > 2a) The resource at the request URI can not be locked, for instance
>  > because it already has a conflicting lock. In that case, I'd expect a
>  > 4xx status code, and RFC2518 does not define a way to send back
>  > DAV:lockdiscovery. If we require the server to send back a 207 with
>  > response body in this case, this really needs to be stated explicitly
>  > because it's far from obvious.
> 
> Well, it is stated in section 8.10.4, but I agree that it is not clearly
> stated, since the only way to guess how to marshall it is by extrapolation
> from example 8.10.10.

...but the multistatus response body is only mentioned for marshalling 
failures due to depth:infinity...

 > ...
>  > > WRT the marshalling, I agree that this is not a
>  > > consistent way of using the propstat syntax
>  > > (i.e. the status is not about the property,
>  > > but that was just a convenient place to put it).
>  > > So if nobody implements this,
>  > > we certainly could define a cleaner marshalling,
>  > > but if any client/server does implement it, then we
>  > > should leave it alone.
>  >
>  > Let's find out.
> 
> Yup.

In the meantime I found out that at least Apache/moddav and Sharemation 
indeed use this format. What we should do...:

1) Find out whether there are clients that actually process this 
information. As far as I can tell, it will only be useful if and only if 
you're trying to get an deep, exclusive lock on a resource that already 
has a shared lock. I'm only aware of two clients using shared locks. The 
first one being our own (and I know it doesn't use that information), 
the other being Adobe GoLive (for which I'll check).

2) If the answer is "yes" *and* we agree not to break them, we'll need 
to figure out how to precisely define that response format (a single 
example is not good enough).

3) On the other hand, if the answer is "no" let's define what we *like* 
the protocol to do and come up with a cleaner design (precondition code 
with nested content as in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?


Best regards,

Julian


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



From w3c-dist-auth-request@w3.org  Sun Jun  6 15:29:09 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15873
	for <webdav-archive@lists.ietf.org>; Sun, 6 Jun 2004 15:29:08 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D0969A17CF; Sun,  6 Jun 2004 15:29:08 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 99205A17CF
	for <w3c-dist-auth@listhub.w3.org>; Sun,  6 Jun 2004 15:29:06 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BX3KM-00029q-IS
	for w3c-dist-auth@w3.org; Sun, 06 Jun 2004 15:29:06 -0400
Received: (qmail 17128 invoked by uid 65534); 6 Jun 2004 19:28:34 -0000
Received: from pD9FF0660.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.6.96)
  by mail.gmx.net (mp026) with SMTP; 06 Jun 2004 21:28:34 +0200
X-Authenticated: #1915285
Message-ID: <40C37055.3080905@gmx.de>
Date: Sun, 06 Jun 2004 21:28:21 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: multipart/mixed;
 boundary="------------070001070408040906050405"
Subject: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40C37055.3080905@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8563
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040606192908.D0969A17CF@frink.w3.org>
Resent-Date: Sun,  6 Jun 2004 15:29:08 -0400 (EDT)


This is a multi-part message in MIME format.
--------------070001070408040906050405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

"What should UNLOCK return if a bad token is provided or no token. (This 
might be contingent on UNLOCK_NEEDS_IF_HEADER.)"

I just tested this, here are the results (test script attached):

(a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token: 412.

(b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 
412.

(c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock 
token: 412.

(d) Xythos (Sharemation): see (c). (I also note that Xythos is returning 
invalid lock tokens)

Summarizing:

- we can't guarantee a specific status code,

- we should define a specific precondition (see proposal at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5>)

- we should talk about what is the right thing to do here -- basically 
we need to answer whether "lock-token" is a request header that 
contributes to precondition checking as defined by RFC2616 
(<http://greenbytes.de/tech/webdav/rfc2616.html#status.412>) -- if we 
can agree on this, Apache/moddav's behaviour would be correct.

Feedback appreciated,

Julian

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


--------------070001070408040906050405
Content-Type: application/x-gzip;
 name="068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz"
Content-Disposition: inline;
 filename="068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz"
Content-Transfer-Encoding: base64

H4sICGZsw0AAAzA2OF9VTkxPQ0tfV0lUSE9VVF9HT09EX1RPS0VOLmpzALVV227bRhB9rgD9
w4B9MJWIF0lFLqokwKiCOIhjuZbUGCgKY0WORMbULr271AWO/z27S0qmLo6Ton3jzs7Mzpwz
Z7ggHDjeQRcoLuE0kPECrweTLxhIsK1Pw+tP5013iHyBXH2ejUaXVu33aqVaiadgfx4GPE6l
e8pn2RypFG6CdCYj6HbBr8F9tQKw8XkXRMy2RigkBEQgTBmHTiRl2va8GUekk7VE4YboSQwi
b4mTkCy8kJOpdDiKILpFJzc6CQtuYzpzYiEyFRLJefKr/+rNzfjifPDHx5vPH0Zng/Ho5v1g
0L8ZDT6+u+iZmvdrGQsywzYEwhjhuxncLwLGVx/gPhPIKZnjA9ynRIgl4+HDXvY/s1jaTW17
0EAtFMIZjxXCB3DZvvYyDiqt5iBLksKSLsNHQ7UyzajihlEIs3l6hSJlVKDNj4HMXSGJzMSR
nrk7Q3maJJsEZ0hC5MKuHfXlhdcIV3LbzjPM96BR1FS0dNh0Y5vrmUxNk+mXHInDPM1STZ4H
aaYmi1Gp7qqVXaYvxyOw4KWmQceoeXdZitRcWHVtrsOUJALrpuq6Bn/jKJCGtjVlbEK4IXqX
ALzTNt2IcTbAQweavg9fv0LJ1utCyz8uioziKlWCwxAK50xlB13cdydLNa2lAPFBw3qKj3es
b55vWV7hnZKWzOfDtvqYykiFWb71tNMoniPLpHYbomIidF6V3TWMnX47F++UwWqeUNHud0/6
p3+1T3rFlQhUnfqAqyDJhNpGXq/j7d3pg1zn30sey5JPbvYe3+k9SVquMxPEbpGW1Sb5Oieq
fKvbmOmuy9qxLe3iGB+rYCYgMojAXimyt2NeSpS/o8djx2hZR4dDmN0LYRwCZVIVITNOc95N
aB1UsWobwkatMGHh+tjC0/XvSxqgbFUbXvN6yRXOXK5txWOCZu2cEzrL1LrU5F5fEjUMefQ+
PruZdPBQ1ZbgBQvRtjzvxd8qgiSOXqF2rXsScZye/GPVXKkKytFDNZSH4G+/XZFNhOQqq92o
l8zF1nBgd72UFKgwPpSlMTaOIr/N3TZS2h5r+3XuhikIWMYDNHTpIAzrha7zRKXXXyrDxnRI
zROyN8LXE5pRMwbLWEZKd6WZ2F8H+W9tsxDMqzZlpYCatbsl8oAfWo1Pq+uwSlhypib15wqd
kPA/qHR/WZ0/qlaNdIelRF0/Mt5CDKevW8Rp/RYGjt9q+A5pvm05b94SQsImafgtv2f9eyAC
xrkSx88hUQT9/2jsjLt++wdb/QbN+MOMTQoAAA==
--------------070001070408040906050405--



From w3c-dist-auth-request@w3.org  Sun Jun  6 20:21:17 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27467
	for <webdav-archive@lists.ietf.org>; Sun, 6 Jun 2004 20:21:16 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 337B8A1F55; Sun,  6 Jun 2004 20:21:16 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 486AEA1F55
	for <w3c-dist-auth@listhub.w3.org>; Sun,  6 Jun 2004 20:21:13 -0400 (EDT)
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BX7t3-0002Ps-8Z
	for w3c-dist-auth@w3.org; Sun, 06 Jun 2004 20:21:13 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i570KgQ1620628
	for <w3c-dist-auth@w3.org>; Sun, 6 Jun 2004 20:20:42 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i570LN6j038870
	for <w3c-dist-auth@w3.org>; Sun, 6 Jun 2004 20:21:24 -0400
In-Reply-To: <40C37055.3080905@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF21A908CF.1493CA0F-ON85256EAC.000143A7-85256EAC.0001E485@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sun, 6 Jun 2004 20:20:21 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/06/2004 20:20:23,
	Serialize complete at 06/06/2004 20:20:23
Content-Type: multipart/alternative; boundary="=_alternative 0001E48385256EAC_="
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/OF21A908CF.1493CA0F-ON85256EAC.000143A7-85256EAC.0001E485@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8564
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607002116.337B8A1F55@frink.w3.org>
Resent-Date: Sun,  6 Jun 2004 20:21:16 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0001E48385256EAC_=
Content-Type: text/plain; charset="US-ASCII"

I would vote for treating the lock-token as a request header
that contributes to precondition checking, so I agree with
the ModDav/Microsoft behavior.

Cheers,
Geoff

Julian wrote on 06/06/2004 03:28:21 PM:
> 
> "What should UNLOCK return if a bad token is provided or no token. (This 

> might be contingent on UNLOCK_NEEDS_IF_HEADER.)"
> 
> I just tested this, here are the results (test script attached):
> 
> (a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token: 
412.
> 
> (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 

> 412.
> 
> (c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock 
> token: 412.
> 
> (d) Xythos (Sharemation): see (c). (I also note that Xythos is returning 

> invalid lock tokens)
> 
> Summarizing:
> 
> - we can't guarantee a specific status code,
> 
> - we should define a specific precondition (see proposal at 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.5>)
> 
> - we should talk about what is the right thing to do here -- basically 
> we need to answer whether "lock-token" is a request header that 
> contributes to precondition checking as defined by RFC2616 
> (<http://greenbytes.de/tech/webdav/rfc2616.html#status.412>) -- if we 
> can agree on this, Apache/moddav's behaviour would be correct.
> 
> Feedback appreciated,
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> [attachment "068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz" deleted by 
> Geoffrey M Clemm/Lexington/IBM] 
--=_alternative 0001E48385256EAC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I would vote for treating the lock-token as a request
header</tt></font>
<br><font size=2><tt>that contributes to precondition checking, so I agree
with</tt></font>
<br><font size=2><tt>the ModDav/Microsoft behavior.</tt></font>
<br><font size=2><tt><br>
Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/06/2004 03:28:21 PM:<br>
&gt; <br>
&gt; &quot;What should UNLOCK return if a bad token is provided or no token.
(This <br>
&gt; might be contingent on UNLOCK_NEEDS_IF_HEADER.)&quot;<br>
&gt; <br>
&gt; I just tested this, here are the results (test script attached):<br>
&gt; <br>
&gt; (a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token:
412.<br>
&gt; <br>
&gt; (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock
token: <br>
&gt; 412.<br>
&gt; <br>
&gt; (c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad
lock <br>
&gt; token: 412.<br>
&gt; <br>
&gt; (d) Xythos (Sharemation): see (c). (I also note that Xythos is returning
<br>
&gt; invalid lock tokens)<br>
&gt; <br>
&gt; Summarizing:<br>
&gt; <br>
&gt; - we can't guarantee a specific status code,<br>
&gt; <br>
&gt; - we should define a specific precondition (see proposal at <br>
&gt; &lt;http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-<br>
&gt; latest.html#rfc.section.5&gt;)<br>
&gt; <br>
&gt; - we should talk about what is the right thing to do here -- basically
<br>
&gt; we need to answer whether &quot;lock-token&quot; is a request header
that <br>
&gt; contributes to precondition checking as defined by RFC2616 <br>
&gt; (&lt;http://greenbytes.de/tech/webdav/rfc2616.html#status.412&gt;)
-- if we <br>
&gt; can agree on this, Apache/moddav's behaviour would be correct.<br>
&gt; <br>
&gt; Feedback appreciated,<br>
&gt; <br>
&gt; Julian<br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; <br>
&gt; [attachment &quot;068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz&quot; deleted
by <br>
&gt; Geoffrey M Clemm/Lexington/IBM] </tt></font>
--=_alternative 0001E48385256EAC_=--



From w3c-dist-auth-request@w3.org  Mon Jun  7 04:10:01 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00391
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 04:10:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 994C6A1CE8; Mon,  7 Jun 2004 04:10:01 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 11A5CA21E4
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 04:09:10 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BXEiO-0000h9-TG
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 03:38:41 -0400
Received: (qmail 5133 invoked by uid 65534); 7 Jun 2004 07:36:07 -0000
Received: from pD9E51D4A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.74)
  by mail.gmx.net (mp003) with SMTP; 07 Jun 2004 09:36:07 +0200
X-Authenticated: #1915285
Message-ID: <40C41AD5.6040204@gmx.de>
Date: Mon, 07 Jun 2004 09:35:49 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF21A908CF.1493CA0F-ON85256EAC.000143A7-85256EAC.0001E485@us.ibm.com>
In-Reply-To: <OF21A908CF.1493CA0F-ON85256EAC.000143A7-85256EAC.0001E485@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40C41AD5.6040204@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8565
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607081001.994C6A1CE8@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 04:10:01 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Geoffrey M Clemm wrote:

 > I would vote for treating the lock-token as a request header
 > that contributes to precondition checking, so I agree with
 > the ModDav/Microsoft behavior.

'%"$%$§! I mistyped the results. The actual results are:

(a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token: 412.

(b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 
410.

(c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock 
token: 412.

(d) Xythos (Sharemation): see (c). (I also note that Xythos is returning 
invalid lock tokens)

RFC2616 treats exactly all "If-*" headers as defining preconditions. 
RFC2518 adds "If" (which is obvious) and also explicitly "Overwrite" 
(but at least it's clear about it). As RFC2518 nowhere states that the 
"Lock-Token" header expresses a "precondition", I'm leaning to 
favorizing Apache's behaviour (which is *not* what IIS does...).

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Mon Jun  7 04:12:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00493
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 04:12:33 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4E664A050D; Mon,  7 Jun 2004 04:12:34 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A0377A08F5
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 04:12:28 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BXFF6-00017y-DP
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 04:12:28 -0400
Received: (qmail 15713 invoked by uid 65534); 7 Jun 2004 08:11:56 -0000
Received: from pD9E51D4A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.74)
  by mail.gmx.net (mp015) with SMTP; 07 Jun 2004 10:11:56 +0200
X-Authenticated: #1915285
Message-ID: <40C42346.9000708@gmx.de>
Date: Mon, 07 Jun 2004 10:11:50 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, w3c-dist-auth@w3.org
References: <OF21A908CF.1493CA0F-ON85256EAC.000143A7-85256EAC.0001E485@us.ibm.com> <40C41AD5.6040204@gmx.de>
In-Reply-To: <40C41AD5.6040204@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40C42346.9000708@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8566
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607081234.4E664A050D@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 04:12:34 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 
> 410.

s/410/400/g

Sigh.

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



From w3c-dist-auth-request@w3.org  Mon Jun  7 07:22:24 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07848
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 07:22:24 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D47DBA2124; Mon,  7 Jun 2004 07:22:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A6D06A2124
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 07:22:18 -0400 (EDT)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXICZ-00080X-Mf
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 07:22:03 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i57BLWhF344890
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 07:21:32 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i57BMS9h133004
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 07:22:28 -0400
In-Reply-To: <40C41AD5.6040204@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 7 Jun 2004 07:21:13 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/07/2004 07:21:13,
	Serialize complete at 06/07/2004 07:21:13
Content-Type: multipart/alternative; boundary="=_alternative 003E655285256EAC_="
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8567
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607112223.D47DBA2124@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 07:22:23 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 003E655285256EAC_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Since none of the current implementations agree, I'd go with the
one that seemed to be trying the hardest to implement what the
specification says, and I agree with Julian that this is the Apache
behavior.

Cheers,
Geoff

Julian wrote on 06/07/2004 03:35:49 AM:
>=20
> Geoffrey M Clemm wrote:
>=20
>  > I would vote for treating the lock-token as a request header
>  > that contributes to precondition checking, so I agree with
>  > the ModDav/Microsoft behavior.
>=20
> '%"$%$=A7! I mistyped the results. The actual results are:
>=20
> (a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token:=20
412.
>=20
> (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: =


> 400.
>=20
> (c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock=20
> token: 412.
>=20
> (d) Xythos (Sharemation): see (c). (I also note that Xythos is returning =


> invalid lock tokens)
>=20
> RFC2616 treats exactly all "If-*" headers as defining preconditions.=20
> RFC2518 adds "If" (which is obvious) and also explicitly "Overwrite"=20
> (but at least it's clear about it). As RFC2518 nowhere states that the=20
> "Lock-Token" header expresses a "precondition", I'm leaning to=20
> favorizing Apache's behaviour (which is *not* what IIS does...).

--=_alternative 003E655285256EAC_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>Since none of the current implementations agree, I'd
go with the</tt></font>
<br><font size=3D2><tt>one that seemed to be trying the hardest to implement
what the</tt></font>
<br><font size=3D2><tt>specification says, and I agree with Julian that this
is the Apache</tt></font>
<br><font size=3D2><tt>behavior.</tt></font>
<br>
<br><font size=3D2><tt>Cheers,</tt></font>
<br><font size=3D2><tt>Geoff</tt></font>
<br>
<br><font size=3D2><tt>Julian wrote on 06/07/2004 03:35:49 AM:<br>
&gt; <br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; <br>
&gt; &nbsp;&gt; I would vote for treating the lock-token as a request heade=
r<br>
&gt; &nbsp;&gt; that contributes to precondition checking, so I agree with<=
br>
&gt; &nbsp;&gt; the ModDav/Microsoft behavior.<br>
&gt; <br>
&gt; '%&quot;$%$=A7! I mistyped the results. The actual results are:<br>
&gt; <br>
&gt; (a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token:
412.<br>
&gt; <br>
&gt; (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock
token: <br>
&gt; 400.<br>
&gt; <br>
&gt; (c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad
lock <br>
&gt; token: 412.<br>
&gt; <br>
&gt; (d) Xythos (Sharemation): see (c). (I also note that Xythos is returni=
ng
<br>
&gt; invalid lock tokens)<br>
&gt; <br>
&gt; RFC2616 treats exactly all &quot;If-*&quot; headers as defining precon=
ditions.
<br>
&gt; RFC2518 adds &quot;If&quot; (which is obvious) and also explicitly
&quot;Overwrite&quot; <br>
&gt; (but at least it's clear about it). As RFC2518 nowhere states that
the <br>
&gt; &quot;Lock-Token&quot; header expresses a &quot;precondition&quot;,
I'm leaning to <br>
&gt; favorizing Apache's behaviour (which is *not* what IIS does...).<br>
</tt></font>
--=_alternative 003E655285256EAC_=--



From w3c-dist-auth-request@w3.org  Mon Jun  7 16:32:14 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15645
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 16:32:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 14C6AA09C2; Mon,  7 Jun 2004 16:32:15 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 84E8CA09C2
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 16:32:10 -0400 (EDT)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXQmw-0004wd-7I
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 16:32:10 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i57KUqU9017827;
	Mon, 7 Jun 2004 13:30:53 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i57KUorZ005557;
	Mon, 7 Jun 2004 13:30:51 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06100507bcea80120454@[129.46.227.161]>
Date: Mon, 7 Jun 2004 13:30:51 -0700
To: w3c-dist-auth@w3.org
From: Ted Hardie <hardie@qualcomm.com>
Cc: JHildebrand@jabber.com, paf@cisco.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Announcement of new co-chair
X-Archived-At: http://www.w3.org/mid/p06100507bcea80120454@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8568
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607203215.14C6AA09C2@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 16:32:15 -0400 (EDT)


Howdy,
	Patrik Falstrom has let me and Lisa know that he
cannot dedicate the time to WebDav that he had originally
intended.  After some discussion with Lisa and Patrik, I have
asked Joe Hildebrand to take up the role of co-chair in Patrik's stead.
	Please welcome Joe to the post; I'm sure he'll
be introducing himself both on the list and in the upcoming
meeting.
		regards,
			Ted Hardie
			co-Chair, Applications Area



From w3c-dist-auth-request@w3.org  Mon Jun  7 16:54:03 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18000
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 16:54:02 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 62A38A0570; Mon,  7 Jun 2004 16:54:04 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8133FA0570
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 16:54:01 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXR85-00024l-9G
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 16:54:01 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i57Kr3JL003148
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 7 Jun 2004 13:53:04 -0700
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <p06100507bcea80120454@[129.46.227.161]>
References: <p06100507bcea80120454@[129.46.227.161]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C4F7A792-B8C4-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 7 Jun 2004 13:53:46 -0700
To: WebDAV <w3c-dist-auth@w3.org>, Joe Hildebrand <JHildebrand@jabber.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Meeting planning (was: Re: Announcement of new co-chair)
X-Archived-At: http://www.w3.org/mid/C4F7A792-B8C4-11D8-9162-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8569
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607205404.62A38A0570@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 16:54:04 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Welcome Joe!

Speaking of meeting, we need to schedule the upcoming meeting pretty 
soon.  I think there's a lot of difficult issues, and in-person 
discussions could really help in resolving difficult issues, so if you 
attend one WebDAV meeting a year, make this the one.  Are there any 
other WG conflicts to avoid in scheduling?  Submissions for the agenda?

Lisa

On Jun 7, 2004, at 1:30 PM, Ted Hardie wrote:

>
> Howdy,
> 	Patrik Falstrom has let me and Lisa know that he
> cannot dedicate the time to WebDav that he had originally
> intended.  After some discussion with Lisa and Patrik, I have
> asked Joe Hildebrand to take up the role of co-chair in Patrik's stead.
> 	Please welcome Joe to the post; I'm sure he'll
> be introducing himself both on the list and in the upcoming
> meeting.
> 		regards,
> 			Ted Hardie
> 			co-Chair, Applications Area
>



From w3c-dist-auth-request@w3.org  Mon Jun  7 17:21:11 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21593
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 17:21:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9EB88A190D; Mon,  7 Jun 2004 17:21:12 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 00D03A190D
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 17:21:09 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXRYL-0007TD-TY
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 17:21:10 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i57LJRJL005096
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 7 Jun 2004 14:19:29 -0700
In-Reply-To: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com>
References: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: quoted-printable
Cc: w3c-dist-auth@w3.org
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 7 Jun 2004 14:20:13 -0700
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8570
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607212112.9EB88A190D@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 17:21:12 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Is there some advantage to having a different error code for these two=20=

cases, or distinguishing between this error and the dozens of problems=20=

that can cause a 400 response?  Apache's model does not distinguish=20
what the error is.    So the Microsoft approach has the advantage of=20
distinguishing the two different cases. The Xythos/SAP approach has the=20=

advantage of using a more specific code (400 is the most generic form=20
of bad request code, therefore less specific than 412) although it's=20
the same for both these cases under discussion.  However, 412 is a=20
little too specific for the case where the client omitted the lock=20
token header entirely -- clients shouldn't have to expect a 412 error=20
when the client sends a request without any "conditional" headers at=20
all.

I don't have a strong opinion here so I'm not disagreeing with Geoff; I=20=

just don't know what's a good reason on which to base our choice, and=20
wanted to list a few potential justifications.  Yet another=20
justification could be "we have two servers doing it the same way,=20
let's do it that way".

Any other commenters before we declare a (very rough) consensus?  .Mac=20=

server implementors could tell us what they do...

Lisa

On Jun 7, 2004, at 4:21 AM, Geoffrey M Clemm wrote:

> Since none of the current implementations agree, I'd go with the
> one that seemed to be trying the hardest to implement what the
> specification says, and I agree with Julian that this is the Apache
> behavior.
>
> Cheers,
> Geoff
>
> Julian wrote on 06/07/2004 03:35:49 AM:
>>
>> Geoffrey M Clemm wrote:
>>
>>> I would vote for treating the lock-token as a request header
>>> that contributes to precondition checking, so I agree with
>>> the ModDav/Microsoft behavior.
>>
>> '%"$%$=A7! I mistyped the results. The actual results are:
>>
>> (a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token:
> 412.
>>
>> (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock=20
>> token:
>
>> 400.
>>
>> (c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad=20
>> lock
>> token: 412.
>>
>> (d) Xythos (Sharemation): see (c). (I also note that Xythos is=20
>> returning
>
>> invalid lock tokens)
>>
>> RFC2616 treats exactly all "If-*" headers as defining preconditions.
>> RFC2518 adds "If" (which is obvious) and also explicitly "Overwrite"
>> (but at least it's clear about it). As RFC2518 nowhere states that =
the
>> "Lock-Token" header expresses a "precondition", I'm leaning to
>> favorizing Apache's behaviour (which is *not* what IIS does...).



From w3c-dist-auth-request@w3.org  Mon Jun  7 17:38:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24591
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 17:38:25 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8EB54A1B65; Mon,  7 Jun 2004 17:38:27 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3FD51A1B65
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 17:38:25 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXRp2-0001XY-VX
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 17:38:25 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i57LacJL006570
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 7 Jun 2004 14:36:39 -0700
In-Reply-To: <40C2E9FA.1090801@gmx.de>
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com> <40C2E9FA.1090801@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 7 Jun 2004 14:37:23 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8571
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607213827.8EB54A1B65@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 17:38:27 -0400 (EDT)
Content-Transfer-Encoding: 7bit



Hello client implementors! -- please respond on this thread and let us 
know if you use the 'lockdiscovery' property value, which is returned 
in failed LOCK requests.

(If no clients use the property value as returned in failed LOCK 
requests -- maybe they all do another round-trip to get the value -- 
then we might as well simplify, rather than optimize for this failure 
case)

Lisa


On Jun 6, 2004, at 2:55 AM, Julian Reschke wrote:

>
> Geoffrey M Clemm wrote:
>
> > ...
>>  > > I don't think anything needs to be changed here.
>>  > > I'm not sure what you had in mind by saying
>>  > > "it MUST be returned on successful execution",
>>  > > since the whole point is to indicate what existing
>>  > > lock caused the LOCK request to fail, i.e. this
>>  > > property is returned only for the failure case.
>>  >
>>  > In RFC2518, the requirement is independant from the success of the 
>> LOCK
>>  > request: "The response MUST contain the value of the lockdiscovery
>>  > property in a prop XML element."
>> By "this property", I meant the property on the nested resource that
>> returned 424 because that nested resource was already locked.
>> I agree that a lockdiscovery property for the resource identified
>> by the request-URL must always be returned, whether or not the request
>> succeeded.
>
> Well, the 424 is returned for the request resource (because it has a 
> failed dependancy). The non-424 status (in the RFC2518 example 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> 
> it's a 403) comes without the DAV:lockdiscovery property (and I do 
> agree that it may be useful here, but that's not what the spec says).
>
>> ...
>>  > 2) For a failed LOCK request, there are (at least) two scenarios:
>>  >
>>  > 2a) The resource at the request URI can not be locked, for instance
>>  > because it already has a conflicting lock. In that case, I'd 
>> expect a
>>  > 4xx status code, and RFC2518 does not define a way to send back
>>  > DAV:lockdiscovery. If we require the server to send back a 207 with
>>  > response body in this case, this really needs to be stated 
>> explicitly
>>  > because it's far from obvious.
>> Well, it is stated in section 8.10.4, but I agree that it is not 
>> clearly
>> stated, since the only way to guess how to marshall it is by 
>> extrapolation
>> from example 8.10.10.
>
> ...but the multistatus response body is only mentioned for marshalling 
> failures due to depth:infinity...
>
> > ...
>>  > > WRT the marshalling, I agree that this is not a
>>  > > consistent way of using the propstat syntax
>>  > > (i.e. the status is not about the property,
>>  > > but that was just a convenient place to put it).
>>  > > So if nobody implements this,
>>  > > we certainly could define a cleaner marshalling,
>>  > > but if any client/server does implement it, then we
>>  > > should leave it alone.
>>  >
>>  > Let's find out.
>> Yup.
>
> In the meantime I found out that at least Apache/moddav and 
> Sharemation indeed use this format. What we should do...:
>
> 1) Find out whether there are clients that actually process this 
> information. As far as I can tell, it will only be useful if and only 
> if you're trying to get an deep, exclusive lock on a resource that 
> already has a shared lock. I'm only aware of two clients using shared 
> locks. The first one being our own (and I know it doesn't use that 
> information), the other being Adobe GoLive (for which I'll check).
>
> 2) If the answer is "yes" *and* we agree not to break them, we'll need 
> to figure out how to precisely define that response format (a single 
> example is not good enough).
>
> 3) On the other hand, if the answer is "no" let's define what we 
> *like* the protocol to do and come up with a cleaner design 
> (precondition code with nested content as in 
> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?
>
>
> Best regards,
>
> Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Mon Jun  7 17:51:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25945
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 17:51:18 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DD9D6A19EF; Mon,  7 Jun 2004 17:51:19 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 71046A19EF
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 17:51:16 -0400 (EDT)
Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXS1U-0003v5-8W
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 17:51:16 -0400
Received: by corp.webb.net with Internet Mail Service (5.5.2653.19)
	id <MLCBAB64>; Mon, 7 Jun 2004 15:49:38 -0600
Message-ID: <8D96EDA0AC04D31197B400A0C96C148009EEA59E@corp.webb.net>
From: Joe Hildebrand <JHildebrand@jabber.com>
To: Ted Hardie <hardie@qualcomm.com>, w3c-dist-auth@w3.org
Date: Mon, 7 Jun 2004 15:49:37 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: Announcement of new co-chair
X-Archived-At: http://www.w3.org/mid/8D96EDA0AC04D31197B400A0C96C148009EEA59E@corp.webb.net
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8572
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607215119.DD9D6A19EF@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 17:51:19 -0400 (EDT)


Thanks for the intro, Ted.

For those that don't know me, I hope to meet you in person at the San Diego
meeting, or online if you can't make it.

Since I haven't been involved from the beginning, there are liable to be
times when I don't have all of the historical context of decisions that have
been made.  I hope you all bear with me when I ask questions that may have
obvious answers to you...

-- 
Joe Hildebrand


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Ted Hardie
> Sent: Monday, June 07, 2004 2:31 PM
> To: w3c-dist-auth@w3.org
> Cc: JHildebrand@jabber.com; paf@cisco.com
> Subject: Announcement of new co-chair
> 
> 
> Howdy,
> 	Patrik Falstrom has let me and Lisa know that he cannot 
> dedicate the time to WebDav that he had originally intended.  
> After some discussion with Lisa and Patrik, I have asked Joe 
> Hildebrand to take up the role of co-chair in Patrik's stead.
> 	Please welcome Joe to the post; I'm sure he'll be 
> introducing himself both on the list and in the upcoming meeting.
> 		regards,
> 			Ted Hardie
> 			co-Chair, Applications Area



From w3c-dist-auth-request@w3.org  Mon Jun  7 18:07:30 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27918
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 18:07:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 76B74A09BF; Mon,  7 Jun 2004 18:07:31 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 27C64A09BF
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 18:07:29 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BXSHB-0006Ow-01
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 18:07:29 -0400
Received: (qmail 4430 invoked by uid 65534); 7 Jun 2004 22:06:56 -0000
Received: from pD953529C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.82.156)
  by mail.gmx.net (mp022) with SMTP; 08 Jun 2004 00:06:56 +0200
X-Authenticated: #1915285
Message-ID: <40C4E6FC.4060504@gmx.de>
Date: Tue, 08 Jun 2004 00:06:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, w3c-dist-auth@w3.org
References: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com> <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org>
In-Reply-To: <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40C4E6FC.4060504@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8573
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607220731.76B74A09BF@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 18:07:31 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Is there some advantage to having a different error code for these two 
> cases, or distinguishing between this error and the dozens of problems 
> that can cause a 400 response?  Apache's model does not distinguish what 
> the error is.    So the Microsoft approach has the advantage of 
> distinguishing the two different cases. The Xythos/SAP approach has the 

I was asking because we have an open issue on that. It seems that we 
can't guarantee a particular server behaviour, but I was still wondering 
what would be the most correct status for each of these cases. The spec 
*should* state something about that.

That being said, a spec revision should define specific precondition 
names, in which case what kind of 4xx is returned becomes less 
important. A new client will just detect the general failure code, and 
then take a look at the response body.

> advantage of using a more specific code (400 is the most generic form of 
> bad request code, therefore less specific than 412) although it's the 
> same for both these cases under discussion.  However, 412 is a little 
> too specific for the case where the client omitted the lock token header 
> entirely -- clients shouldn't have to expect a 412 error when the client 
> sends a request without any "conditional" headers at all.

Correct. So it would be nice if we could decide whether "lock-tokem" is 
an header that contributes to "precondition" checks as defined per 
RFC2616 (I think it shouldn't).

> I don't have a strong opinion here so I'm not disagreeing with Geoff; I 
> just don't know what's a good reason on which to base our choice, and 
> wanted to list a few potential justifications.  Yet another 
> justification could be "we have two servers doing it the same way, let's 
> do it that way".
> 
> Any other commenters before we declare a (very rough) consensus?  .Mac 
> server implementors could tell us what they do...

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon Jun  7 18:18:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29150
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 18:18:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 68B7DA185E; Mon,  7 Jun 2004 18:18:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 84521A17E7
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 18:18:20 -0400 (EDT)
Received: from mail-out3.apple.com ([17.254.13.22])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXSRg-0007nA-EK
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 18:18:20 -0400
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i57MHnDe026448
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 15:17:49 -0700 (PDT)
Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6a0c188f6c118064e1304@mailgate1.apple.com> for <w3c-dist-auth@w3.org>;
 Mon, 7 Jun 2004 15:17:49 -0700
Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76])
	by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i57MHWPg007668
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 15:17:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v660)
In-Reply-To: <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org>
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com> <40C2E9FA.1090801@gmx.de> <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com>
Content-Transfer-Encoding: 7bit
From: Jim Luther <luther.j@apple.com>
Date: Mon, 7 Jun 2004 15:17:32 -0700
To: w3c-dist-auth@w3.org
X-Mailer: Apple Mail (2.660)
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8574
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607221823.68B7DA185E@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 18:18:23 -0400 (EDT)
Content-Transfer-Encoding: 7bit


The Mac OS X WebDAV file system client uses exclusive locks. The 
lockdiscovery property is only used if LOCK is successful.

- Jim

On Jun 7, 2004, at 2:37 PM, Lisa Dusseault wrote:

>
>
> Hello client implementors! -- please respond on this thread and let us 
> know if you use the 'lockdiscovery' property value, which is returned 
> in failed LOCK requests.
>
> (If no clients use the property value as returned in failed LOCK 
> requests -- maybe they all do another round-trip to get the value -- 
> then we might as well simplify, rather than optimize for this failure 
> case)
>
> Lisa
>
>
> On Jun 6, 2004, at 2:55 AM, Julian Reschke wrote:
>
>>
>> Geoffrey M Clemm wrote:
>>
>> > ...
>>>  > > I don't think anything needs to be changed here.
>>>  > > I'm not sure what you had in mind by saying
>>>  > > "it MUST be returned on successful execution",
>>>  > > since the whole point is to indicate what existing
>>>  > > lock caused the LOCK request to fail, i.e. this
>>>  > > property is returned only for the failure case.
>>>  >
>>>  > In RFC2518, the requirement is independant from the success of 
>>> the LOCK
>>>  > request: "The response MUST contain the value of the lockdiscovery
>>>  > property in a prop XML element."
>>> By "this property", I meant the property on the nested resource that
>>> returned 424 because that nested resource was already locked.
>>> I agree that a lockdiscovery property for the resource identified
>>> by the request-URL must always be returned, whether or not the 
>>> request
>>> succeeded.
>>
>> Well, the 424 is returned for the request resource (because it has a 
>> failed dependancy). The non-424 status (in the RFC2518 example 
>> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> 
>> it's a 403) comes without the DAV:lockdiscovery property (and I do 
>> agree that it may be useful here, but that's not what the spec says).
>>
>>> ...
>>>  > 2) For a failed LOCK request, there are (at least) two scenarios:
>>>  >
>>>  > 2a) The resource at the request URI can not be locked, for 
>>> instance
>>>  > because it already has a conflicting lock. In that case, I'd 
>>> expect a
>>>  > 4xx status code, and RFC2518 does not define a way to send back
>>>  > DAV:lockdiscovery. If we require the server to send back a 207 
>>> with
>>>  > response body in this case, this really needs to be stated 
>>> explicitly
>>>  > because it's far from obvious.
>>> Well, it is stated in section 8.10.4, but I agree that it is not 
>>> clearly
>>> stated, since the only way to guess how to marshall it is by 
>>> extrapolation
>>> from example 8.10.10.
>>
>> ...but the multistatus response body is only mentioned for 
>> marshalling failures due to depth:infinity...
>>
>> > ...
>>>  > > WRT the marshalling, I agree that this is not a
>>>  > > consistent way of using the propstat syntax
>>>  > > (i.e. the status is not about the property,
>>>  > > but that was just a convenient place to put it).
>>>  > > So if nobody implements this,
>>>  > > we certainly could define a cleaner marshalling,
>>>  > > but if any client/server does implement it, then we
>>>  > > should leave it alone.
>>>  >
>>>  > Let's find out.
>>> Yup.
>>
>> In the meantime I found out that at least Apache/moddav and 
>> Sharemation indeed use this format. What we should do...:
>>
>> 1) Find out whether there are clients that actually process this 
>> information. As far as I can tell, it will only be useful if and only 
>> if you're trying to get an deep, exclusive lock on a resource that 
>> already has a shared lock. I'm only aware of two clients using shared 
>> locks. The first one being our own (and I know it doesn't use that 
>> information), the other being Adobe GoLive (for which I'll check).
>>
>> 2) If the answer is "yes" *and* we agree not to break them, we'll 
>> need to figure out how to precisely define that response format (a 
>> single example is not good enough).
>>
>> 3) On the other hand, if the answer is "no" let's define what we 
>> *like* the protocol to do and come up with a cleaner design 
>> (precondition code with nested content as in 
>> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?
>>
>>
>> Best regards,
>>
>> Julian
>>
>>
>> -- 
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>



From w3c-dist-auth-request@w3.org  Mon Jun  7 19:30:53 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02723
	for <webdav-archive@lists.ietf.org>; Mon, 7 Jun 2004 19:30:53 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 86337A17B5; Mon,  7 Jun 2004 19:30:53 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4628BA18CD
	for <w3c-dist-auth@listhub.w3.org>; Mon,  7 Jun 2004 19:30:51 -0400 (EDT)
Received: from mail-out4.apple.com ([17.254.13.23])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BXTZq-0002MU-VJ
	for w3c-dist-auth@w3.org; Mon, 07 Jun 2004 19:30:51 -0400
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i57NUKgs025929
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 16:30:20 -0700 (PDT)
Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6a0c5af0b3118064e1304@mailgate1.apple.com> for <w3c-dist-auth@w3.org>;
 Mon, 7 Jun 2004 16:30:19 -0700
Received: from [17.207.15.105] (baumjo.apple.com [17.207.15.105])
	by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i57NUHeq020422
	for <w3c-dist-auth@w3.org>; Mon, 7 Jun 2004 16:30:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org>
References: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com> <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A271FE50-B8DA-11D8-ACC2-000393518B02@apple.com>
Content-Transfer-Encoding: 7bit
From: John Baumgarten <jbaumgarten@apple.com>
Date: Mon, 7 Jun 2004 16:30:17 -0700
To: w3c-dist-auth@w3.org
X-Mailer: Apple Mail (2.618)
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/A271FE50-B8DA-11D8-ACC2-000393518B02@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8575
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040607233053.86337A17B5@frink.w3.org>
Resent-Date: Mon,  7 Jun 2004 19:30:53 -0400 (EDT)
Content-Transfer-Encoding: 7bit


In the pending maintenance release running in our lab (not necessarily 
what's up on .mac today), we return, respectively:

HTTP/1.1 412 Precondition Failed: Lock-Token header missing
HTTP/1.1 409 Conflict: Lock-Token is invalid

>
> .Mac server implementors could tell us what they do...
>


JS "Jake" Baumgarten
Apple .Mac Backend Server Engineering

+1-408-974-0043
jbaumgarten@apple.com
Loc: VG5-1045   MS: 82-EC
20605 Valley Green Dr, Cupertino CA 95014 USA
www.apple.com



From w3c-dist-auth-request@w3.org  Tue Jun  8 02:51:01 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05933
	for <webdav-archive@lists.ietf.org>; Tue, 8 Jun 2004 02:51:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7A580A0B12; Tue,  8 Jun 2004 02:50:22 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B59F8A1090
	for <w3c-dist-auth@listhub.w3.org>; Tue,  8 Jun 2004 02:50:12 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BXaR2-0005Hm-Il
	for w3c-dist-auth@w3.org; Tue, 08 Jun 2004 02:50:12 -0400
Received: (qmail 12997 invoked by uid 65534); 8 Jun 2004 06:49:39 -0000
Received: from pD953529C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.82.156)
  by mail.gmx.net (mp011) with SMTP; 08 Jun 2004 08:49:39 +0200
X-Authenticated: #1915285
Message-ID: <40C5616B.4040101@gmx.de>
Date: Tue, 08 Jun 2004 08:49:15 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Baumgarten <jbaumgarten@apple.com>
Cc: w3c-dist-auth@w3.org
References: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com> <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org> <A271FE50-B8DA-11D8-ACC2-000393518B02@apple.com>
In-Reply-To: <A271FE50-B8DA-11D8-ACC2-000393518B02@apple.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40C5616B.4040101@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8576
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040608065022.7A580A0B12@frink.w3.org>
Resent-Date: Tue,  8 Jun 2004 02:50:22 -0400 (EDT)
Content-Transfer-Encoding: 7bit


John Baumgarten wrote:

> 
> In the pending maintenance release running in our lab (not necessarily 
> what's up on .mac today), we return, respectively:
> 
> HTTP/1.1 412 Precondition Failed: Lock-Token header missing
> HTTP/1.1 409 Conflict: Lock-Token is invalid
> 
>>
>> .Mac server implementors could tell us what they do...

Jake,

thanks for the feedback. This contributes to the picture -- clients will 
have to expect almost everything between 400 and 499.

At the end of the day, a revised spec should

- define specific RFC3253-like precondition identifiers, so that new 
software can precisely find out what went wrong,

- give server implementors guidelines which 4xx code to choose (in 
particular, we should answer that question whether "lock-token" 
contributes to the set of request headers that can cause a 412 
Precondition Failed),

- give client implementors guidelines how to interpret server responses 
(such as first check for DAV:error response body, then possibly fall 
back to generic HTTP status usage).

I'll try to capture this in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#method.preconditions.and.postconditions> 
today.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue Jun  8 05:31:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14287
	for <webdav-archive@lists.ietf.org>; Tue, 8 Jun 2004 05:31:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AD626A1697; Tue,  8 Jun 2004 05:31:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2A250A1697
	for <w3c-dist-auth@listhub.w3.org>; Tue,  8 Jun 2004 05:31:48 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BXcxP-0005IZ-Oq
	for w3c-dist-auth@w3.org; Tue, 08 Jun 2004 05:31:48 -0400
Received: (qmail 17268 invoked by uid 65534); 8 Jun 2004 09:31:16 -0000
Received: from p5082479C.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.71.156)
  by mail.gmx.net (mp010) with SMTP; 08 Jun 2004 11:31:16 +0200
X-Authenticated: #1915285
Message-ID: <40C5875E.2060600@gmx.de>
Date: Tue, 08 Jun 2004 11:31:10 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Jason Crawford <ccjason@us.ibm.com>
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com> <40C2E9FA.1090801@gmx.de> <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org>
In-Reply-To: <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/40C5875E.2060600@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8577
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040608093152.AD626A1697@frink.w3.org>
Resent-Date: Tue,  8 Jun 2004 05:31:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Hello client implementors! -- please respond on this thread and let us 
> know if you use the 'lockdiscovery' property value, which is returned in 
> failed LOCK requests.
> 
> (If no clients use the property value as returned in failed LOCK 
> requests -- maybe they all do another round-trip to get the value -- 
> then we might as well simplify, rather than optimize for this failure case)

OK,

I just tested Adobe Golive (the client besides our own I'm aware of 
using shared locks) with Apache/moddav, trying to get an exclusive lock 
on a resource that already has a shared lock. The response from 
Apache/moddav is a 423 Locked, so no Multistatus.

Unless I'm missing something this means that the marshalling shown in 
section 8.10.10 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) 
indeed won't help any clients at all; and as it is underspecified we 
should just get rid of it.

Proposed changes:

1) Change section 8.10.2 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>) 
to say: "The response for a successful LOCK creation request MUST 
contain the value of the lockdiscovery property in a prop XML element."

2) When we define named preconditions, define a content model for the 
precondition that will reveal the lockdiscovery property.

Jason, could you please add this to the issues list? (I'm adding this to 
my list as 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.8.10.1_lockdiscovery_on_failure>, 
please let me know if should rephrase it).


Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Wed Jun  9 09:39:54 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14661
	for <webdav-archive@lists.ietf.org>; Wed, 9 Jun 2004 09:39:54 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 58006A25CE; Wed,  9 Jun 2004 09:39:55 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 85200A2850
	for <w3c-dist-auth@listhub.w3.org>; Wed,  9 Jun 2004 09:38:15 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BY35B-0007of-8R
	for w3c-dist-auth@w3c.org; Wed, 09 Jun 2004 09:25:33 -0400
Received: (qmail 11704 invoked by uid 65534); 9 Jun 2004 13:25:01 -0000
Received: from p50824416.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.68.22)
  by mail.gmx.net (mp017) with SMTP; 09 Jun 2004 15:25:01 +0200
X-Authenticated: #1915285
Message-ID: <40C70FA4.503@gmx.de>
Date: Wed, 09 Jun 2004 15:24:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Lisa Dusseault <lisa@osafoundation.org>,
        Jason Crawford <ccjason@us.ibm.com>
References: <934AA4A0-B4A5-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDECD8.7090009@gmx.de> <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org> <40BDF36D.1040703@gmx.de> <40BF0770.7070304@gmx.de>
In-Reply-To: <40BF0770.7070304@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
X-Archived-At: http://www.w3.org/mid/40C70FA4.503@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8578
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040609133955.58006A25CE@frink.w3.org>
Resent-Date: Wed,  9 Jun 2004 09:39:55 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:
> 
> OK,
> 
> here's my attempt to summarize what Lisa and I discussed. I think this 
> should be used as resolution for the following issues:
> 
> - LOCK_BODY_SHOULD_BE_MUST
> - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
> 
> Note that the description below does *not* change the original 
> semantics; it's just a clarification that seems to be in sync with 
> current implementations (and that's what we should be looking for when 
> updating the protocol)...:
> 
> 1) A LOCK request with message body is a LOCK create request. A LOCK 
> request without a message body is a LOCK refresh request.
> 
> 2) A LOCK refresh request refreshes those locks on the request resource 
> whose lock tokens are submitted in the "If" header and whose lock-root 
> is the resource identified by the request URI. A server MAY support 
> using the Time-Out header to set a new timeout, but clients can not rely 
> on that behaviour.
> 
> 2a) In the case of a shared lock it's technically feasable to submit 
> lock tokens for multiple locks to be refreshed in one "If" header. The 
> semantics for that seem to be clear from 2), but it's doubtful whether a 
> client will ever want to do that. IMHO it doesn't make any sense to put 
> in the additional wording to forbid it, though (that's where I disagreed 
> with Lisa...).
> 
> Note that if we stick with this resolution, the LOCK refresh changes in 
> RFC2518bis-05 will need to be rolled back.

OK,

can we please make a decision?

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Fri Jun 11 04:03:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05302
	for <webdav-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:03:22 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 62B6FA2C7B; Fri, 11 Jun 2004 04:03:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D49DCA2C7C
	for <w3c-dist-auth@listhub.w3.org>; Fri, 11 Jun 2004 04:03:20 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BYh0I-0003aS-0w
	for w3c-dist-auth@w3.org; Fri, 11 Jun 2004 04:03:10 -0400
Received: (qmail 5002 invoked by uid 65534); 11 Jun 2004 08:02:37 -0000
Received: from pD953539B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.83.155)
  by mail.gmx.net (mp009) with SMTP; 11 Jun 2004 10:02:37 +0200
X-Authenticated: #1915285
Message-ID: <40C96715.1010304@gmx.de>
Date: Fri, 11 Jun 2004 10:02:29 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Fwd: I-D ACTION:draft-reschke-webdav-locking-02.txt]
X-Archived-At: http://www.w3.org/mid/40C96715.1010304@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8579
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040611080323.62B6FA2C7B@frink.w3.org>
Resent-Date: Fri, 11 Jun 2004 04:03:23 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I have submitted another version of my experimental stand-alone locking 
protocol document.  Revision 02 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-02.html>) 
has the following changes:

    Update "008_URI_URL", "040_LOCK_ISSUES_06",
    "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY",
    "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN".
    Re-opened "065_UNLOCK_WHAT_URL".  Close
    "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER".  Rewrite UNLOCK and LOCK
    refresh method descriptions.  Fix page title (TXT version).  Close
    "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH",
    "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER".  Add and
    resolve "8.10.1_lockdiscovery_on_failure".  Started attempt to
    clarify status code.

The main changes are that the method descriptions for LOCK refresh and 
UNLOCK have been rewritten (LOCK create still to be done).

As usual, edits are ongoing on
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>. 
The current issues list is at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>.

Best regards, Julian


-------- Original Message --------
From: - Thu Jun 10 16:42:16 2004
X-UIDL: 9e7be0088c2066c6a593ac3c436cec25
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-Path: <i-d-announce-bounces@ietf.org>
X-Flags: 0000
Delivered-To: GMX delivery to julian.reschke@gmx.de
Received: (qmail 9138 invoked by uid 65534); 9 Jun 2004 20:32:15 -0000
Received: from megatron.ietf.org (EHLO megatron.ietf.org) (132.151.6.71) 
  by mx0.gmx.net (mx043) with SMTP; 09 Jun 2004 22:32:15 +0200
Received: from localhost.localdomain ([127.0.0.1] 
helo=megatron.ietf.org)	by megatron.ietf.org with esmtp (Exim 4.32)	id 
1BY8xP-0000qd-D3; Wed, 09 Jun 2004 15:41:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)	by 
megatron.ietf.org with esmtp (Exim 4.32) id 1BY8q1-0006U7-Cw	for 
i-d-announce@megatron.ietf.org; Wed, 09 Jun 2004 15:34:17 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org 
(8.9.1a/8.9.1a) with ESMTP id PAA13058	for <i-d-announce@ietf.org>; Wed, 
9 Jun 2004 15:34:15 -0400 (EDT)
Message-Id: <200406091934.PAA13058@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Wed, 09 Jun 2004 15:34:15 -0400
Subject: I-D ACTION:draft-reschke-webdav-locking-02.txt
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: 
<https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
	Author(s)	: J. Reschke
	Filename	: draft-reschke-webdav-locking-02.txt
	Pages		: 50
	Date		: 2004-6-9
	
This document specifies a set of methods and headers ancillary to
    HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
    RFC2518) for the management of resource locking (collision
    avoidance).  It updates those sections from RFC2518 that specify
    WebDAV's locking features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-reschke-webdav-locking-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-reschke-webdav-locking-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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



From w3c-dist-auth-request@w3.org  Sat Jun 12 09:46:32 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29730
	for <webdav-archive@lists.ietf.org>; Sat, 12 Jun 2004 09:46:32 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C4C5BA19F6; Sat, 12 Jun 2004 09:46:33 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1328EA19F6
	for <w3c-dist-auth@listhub.w3.org>; Sat, 12 Jun 2004 09:46:30 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BZ8q5-0004D8-QF
	for w3c-dist-auth@w3.org; Sat, 12 Jun 2004 09:46:30 -0400
Received: (qmail 25190 invoked by uid 65534); 12 Jun 2004 13:45:57 -0000
Received: from pD9E51178.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.17.120)
  by mail.gmx.net (mp022) with SMTP; 12 Jun 2004 15:45:57 +0200
X-Authenticated: #1915285
Message-ID: <40CB090E.5060200@gmx.de>
Date: Sat, 12 Jun 2004 15:45:50 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <40BB2F7D.3060606@gmx.de> <40BB386B.4040807@gmx.de>
In-Reply-To: <40BB386B.4040807@gmx.de>
Content-Type: multipart/mixed;
 boundary="------------040006090904040409020300"
Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40CB090E.5060200@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8580
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040612134633.C4C5BA19F6@frink.w3.org>
Resent-Date: Sat, 12 Jun 2004 09:46:33 -0400 (EDT)


This is a multi-part message in MIME format.
--------------040006090904040409020300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julian Reschke wrote:

>> I just noticed that in
>>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
>>
>> we write...:
>>
>>   "An UNLOCK request deletes the lock with the specified lock token.
>>   The request-URL of the request MUST identify the resource that
>>   is directly locked by that lock.  After a lock is deleted,
>>   no resource is locked by that lock."
>>
>> This was a change to the previous GULP version. However, the 
>> discussion attached to issue entry UNLOCK_WHAT_URL 
>> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that 
>> we agreed upon allowing any URL protected by the lock to be used as 
>> request URL.
>>
>> 1) We should agree on one of the two; and fix the other document 
>> accordingly.
>>
>> 2) RFC2518 seems to allow both interpretations:
>>
>>    "The UNLOCK method removes the lock identified by the lock token
>>    in the Lock-Token request header from the Request-URI, and all
>>    other resources included in the lock."
>>
>> 3) Back when I tested this, both Apache/moddav and Xythos were 
>> implementing this, and so are we (I think). Microsoft IIS doesn't 
>> support deep locks, so it's not relevant here.
>>
>> Therefore it seems that we should undo that particular change from 
>> GULP 5.5 for the sake of interoperability with older clients that may 
>> rely on it (this seems to be harmless).
> 
> 
> Adding to the confusion, I just find out that RFC2518bis-05 says it 
> needs to be directly locked as well (well, I guess it *tries* to say 
> that, see... 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0115.html>).
> 
> Can we please make a decision *and* make sure that it's tracked on the 
> issues list? An issues list that is not only out of sync but even 
> contradicts the latest draft really doesn't help much :-)

OK,

here are some actual test results:

a) Apache/moddav: allows UNLOCK on indirectly locked resources,
b) Xythos: same,
c) SAP Enterprise Portal: same,
d) Microsoft IIS: no support for depth infinity locks.

Thus the current text in the issues resolution "Resolved that you can 
specify any URL locked by the lock you want to unlock" does indeed 
reflect current implementation experience, and this is what spec 
revisions should be saying.

Thus:

1) RFC2518bis should undo that change, and
2) GULP should be updated accordingly (I'll do that for my in-document 
copy of GULP at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C>.


Best regards, Julian


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

--------------040006090904040409020300
Content-Type: application/x-gzip;
 name="065_UNLOCK_WHAT_URL.js.gz"
Content-Disposition: inline;
 filename="065_UNLOCK_WHAT_URL.js.gz"
Content-Transfer-Encoding: base64

H4sICDr8ykACAzA2NV9VTkxPQ0tfV0hBVF9VUkwuanMA3VZLb9NAED4TKf9h2EPj0DRJw+MQ
mkgVRapESksToBLi4NqTxNTZTffRpqL8d2bXdmo7hkYILty8M/PNzn7z8o0vQeI1DIDjLRwG
OrrBi9PLbxho8NjJ+OJk1GuPUd6gpM/jyeSMNV/Xa/XaDQGNjAj4eRzIaKnbh3JmFsi18rrW
xBkolNa1ieNUsrwNHwT1WjQFbwPfjpHP9ByGsN+E7/UaZH42b9q3N/3YwlPPeXqSXL/pp7f2
U69NDScaBIfQLJbnqJaCK/RkGkqGfRvMhSfbSvvaKIveUM1QH8Zx5uAY/RCl8pqVtjK1muBK
r0PpdCCQ6GuEQMQxuqDqtQKSnbx7czoCBrs2GRZJyWyLJfJUxVpW0YKpHytsOSJbNgmZqUIe
evZg+fOcxL0IDqDX7cL9PeRkwwE873absLOTlz4dwIvuyyp6mOG4WlLgGEJqbOiZ4CLr26Bz
bnbpFZmoTMeD3w8m0utsFROE10llEm1Lo4kzrim3ZcLOPk4yuuyVHZ8VWSN9wlmqfYQ6NhXi
0pcso3BLBrfniuLpwz+maiEkbslX73d09f5vtooRjE7fvKtuPKt5vO/0OV4bVDoZDB47wqWe
E4xFfBrxSN+xX9tOogUKo631GClx4d6rLisyfXDUj0VwRc4ErBYxV/2jQePo8FO/MUxVKqBw
7QFXQWwUDf7O8KBT0tmDvku+b2WkczaJuPNwz9CFUM2dnf0OJK6Q5zeAlndJfvNa+4yZfXV+
dnrMmuw5G5YmKvB1MAdvRTWy3gI5R8k9tqoKQsYqa0q5NQdhFAIXmoLQRnKHBAdtAQUb8Rlk
VQSXIkzSVB7olaWWl9IytXk9k8Sz1Hce5TGd8COfz4w/Q5vcizOfaiJBl/kperLgMcUW43sR
osc6nWdfCOHHe9xfoNccNOYSp42vrNnWFFDCHlJtbpK//m4rc6m0JK/efisnTpfqHhS3b67l
iOPNbnbC/Urm176T5l0fm+U4izCiQBgZoEuXBWHYSsfB35gC6YRUvu1GCOYYXPVtCYDhriho
3gg9p4oxXGLs21mUReSAOdNgHsVheYJ8fJ+fIVXTNbHYdsCWp8TItsvEtQvV0kGBWettyDb+
Aqqb9w9fs7Fby895ZL3+s/f8BL6ski71CgAA
--------------040006090904040409020300--



From w3c-dist-auth-request@w3.org  Sat Jun 12 13:37:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11433
	for <webdav-archive@lists.ietf.org>; Sat, 12 Jun 2004 13:37:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EC24AA0858; Sat, 12 Jun 2004 13:37:28 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP
	id 46322A0746; Sat, 12 Jun 2004 13:37:15 -0400 (EDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BZCPg-0004At-Hz; Sat, 12 Jun 2004 13:35:28 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5CHYtdI596154;
	Sat, 12 Jun 2004 13:34:55 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5CHZdqG116130;
	Sat, 12 Jun 2004 13:35:39 -0400
In-Reply-To: <40CB090E.5060200@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF7C34425B.E8C9F51A-ON85256EB1.00608127-85256EB1.00609227@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 12 Jun 2004 13:34:25 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/12/2004 13:34:31,
	Serialize complete at 06/12/2004 13:34:31
Content-Type: multipart/alternative; boundary="=_alternative 0060922585256EB1_="
Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/OF7C34425B.E8C9F51A-ON85256EB1.00608127-85256EB1.00609227@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8581
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040612173728.EC24AA0858@frink.w3.org>
Resent-Date: Sat, 12 Jun 2004 13:37:28 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0060922585256EB1_=
Content-Type: text/plain; charset="US-ASCII"

I agree.

Cheers,
Geoff

Julian wrote on 06/12/2004 09:45:50 AM:

> Julian Reschke wrote:
> 
> here are some actual test results:
> 
> a) Apache/moddav: allows UNLOCK on indirectly locked resources,
> b) Xythos: same,
> c) SAP Enterprise Portal: same,
> d) Microsoft IIS: no support for depth infinity locks.
> 
> Thus the current text in the issues resolution "Resolved that you can 
> specify any URL locked by the lock you want to unlock" does indeed 
> reflect current implementation experience, and this is what spec 
> revisions should be saying.
> 
> Thus:
> 
> 1) RFC2518bis should undo that change, and
> 2) GULP should be updated accordingly (I'll do that for my in-document 
> copy of GULP at 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.C>.

--=_alternative 0060922585256EB1_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I agree.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/12/2004 09:45:50 AM:<br>
<br>
&gt; Julian Reschke wrote:<br>
&gt; <br>
&gt; here are some actual test results:<br>
&gt; <br>
&gt; a) Apache/moddav: allows UNLOCK on indirectly locked resources,<br>
&gt; b) Xythos: same,<br>
&gt; c) SAP Enterprise Portal: same,<br>
&gt; d) Microsoft IIS: no support for depth infinity locks.<br>
&gt; <br>
&gt; Thus the current text in the issues resolution &quot;Resolved that
you can <br>
&gt; specify any URL locked by the lock you want to unlock&quot; does indeed
<br>
&gt; reflect current implementation experience, and this is what spec <br>
&gt; revisions should be saying.<br>
&gt; <br>
&gt; Thus:<br>
&gt; <br>
&gt; 1) RFC2518bis should undo that change, and<br>
&gt; 2) GULP should be updated accordingly (I'll do that for my in-document
<br>
&gt; copy of GULP at <br>
&gt; &lt;http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-<br>
&gt; latest.html#rfc.section.C&gt;.<br>
</tt></font>
--=_alternative 0060922585256EB1_=--



From w3c-dist-auth-request@w3.org  Mon Jun 14 05:28:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16362
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 05:28:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C9377A2215; Mon, 14 Jun 2004 05:28:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 77F36A21FD
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 05:28:05 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BZnl5-0001VY-N1
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 05:28:03 -0400
Received: (qmail 5340 invoked by uid 65534); 14 Jun 2004 09:27:31 -0000
Received: from p50824176.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.65.118)
  by mail.gmx.net (mp006) with SMTP; 14 Jun 2004 11:27:31 +0200
X-Authenticated: #1915285
Message-ID: <40CD6F82.7090505@gmx.de>
Date: Mon, 14 Jun 2004 11:27:30 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OF7C34425B.E8C9F51A-ON85256EB1.00608127-85256EB1.00609227@us.ibm.com>
In-Reply-To: <OF7C34425B.E8C9F51A-ON85256EB1.00608127-85256EB1.00609227@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40CD6F82.7090505@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8582
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614092811.C9377A2215@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 05:28:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> 
> I agree.

ok,

below the new version...:

-------------- GULP (Version 5.7) --------------

- A lock either directly or indirectly locks a resource.

- A LOCK request with a non-empty body creates a new lock, and the
   resource identified by the request-URL is directly locked by that lock.
   The "lock-root" of the new lock is the request-URL. If at the time of
   the request, the request-URL is not mapped to a resource, a new
   resource with no content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
   members of that collection (other than the collection itself) are
   indirectly locked by that lock.  In particular, if an internal
   member resource is added to a collection that is locked by a
   depth:infinity lock, and if the resource is not locked by that lock,
   then the resource becomes indirectly locked by that lock.
   Conversely, if a resource is indirectly locked with a depth:infinity
   lock, and if the result of deleting an internal member URI is that
   the resource is no longer a member of the collection that is
   directly locked by that lock, then the resource is no longer locked
   by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
   The request-URL of the request MUST identify a resource that
   is either directly or indirectly locked by that lock.
   After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
   header.

- If a request would modify the content for a locked resource, a dead
   property of a locked resource, a live property that is defined to be
   lockable for a locked resource, or an internal member URI of a
   locked collection, the request MUST fail unless the lock-token for
   that lock is submitted in the request.  An internal member URI
   of a collection is considered to be modified if it is added,
   removed, or identifies a different resource.

- If a request causes a directly locked resource to no longer be
   mapped to the lock-root of that lock, then the request MUST
   fail unless the lock-token for that lock is submitted in the
   request.  If the request succeeds, then that lock MUST have been
   deleted by that request.

- If a request would cause a resource to be locked by two different
   exclusive locks, the request MUST fail.



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



From w3c-dist-auth-request@w3.org  Mon Jun 14 11:19:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08845
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 11:19:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9A39EA19D1; Mon, 14 Jun 2004 11:19:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1798CA19D1
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 11:19:41 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BZtFM-0008Hs-Ua
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 11:19:41 -0400
Received: (qmail 27457 invoked by uid 65534); 14 Jun 2004 15:19:09 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10)
  by mail.gmx.net (mp006) with SMTP; 14 Jun 2004 17:19:09 +0200
X-Authenticated: #1915285
Message-ID: <40CDC1E9.2020007@gmx.de>
Date: Mon, 14 Jun 2004 17:19:05 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OF7C34425B.E8C9F51A-ON85256EB1.00608127-85256EB1.00609227@us.ibm.com> <40CD6F82.7090505@gmx.de>
In-Reply-To: <40CD6F82.7090505@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40CDC1E9.2020007@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8583
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614151943.9A39EA19D1@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 11:19:43 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> ...
>   The "lock-root" of the new lock is the request-URL. If at the time of
>   the request, the request-URL is not mapped to a resource, a new
>   resource with no content MUST be created by the request.
 > ...

Stefan (rightfully) points out that this should say "...with empty 
content...". "No content" might be interpreted as defining that a GET on 
that resource would return a 404, which is not what we want.

Is everybody ok with thst minor change?

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Mon Jun 14 12:32:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13346
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 12:32:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 67918A0DCE; Mon, 14 Jun 2004 12:32:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1E316A19D5
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 12:32:55 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BZuOE-0007SX-LT
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 12:32:54 -0400
Received: (qmail 20774 invoked by uid 65534); 14 Jun 2004 16:32:23 -0000
Received: from p50824176.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.65.118)
  by mail.gmx.net (mp003) with SMTP; 14 Jun 2004 18:32:23 +0200
X-Authenticated: #1915285
Message-ID: <40CDD310.6030105@gmx.de>
Date: Mon, 14 Jun 2004 18:32:16 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: new DELETE vs collection lock issue
X-Archived-At: http://www.w3.org/mid/40CDD310.6030105@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8584
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614163258.67918A0DCE@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 12:32:58 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

Section 7.5 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>) states...:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove a resource which has a URI which is an 
existing internal member URI of a write locked collection, this request 
MUST fail if the principal does not have a write lock on the collection."

(the same text appears in RFC2518bis-05).

This is consistent with RFC2518's definition of DELETE, namely 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.6.1>):

"If the DELETE method is issued to a non-collection resource whose URIs 
are an internal member of one or more collections, then during DELETE 
processing a server MUST remove any URI for the resource identified by 
the Request-URI from collections which contain it as a member."

However the requirement to remove *all* URIs mapped to the resource is 
incompatible with BIND (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4.p.1>) 
and has been removed in RFC2518bis-05. Thus we should rewrite section 
7.5 as:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove an internal member URI of a write locked 
collection, this request MUST fail if the principal does not have a 
write lock on the collection."


Jason, could you please add this to the issues list?

Julian

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



From w3c-dist-auth-request@w3.org  Mon Jun 14 12:42:11 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13880
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 12:42:10 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 230A1A1C33; Mon, 14 Jun 2004 12:42:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B9C81A2073
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 12:42:10 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BZuXC-0000vh-JL
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 12:42:10 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5EGfesV736046
	for <w3c-dist-auth@w3.org>; Mon, 14 Jun 2004 12:41:40 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5EGgUWx115494
	for <w3c-dist-auth@w3.org>; Mon, 14 Jun 2004 12:42:43 -0400
In-Reply-To: <40CDD310.6030105@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF05BD399B.1BEA462B-ON85256EB3.005B8032-85256EB3.005B9254@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 14 Jun 2004 12:39:48 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/14/2004 12:41:14,
	Serialize complete at 06/14/2004 12:41:14
Content-Type: multipart/alternative; boundary="=_alternative 005B924685256EB3_="
Subject: Re: new DELETE vs collection lock issue
X-Archived-At: http://www.w3.org/mid/OF05BD399B.1BEA462B-ON85256EB3.005B8032-85256EB3.005B9254@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8585
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614164213.230A1A1C33@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 12:42:13 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 005B924685256EB3_=
Content-Type: text/plain; charset="US-ASCII"

I agree that this section should be modified in the way Julian species 
below.

Cheers,
Geoff



Hi,

Section 7.5 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>) 
states...:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove a resource which has a URI which is an 
existing internal member URI of a write locked collection, this request 
MUST fail if the principal does not have a write lock on the collection."

(the same text appears in RFC2518bis-05).

This is consistent with RFC2518's definition of DELETE, namely 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.6.1>):

"If the DELETE method is issued to a non-collection resource whose URIs 
are an internal member of one or more collections, then during DELETE 
processing a server MUST remove any URI for the resource identified by 
the Request-URI from collections which contain it as a member."

However the requirement to remove *all* URIs mapped to the resource is 
incompatible with BIND (see 
<
http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4.p.1
>) 
and has been removed in RFC2518bis-05. Thus we should rewrite section 
7.5 as:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove an internal member URI of a write locked 
collection, this request MUST fail if the principal does not have a 
write lock on the collection."


Jason, could you please add this to the issues list?

Julian

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



--=_alternative 005B924685256EB3_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">I agree that this section should be
modified in the way Julian species below.</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br><font size=2 face="sans-serif">Geoff</font>
<br>
<br>
<br><font size=2><tt><br>
Hi,<br>
<br>
Section 7.5 of RFC2518 <br>
(&lt;http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5&gt;)
states...:<br>
<br>
&quot;As a consequence, when a principal issues a PUT or POST request to
<br>
create a new resource under a URI which needs to be an internal member
<br>
of a write locked collection to maintain HTTP namespace consistency, or
<br>
issues a DELETE to remove a resource which has a URI which is an <br>
existing internal member URI of a write locked collection, this request
<br>
MUST fail if the principal does not have a write lock on the collection.&quot;<br>
<br>
(the same text appears in RFC2518bis-05).<br>
<br>
This is consistent with RFC2518's definition of DELETE, namely <br>
(&lt;http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.6.1&gt;):<br>
<br>
&quot;If the DELETE method is issued to a non-collection resource whose
URIs <br>
are an internal member of one or more collections, then during DELETE <br>
processing a server MUST remove any URI for the resource identified by
<br>
the Request-URI from collections which contain it as a member.&quot;<br>
<br>
However the requirement to remove *all* URIs mapped to the resource is
<br>
incompatible with BIND (see <br>
&lt;http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4.p.1&gt;)
<br>
and has been removed in RFC2518bis-05. Thus we should rewrite section <br>
7.5 as:<br>
<br>
&quot;As a consequence, when a principal issues a PUT or POST request to
<br>
create a new resource under a URI which needs to be an internal member
<br>
of a write locked collection to maintain HTTP namespace consistency, or
<br>
issues a DELETE to remove an internal member URI of a write locked <br>
collection, this request MUST fail if the principal does not have a <br>
write lock on the collection.&quot;<br>
<br>
<br>
Jason, could you please add this to the issues list?<br>
<br>
Julian<br>
<br>
-- <br>
&lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
<br>
</tt></font>
<br>
--=_alternative 005B924685256EB3_=--



From w3c-dist-auth-request@w3.org  Mon Jun 14 12:58:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14971
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 12:58:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 11268A22C4; Mon, 14 Jun 2004 12:58:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 86862A22C4
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 12:58:43 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BZunD-0003hQ-Fd
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 12:58:43 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5EGwC18429734
	for <w3c-dist-auth@w3.org>; Mon, 14 Jun 2004 12:58:12 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5EGx7Wr135904
	for <w3c-dist-auth@w3.org>; Mon, 14 Jun 2004 12:59:16 -0400
In-Reply-To: <40CDC1E9.2020007@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF402134C7.DB31113C-ON85256EB3.005D28DE-85256EB3.005D3748@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 14 Jun 2004 12:57:46 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/14/2004 12:57:46,
	Serialize complete at 06/14/2004 12:57:46
Content-Type: multipart/alternative; boundary="=_alternative 005D374185256EB3_="
Subject: Re: GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/OF402134C7.DB31113C-ON85256EB3.005D28DE-85256EB3.005D3748@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8586
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614165847.11268A22C4@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 12:58:47 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 005D374185256EB3_=
Content-Type: text/plain; charset="US-ASCII"

I agree with that fix.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 06/14/2004 11:19:05 AM:

> Julian Reschke wrote:
> 
> > ...
> >   The "lock-root" of the new lock is the request-URL. If at the time 
of
> >   the request, the request-URL is not mapped to a resource, a new
> >   resource with no content MUST be created by the request.
>  > ...
> 
> Stefan (rightfully) points out that this should say "...with empty 
> content...". "No content" might be interpreted as defining that a GET on 

> that resource would return a 404, which is not what we want.
> 
> Is everybody ok with thst minor change?

--=_alternative 005D374185256EB3_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I agree with that fix.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote
on 06/14/2004 11:19:05 AM:<br>
<br>
&gt; Julian Reschke wrote:<br>
&gt; <br>
&gt; &gt; ...<br>
&gt; &gt; &nbsp; The &quot;lock-root&quot; of the new lock is the request-URL.
If at the time of<br>
&gt; &gt; &nbsp; the request, the request-URL is not mapped to a resource,
a new<br>
&gt; &gt; &nbsp; resource with no content MUST be created by the request.<br>
&gt; &nbsp;&gt; ...<br>
&gt; <br>
&gt; Stefan (rightfully) points out that this should say &quot;...with
empty <br>
&gt; content...&quot;. &quot;No content&quot; might be interpreted as defining
that a GET on <br>
&gt; that resource would return a 404, which is not what we want.<br>
&gt; <br>
&gt; Is everybody ok with thst minor change?<br>
</tt></font>
--=_alternative 005D374185256EB3_=--



From w3c-dist-auth-request@w3.org  Mon Jun 14 13:16:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16025
	for <webdav-archive@lists.ietf.org>; Mon, 14 Jun 2004 13:16:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0FEDBA24D1; Mon, 14 Jun 2004 13:13:42 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DF851A24D1
	for <w3c-dist-auth@listhub.w3.org>; Mon, 14 Jun 2004 13:13:37 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BZv1d-0006bs-PS
	for w3c-dist-auth@w3.org; Mon, 14 Jun 2004 13:13:37 -0400
Received: (qmail 19175 invoked by uid 65534); 14 Jun 2004 17:13:06 -0000
Received: from p50824176.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.65.118)
  by mail.gmx.net (mp001) with SMTP; 14 Jun 2004 19:13:06 +0200
X-Authenticated: #1915285
Message-ID: <40CDDCA1.9050206@gmx.de>
Date: Mon, 14 Jun 2004 19:13:05 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OF402134C7.DB31113C-ON85256EB3.005D28DE-85256EB3.005D3748@us.ibm.com>
In-Reply-To: <OF402134C7.DB31113C-ON85256EB3.005D28DE-85256EB3.005D3748@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: GULP 5.8, was: GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40CDDCA1.9050206@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8587
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040614171342.0FEDBA24D1@frink.w3.org>
Resent-Date: Mon, 14 Jun 2004 13:13:42 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> 
> I agree with that fix.

OK, here we go...:

-------------- GULP (Version 5.8) --------------

- A lock either directly or indirectly locks a resource.

- A LOCK request with a non-empty body creates a new lock, and the
   resource identified by the request-URL is directly locked by that lock.
   The "lock-root" of the new lock is the request-URL. If at the time of
   the request, the request-URL is not mapped to a resource, a new
   resource with empty content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
   members of that collection (other than the collection itself) are
   indirectly locked by that lock.  In particular, if an internal
   member resource is added to a collection that is locked by a
   depth:infinity lock, and if the resource is not locked by that lock,
   then the resource becomes indirectly locked by that lock.
   Conversely, if a resource is indirectly locked with a depth:infinity
   lock, and if the result of deleting an internal member URI is that
   the resource is no longer a member of the collection that is
   directly locked by that lock, then the resource is no longer locked
   by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
   The request-URL of the request MUST identify a resource that
   is either directly or indirectly locked by that lock.
   After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
   header.

- If a request would modify the content for a locked resource, a dead
   property of a locked resource, a live property that is defined to be
   lockable for a locked resource, or an internal member URI of a
   locked collection, the request MUST fail unless the lock-token for
   that lock is submitted in the request.  An internal member URI
   of a collection is considered to be modified if it is added,
   removed, or identifies a different resource.

- If a request causes a directly locked resource to no longer be
   mapped to the lock-root of that lock, then the request MUST
   fail unless the lock-token for that lock is submitted in the
   request.  If the request succeeds, then that lock MUST have been
   deleted by that request.

- If a request would cause a resource to be locked by two different
   exclusive locks, the request MUST fail.



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



From w3c-dist-auth-request@w3.org  Tue Jun 15 03:05:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27776
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 03:05:55 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9AB8FA1B7D; Tue, 15 Jun 2004 03:05:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5D4A7A1B7D
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 03:05:49 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1Ba80z-0002fz-5r
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 03:05:49 -0400
Received: (qmail 16529 invoked by uid 65534); 15 Jun 2004 07:05:16 -0000
Received: from pD9E51A64.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.26.100)
  by mail.gmx.net (mp013) with SMTP; 15 Jun 2004 09:05:16 +0200
X-Authenticated: #1915285
Message-ID: <40CE9FA5.3020503@gmx.de>
Date: Tue, 15 Jun 2004 09:05:09 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Jason Crawford <ccjason@us.ibm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Resolve Issue 67 UNLOCK_NEEDS_IF_HEADER
X-Archived-At: http://www.w3.org/mid/40CE9FA5.3020503@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8588
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615070552.9AB8FA1B7D@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 03:05:52 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Hi,

this issue (<http://www.webdav.org/wg/rfcdev/issues.htm>) reads:

"Shouldn’t we be using an IF header to do an UNLOCK seeing as you need 
to prove you are holding a lock before you can remove it?  (This might 
be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)"

The tests that I have done (for other UNLOCK related issues) show that 
servers indeed use the "Lock-Token" request header to indicate the lock 
to be removed; and that they do not require an additional "If" header. 
This may have been a valid point before the spec was finished, but now 
as we're talking about progressing/clarifying the protocol, we should 
just reject that issue.

Jason, can you please update the issues list? I'll update 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.067_UNLOCK_NEEDS_IF_HEADER> 
accordingly.

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Tue Jun 15 06:56:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09980
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 06:56:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 551DBA22C1; Tue, 15 Jun 2004 06:56:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A5B4CA237E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 06:56:10 -0400 (EDT)
Received: from e33.co.us.ibm.com ([32.97.110.131])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BaBbu-0007d6-F4
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 06:56:10 -0400
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10])
	by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5FAtdwc604910
	for <w3c-dist-auth@w3.org>; Tue, 15 Jun 2004 06:55:39 -0400
Received: from d01ml261.pok.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FAtc1W629924
	for <w3c-dist-auth@w3.org>; Tue, 15 Jun 2004 04:55:39 -0600
In-Reply-To: <40CE9FA5.3020503@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF3B62113C.7D0A4733-ON85256EB4.003BB79B-85256EB4.003C04D2@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 15 Jun 2004 06:55:10 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/15/2004 06:55:13,
	Serialize complete at 06/15/2004 06:55:13
Content-Type: multipart/alternative; boundary="=_alternative 003C04CD85256EB4_="
Subject: Re: Resolve Issue 67 UNLOCK_NEEDS_IF_HEADER
X-Archived-At: http://www.w3.org/mid/OF3B62113C.7D0A4733-ON85256EB4.003BB79B-85256EB4.003C04D2@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8589
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615105613.551DBA22C1@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 06:56:13 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 003C04CD85256EB4_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

QW5kIGlmIHRoZSBmYWN0cyBvbiB0aGUgZ3JvdW5kIHdlcmVuJ3QgZW5vdWdoLCBpdCBkb2Vzbid0
DQptYWtlIHNlbnNlIGFueXdheSwgYmVjYXVzZSBhbnkgYXV0aG9yaXplZCB1c2VyIHNob3VsZCBi
ZQ0KYWJsZSB0byByZW1vdmUgYSBsb2NrICh0byBhbGxvdyB0aGUgcmVtb3ZhbCBvZiBhIGxvY2sg
d2hlbg0KdGhlIGNsaWVudCBvd25pbmcgdGhlIGxvY2sgbm8gbG9uZ2VyIGV4aXN0cyBvciBpcyBt
aXNiZWhhdmluZykuDQoNClNvIEkgY29uY3VyIHRoYXQgdGhpcyBpc3N1ZSBzaG91bGQgYmUgbWFy
a2VkIHJlc29sdmVkLA0Kd2l0aCBubyBhY3Rpb24uDQoNCkNoZWVycywNCkdlb2ZmDQoNCkp1bGlh
biB3cm90ZSBvbiAwNi8xNS8yMDA0IDAzOjA1OjA5IEFNOg0KPg0KPiB0aGlzIGlzc3VlICg8aHR0
cDovL3d3dy53ZWJkYXYub3JnL3dnL3JmY2Rldi9pc3N1ZXMuaHRtPikgcmVhZHM6DQo+IA0KPiAi
U2hvdWxkbuKAmXQgd2UgYmUgdXNpbmcgYW4gSUYgaGVhZGVyIHRvIGRvIGFuIFVOTE9DSyBzZWVp
bmcgYXMgeW91IG5lZWQgDQo+IHRvIHByb3ZlIHlvdSBhcmUgaG9sZGluZyBhIGxvY2sgYmVmb3Jl
IHlvdSBjYW4gcmVtb3ZlIGl0PyAgKFRoaXMgbWlnaHQgDQo+IGJlIGNvbnRpbmdlbnQgb24gTE9D
S1NfU0hPVUxEX1RIRVlfVVNFX0FOX0lGX0hFQURFUl9UT19WRVJJRlkpIg0KPiANCj4gVGhlIHRl
c3RzIHRoYXQgSSBoYXZlIGRvbmUgKGZvciBvdGhlciBVTkxPQ0sgcmVsYXRlZCBpc3N1ZXMpIHNo
b3cgdGhhdCANCj4gc2VydmVycyBpbmRlZWQgdXNlIHRoZSAiTG9jay1Ub2tlbiIgcmVxdWVzdCBo
ZWFkZXIgdG8gaW5kaWNhdGUgdGhlIGxvY2sgDQo+IHRvIGJlIHJlbW92ZWQ7IGFuZCB0aGF0IHRo
ZXkgZG8gbm90IHJlcXVpcmUgYW4gYWRkaXRpb25hbCAiSWYiIGhlYWRlci4gDQo+IFRoaXMgbWF5
IGhhdmUgYmVlbiBhIHZhbGlkIHBvaW50IGJlZm9yZSB0aGUgc3BlYyB3YXMgZmluaXNoZWQsIGJ1
dCBub3cgDQo+IGFzIHdlJ3JlIHRhbGtpbmcgYWJvdXQgcHJvZ3Jlc3NpbmcvY2xhcmlmeWluZyB0
aGUgcHJvdG9jb2wsIHdlIHNob3VsZCANCj4ganVzdCByZWplY3QgdGhhdCBpc3N1ZS4NCj4gDQo+
IEphc29uLCBjYW4geW91IHBsZWFzZSB1cGRhdGUgdGhlIGlzc3VlcyBsaXN0PyBJJ2xsIHVwZGF0
ZSANCj4gPGh0dHA6Ly9ncmVlbmJ5dGVzLmRlL3RlY2gvd2ViZGF2L2RyYWZ0LXJlc2Noa2Utd2Vi
ZGF2LWxvY2tpbmctDQo+IGxhdGVzdC5odG1sI3JmYy5pc3N1ZS4wNjdfVU5MT0NLX05FRURTX0lG
X0hFQURFUj4gDQo+IGFjY29yZGluZ2x5Lg0KDQoNCg==
--=_alternative 003C04CD85256EB4_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5BbmQgaWYgdGhlIGZhY3RzIG9uIHRoZSBncm91bmQgd2Vy
ZW4ndCBlbm91Z2gsIGl0DQpkb2Vzbid0PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0
dD5tYWtlIHNlbnNlIGFueXdheSwgYmVjYXVzZSBhbnkgYXV0aG9yaXplZCB1c2VyIHNob3VsZA0K
YmU8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PmFibGUgdG8gcmVtb3ZlIGEgbG9j
ayAodG8gYWxsb3cgdGhlIHJlbW92YWwgb2YgYSBsb2NrDQp3aGVuPC90dD48L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yPjx0dD50aGUgY2xpZW50IG93bmluZyB0aGUgbG9jayBubyBsb25nZXIgZXhp
c3RzIG9yIGlzDQptaXNiZWhhdmluZykuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6
ZT0yPjx0dD5TbyBJIGNvbmN1ciB0aGF0IHRoaXMgaXNzdWUgc2hvdWxkIGJlIG1hcmtlZCByZXNv
bHZlZCw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PndpdGggbm8gYWN0aW9uLjwv
dHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Q2hlZXJzLDwvdHQ+PC9mb250
Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+R2VvZmY8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9u
dCBzaXplPTI+PHR0Pkp1bGlhbiB3cm90ZSBvbiAwNi8xNS8yMDA0IDAzOjA1OjA5IEFNOjxicj4N
CiZndDs8YnI+DQomZ3Q7IHRoaXMgaXNzdWUgKCZsdDtodHRwOi8vd3d3LndlYmRhdi5vcmcvd2cv
cmZjZGV2L2lzc3Vlcy5odG0mZ3Q7KSByZWFkczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7
U2hvdWxkbuKAmXQgd2UgYmUgdXNpbmcgYW4gSUYgaGVhZGVyIHRvIGRvIGFuIFVOTE9DSyBzZWVp
bmcgYXMNCnlvdSBuZWVkIDxicj4NCiZndDsgdG8gcHJvdmUgeW91IGFyZSBob2xkaW5nIGEgbG9j
ayBiZWZvcmUgeW91IGNhbiByZW1vdmUgaXQ/ICZuYnNwOyhUaGlzDQptaWdodCA8YnI+DQomZ3Q7
IGJlIGNvbnRpbmdlbnQgb24gTE9DS1NfU0hPVUxEX1RIRVlfVVNFX0FOX0lGX0hFQURFUl9UT19W
RVJJRlkpJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSB0ZXN0cyB0aGF0IEkgaGF2ZSBk
b25lIChmb3Igb3RoZXIgVU5MT0NLIHJlbGF0ZWQgaXNzdWVzKSBzaG93DQp0aGF0IDxicj4NCiZn
dDsgc2VydmVycyBpbmRlZWQgdXNlIHRoZSAmcXVvdDtMb2NrLVRva2VuJnF1b3Q7IHJlcXVlc3Qg
aGVhZGVyIHRvIGluZGljYXRlDQp0aGUgbG9jayA8YnI+DQomZ3Q7IHRvIGJlIHJlbW92ZWQ7IGFu
ZCB0aGF0IHRoZXkgZG8gbm90IHJlcXVpcmUgYW4gYWRkaXRpb25hbCAmcXVvdDtJZiZxdW90Ow0K
aGVhZGVyLiA8YnI+DQomZ3Q7IFRoaXMgbWF5IGhhdmUgYmVlbiBhIHZhbGlkIHBvaW50IGJlZm9y
ZSB0aGUgc3BlYyB3YXMgZmluaXNoZWQsIGJ1dA0Kbm93IDxicj4NCiZndDsgYXMgd2UncmUgdGFs
a2luZyBhYm91dCBwcm9ncmVzc2luZy9jbGFyaWZ5aW5nIHRoZSBwcm90b2NvbCwgd2Ugc2hvdWxk
DQo8YnI+DQomZ3Q7IGp1c3QgcmVqZWN0IHRoYXQgaXNzdWUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IEphc29uLCBjYW4geW91IHBsZWFzZSB1cGRhdGUgdGhlIGlzc3VlcyBsaXN0PyBJJ2xsIHVwZGF0
ZSA8YnI+DQomZ3Q7ICZsdDtodHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9kcmFmdC1y
ZXNjaGtlLXdlYmRhdi1sb2NraW5nLTxicj4NCiZndDsgbGF0ZXN0Lmh0bWwjcmZjLmlzc3VlLjA2
N19VTkxPQ0tfTkVFRFNfSUZfSEVBREVSJmd0OyA8YnI+DQomZ3Q7IGFjY29yZGluZ2x5Ljxicj4N
Cjxicj4NCjwvdHQ+PC9mb250Pg0K
--=_alternative 003C04CD85256EB4_=--



From w3c-dist-auth-request@w3.org  Tue Jun 15 09:00:14 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15351
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 09:00:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D37A3A269B; Tue, 15 Jun 2004 09:00:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5AE23A269B
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 09:00:09 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BaDXr-0005uA-8T
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 09:00:07 -0400
Received: (qmail 19504 invoked by uid 65534); 15 Jun 2004 12:59:33 -0000
Received: from p50824274.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.66.116)
  by mail.gmx.net (mp001) with SMTP; 15 Jun 2004 14:59:33 +0200
X-Authenticated: #1915285
Message-ID: <40CEF2AC.1010807@gmx.de>
Date: Tue, 15 Jun 2004 14:59:24 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Jason Crawford <ccjason@us.ibm.com>
References: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com> <76B9DB9A-B8C8-11D8-9162-000A95B2BB72@osafoundation.org> <A271FE50-B8DA-11D8-ACC2-000393518B02@apple.com> <40C5616B.4040101@gmx.de>
In-Reply-To: <40C5616B.4040101@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN
X-Archived-At: http://www.w3.org/mid/40CEF2AC.1010807@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8590
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615130011.D37A3A269B@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 09:00:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


OK,

to summarize (
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.068_UNLOCK_WITHOUT_GOOD_TOKEN>):

- errors linked to missing or bad tokens in the "lock-token" request 
header do *not* cause a 412 ("lock-token" isn't part of the headers for 
which 412-style preconditions are checked),

- clients need to be able to handle all 4xx status codes anyway,

- we define a specific precondition for missing/bad lock tokens inside 
the lock-token request header, so clients can more precisely identity 
this error condition

Jason, you may want to update your issues list accordingly.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue Jun 15 17:10:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16708
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:10:27 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C2F05A089D; Tue, 15 Jun 2004 17:10:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 827D1A0C69
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 17:10:20 -0400 (EDT)
Received: from cats-mx1.ucsc.edu ([128.114.125.34] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BaLCG-0005ym-By
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 17:10:20 -0400
Received: from Tycho (dhcp-55-169.cse.ucsc.edu [128.114.55.169])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id i5FL8Gt29411
	for <w3c-dist-auth@w3.org>; Tue, 15 Jun 2004 14:08:16 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 15 Jun 2004 14:07:23 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMICEKILAAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: FW: WebDAV via squid-2.5
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEKILAAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8591
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615211025.C2F05A089D@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 17:10:25 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Jack M. Nilles [mailto:jnilles@jala.com]
Sent: Friday, June 11, 2004 4:43 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] WebDAV via squid-2.5




I am trying, unsuccessfully so far, to establish a WebDAV connection 
over a LAN via a proxy server running squid-2.5 as well as a firewall. 
The squid writers state that version 2.5 is fully supportive of WebDAV 
yet I can't establish a connection (in this case to an Apple server). 
although I have no trouble with a dialup connection. Therefore the 
problem appears to be either in teh squid configuration or the firewall. 
Any suggestions?
If I try: http://test.webdav.org/dav/
all I get is a pointer to http://test.webdav.org/. Is there a simple 
test that will help resolve which (squid or firewall) is the culprit?

-- 
Jack M. Nilles
JALA International, Inc.
971 Stonehill Lane
Los Angeles, CA 90049-1412
Tel: +1 (310) 476-3703
Fax: +1 (310) 476-6007
jnilles@jala.com
www.jala.com



From w3c-dist-auth-request@w3.org  Tue Jun 15 17:10:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16732
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:10:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6024DA118C; Tue, 15 Jun 2004 17:10:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 442DCA118C
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 17:10:21 -0400 (EDT)
Received: from cats-mx1.ucsc.edu ([128.114.125.34] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BaLCH-0005ym-0L
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 17:10:21 -0400
Received: from Tycho (dhcp-55-169.cse.ucsc.edu [128.114.55.169])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id i5FL8Gt29410
	for <w3c-dist-auth@w3.org>; Tue, 15 Jun 2004 14:08:16 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 15 Jun 2004 14:07:22 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEKILAAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009B_01C452E2.143969D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: FW: [Moderator Action] How does WebDAV handles caching ?
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEKILAAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8592
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615211030.6024DA118C@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 17:10:30 -0400 (EDT)


This is a multi-part message in MIME format.

------=_NextPart_000_009B_01C452E2.143969D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim
-----Original Message-----
From: Prashant Dhotkar [mailto:info_thirsty_engineer@techie.com]
Sent: Monday, June 14, 2004 3:20 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] How does WebDAV handles caching ?


Hello,

As you have mentioned that the WebDAV works well even when the connection
gets disconnected arbitrarily, I want to know what happens if the connection
gets disconnected when 5 MB of data is transferred out of 10 MB ? When I
restart the transfer will the transfer start from beginning of the file or
from where I lost the connection. What kind of caching technique is used by
WebDAV ? Please elaborate on this.

Thank you,



Prashant Dhotkar

Software Engg.

Pune,

India


--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://www.mail.com/?sr=signup

------=_NextPart_000_009B_01C452E2.143969D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D942580221-15062004><FONT face=3DArial color=3D#0000ff =

size=3D2>Accidentally caught by the spam filter.</FONT></SPAN></DIV>
<DIV><SPAN class=3D942580221-15062004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D942580221-15062004><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
Jim</FONT></SPAN></DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Prashant Dhotkar=20
[mailto:info_thirsty_engineer@techie.com]<BR><B>Sent:</B> Monday, June =
14, 2004=20
3:20 AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action]=20
How does WebDAV handles caching ?<BR><BR></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hello,<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">As you have mentioned that =
the=20
WebDAV works well even when the connection gets disconnected =
arbitrarily, I want=20
to know what happens if the connection gets disconnected when 5 MB of =
data is=20
transferred out of 10 MB ? When I restart the transfer will the transfer =
start=20
from beginning of the file or from where I lost the connection. What =
kind of=20
caching technique is used by WebDAV ? Please elaborate on this.=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thank you,</SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN>&nbsp;</P><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Prashant=20
Dhotkar</SPAN><SPAN style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-no-proof: =
yes">Software=20
Engg.</SPAN><SPAN style=3D"mso-no-proof: yes"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p>Pune,</o:p></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in =
0pt"><o:p><STRONG>India</STRONG></o:p></SPAN></P><BR>--=20
<P>___________________________________________________________<BR>Sign-up=
 for=20
Ads Free at Mail.com<BR><A=20
href=3D"http://mail01.mail.com/scripts/payment/adtracking.cgi?bannercode=3D=
adsfreejump01"=20
target=3D_blank>http://www.mail.com/?sr=3Dsignup</A></P></BODY></HTML>

------=_NextPart_000_009B_01C452E2.143969D0--



From w3c-dist-auth-request@w3.org  Tue Jun 15 17:52:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19282
	for <webdav-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:52:18 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EB0F6A0CAC; Tue, 15 Jun 2004 17:52:18 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E01F5A0D14
	for <w3c-dist-auth@listhub.w3.org>; Tue, 15 Jun 2004 17:52:16 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BaLqq-0003ZY-Kb
	for w3c-dist-auth@w3.org; Tue, 15 Jun 2004 17:52:16 -0400
Received: (qmail 1366 invoked by uid 65534); 15 Jun 2004 21:51:44 -0000
Received: from pD9E51A64.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.26.100)
  by mail.gmx.net (mp009) with SMTP; 15 Jun 2004 23:51:44 +0200
X-Authenticated: #1915285
Message-ID: <40CF6F6F.7000001@gmx.de>
Date: Tue, 15 Jun 2004 23:51:43 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
References: <AMEPKEBLDJJCCDEJHAMIAEKILAAA.ejw@cse.ucsc.edu>
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIAEKILAAA.ejw@cse.ucsc.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: FW: [Moderator Action] How does WebDAV handles caching ?
X-Archived-At: http://www.w3.org/mid/40CF6F6F.7000001@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8593
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040615215218.EB0F6A0CAC@frink.w3.org>
Resent-Date: Tue, 15 Jun 2004 17:52:18 -0400 (EDT)
Content-Transfer-Encoding: 7bit


> *From:* Prashant Dhotkar [mailto:info_thirsty_engineer@techie.com]
> *Sent:* Monday, June 14, 2004 3:20 AM
> *To:* w3c-dist-auth@w3.org
> *Subject:* [Moderator Action] How does WebDAV handles caching ?
> 
> Hello,
> 
> As you have mentioned that the WebDAV works well even when the 
> connection gets disconnected arbitrarily, I want to know what happens if 
> the connection gets disconnected when 5 MB of data is transferred out of 
> 10 MB ? When I restart the transfer will the transfer start from 
> beginning of the file or from where I lost the connection. What kind of 
> caching technique is used by WebDAV ? Please elaborate on this.

Same as HTTP. In this particular case this means that the client can do 
a GET request specifying a byte range for the remainder of the resource.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Jun 17 13:53:58 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27873
	for <webdav-archive@lists.ietf.org>; Thu, 17 Jun 2004 13:53:58 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2F3DEA2260; Thu, 17 Jun 2004 13:53:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 337C4A23EC
	for <w3c-dist-auth@listhub.w3.org>; Thu, 17 Jun 2004 13:53:55 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1Bb15G-0001vn-VR
	for w3c-dist-auth@w3.org; Thu, 17 Jun 2004 13:53:55 -0400
Received: (qmail 2093 invoked by uid 65534); 17 Jun 2004 17:53:23 -0000
Received: from p50824252.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.66.82)
  by mail.gmx.net (mp026) with SMTP; 17 Jun 2004 19:53:23 +0200
X-Authenticated: #1915285
Message-ID: <40D1DA91.2050907@gmx.de>
Date: Thu, 17 Jun 2004 19:53:21 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: resolving 057_LOCK_SEMANTICS 
X-Archived-At: http://www.w3.org/mid/40D1DA91.2050907@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8594
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040617175358.2F3DEA2260@frink.w3.org>
Resent-Date: Thu, 17 Jun 2004 13:53:58 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I have resolved 057_LOCK_SEMANTICS in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 
with the following changes (see previous mailing list discussion in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57>):


a) Define a generic precondition:

"(DAV:lock-submission-allowed): If the server restricts usage of the 
lock token inside an "If" request header to specific principals, the 
authenticated principal for this request MUST be one of them."


b) Change UNLOCK precondition DAV:lock-owner-matches to:

"(DAV:lock-removal-allowed): As dicussed above, the principal 
authenticated for the UNLOCK request MUST be allowed to remove the 
identified lock (note that servers that support the "WebDAV Access 
Control Protocol" should use the DAV:need-privileges precondition 
defined in section 7.1.1 of [RFC3744])."


c) Update "Write Locks and the If Request Header" as follows:

OLD:
    "In order to prevent these collisions a lock token MUST be submitted 
by an authorized principal in the If header for all locked resources 
that a method may interact with or the method MUST fail. For example, if 
a resource is to be moved and both the source and destination are locked 
then two lock tokens must be submitted, one for the source and the other 
for the destination."

NEW:
    "In order to prevent these collisions a lock token MUST be submitted 
in the If header for all locked resources that a method may interact 
with or the method MUST fail. For example, if a resource is to be moved 
and both the source and destination are locked then two lock tokens must 
be submitted, one for the source and the other for the destination.

Servers SHOULD restrict usage of the lock token to exactly the 
authenticated principal who created the lock. Servers MAY also allow 
other privileged authenticated principals or even unauthenticated 
principals to use the lock token."


Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Thu Jun 17 14:09:16 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29909
	for <webdav-archive@lists.ietf.org>; Thu, 17 Jun 2004 14:09:16 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 49DA0A21F1; Thu, 17 Jun 2004 14:09:16 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3E784A21F1
	for <w3c-dist-auth@listhub.w3.org>; Thu, 17 Jun 2004 14:09:14 -0400 (EDT)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1Bb1K6-0004RM-3i
	for w3c-dist-auth@w3.org; Thu, 17 Jun 2004 14:09:14 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5HI8f57005557
	for <w3c-dist-auth@w3.org>; Thu, 17 Jun 2004 11:08:41 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5HI8dBl029997
	for <w3c-dist-auth@w3.org>; Thu, 17 Jun 2004 11:08:40 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110402bcf78e83e53e@[129.46.227.161]>
Date: Thu, 17 Jun 2004 11:08:38 -0700
To: w3c-dist-auth@w3.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Fwd: Last Call: 'HTTP adaptation with OPES' to Proposed Standard
X-Archived-At: http://www.w3.org/mid/p06110402bcf78e83e53e@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8595
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040617180916.49DA0A21F1@frink.w3.org>
Resent-Date: Thu, 17 Jun 2004 14:09:16 -0400 (EDT)


This group may be interested in reading and commenting on the
following draft.
			regards,
				Ted Hardie


>
>The IESG has received a request from the Open Pluggable Edge Services WG to
>consider the following document:
>
>- 'HTTP adaptation with OPES '
>    <draft-ietf-opes-http-02.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-01.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-opes-http-02.txt
>
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce



From w3c-dist-auth-request@w3.org  Thu Jun 17 19:37:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26364
	for <webdav-archive@lists.ietf.org>; Thu, 17 Jun 2004 19:37:26 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B5CDBA0C99; Thu, 17 Jun 2004 19:37:26 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5FCF9A0C99
	for <w3c-dist-auth@listhub.w3.org>; Thu, 17 Jun 2004 19:37:23 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1Bb6Rf-0003W5-2N
	for w3c-dist-auth@w3c.org; Thu, 17 Jun 2004 19:37:23 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5HNaJJL008044
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Thu, 17 Jun 2004 16:36:20 -0700
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <42EAD1DE-C0B7-11D8-A549-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 17 Jun 2004 16:37:14 -0700
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: DRAFT schedule: Meeting Thurs, Aug 5 -- afternoon
X-Archived-At: http://www.w3.org/mid/42EAD1DE-C0B7-11D8-A549-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8596
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040617233726.B5CDBA0C99@frink.w3.org>
Resent-Date: Thu, 17 Jun 2004 19:37:26 -0400 (EDT)
Content-Transfer-Encoding: 7bit



The WebDAV WG is meeting at the San Diego IETF -- so far, the meeting 
is scheduled on the DRAFT schedule as thursday afternoon.  If we keep 
this slot or any other Thursday slot, let's also do a group dinner 
after the meeting (finishing dinner in time to attend most of the 
plenary, so roughly from 17:30 to 19:30.)

Lisa



From w3c-dist-auth-request@w3.org  Fri Jun 18 07:51:40 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14981
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 07:51:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B8B63A19D4; Fri, 18 Jun 2004 07:51:39 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A207BA19D4
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 07:51:37 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BbHuD-0007bN-H0
	for w3c-dist-auth@w3.org; Fri, 18 Jun 2004 07:51:37 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5IBp67R472214
	for <w3c-dist-auth@w3.org>; Fri, 18 Jun 2004 07:51:06 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5IBqD5m144008
	for <w3c-dist-auth@w3.org>; Fri, 18 Jun 2004 07:52:14 -0400
In-Reply-To: <40D1DA91.2050907@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF17713204.421C88C8-ON85256EB7.0040E0E1-85256EB7.00411A4D@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 18 Jun 2004 07:50:35 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF300 | June 4, 2004) at
 06/18/2004 07:50:36,
	Serialize complete at 06/18/2004 07:50:36
Content-Type: multipart/alternative; boundary="=_alternative 00411A4C85256EB7_="
Subject: Re: resolving 057_LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/OF17713204.421C88C8-ON85256EB7.0040E0E1-85256EB7.00411A4D@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8597
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618115139.B8B63A19D4@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 07:51:39 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 00411A4C85256EB7_=
Content-Type: text/plain; charset="US-ASCII"

This is all fine with me, except I'd like to delete the "MAY"
clause from the last sentence in the update to (c).
Weakening this to a SHOULD is as far as we should go.
Explicitly adding in the MAY sentence looks too much like
encouragement to do the wrong thing.

Cheers,
Geoff

Julian wrote on 06/17/2004 01:53:21 PM:

> 
> Hi,
> 
> I have resolved 057_LOCK_SEMANTICS in 
> 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 

> with the following changes (see previous mailing list discussion in 
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57
> >):
> 
> 
> a) Define a generic precondition:
> 
> "(DAV:lock-submission-allowed): If the server restricts usage of the 
> lock token inside an "If" request header to specific principals, the 
> authenticated principal for this request MUST be one of them."
> 
> 
> b) Change UNLOCK precondition DAV:lock-owner-matches to:
> 
> "(DAV:lock-removal-allowed): As dicussed above, the principal 
> authenticated for the UNLOCK request MUST be allowed to remove the 
> identified lock (note that servers that support the "WebDAV Access 
> Control Protocol" should use the DAV:need-privileges precondition 
> defined in section 7.1.1 of [RFC3744])."
> 
> 
> c) Update "Write Locks and the If Request Header" as follows:
> 
> OLD:
>     "In order to prevent these collisions a lock token MUST be submitted 

> by an authorized principal in the If header for all locked resources 
> that a method may interact with or the method MUST fail. For example, if 

> a resource is to be moved and both the source and destination are locked 

> then two lock tokens must be submitted, one for the source and the other 

> for the destination."
> 
> NEW:
>     "In order to prevent these collisions a lock token MUST be submitted 

> in the If header for all locked resources that a method may interact 
> with or the method MUST fail. For example, if a resource is to be moved 
> and both the source and destination are locked then two lock tokens must 

> be submitted, one for the source and the other for the destination.
> 
> Servers SHOULD restrict usage of the lock token to exactly the 
> authenticated principal who created the lock. Servers MAY also allow 
> other privileged authenticated principals or even unauthenticated 
> principals to use the lock token."
> 
> 
> Best regards, Julian
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

--=_alternative 00411A4C85256EB7_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>This is all fine with me, except I'd like to delete
the &quot;MAY&quot;</tt></font>
<br><font size=2><tt>clause from the last sentence in the update to (c).</tt></font>
<br><font size=2><tt>Weakening this to a SHOULD is as far as we should
go.</tt></font>
<br><font size=2><tt>Explicitly adding in the MAY sentence looks too much
like</tt></font>
<br><font size=2><tt>encouragement to do the wrong thing.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/17/2004 01:53:21 PM:<br>
<br>
&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; I have resolved 057_LOCK_SEMANTICS in <br>
&gt; &lt;http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html&gt;
<br>
&gt; with the following changes (see previous mailing list discussion in
<br>
&gt; &lt;http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57<br>
&gt; &gt;):<br>
&gt; <br>
&gt; <br>
&gt; a) Define a generic precondition:<br>
&gt; <br>
&gt; &quot;(DAV:lock-submission-allowed): If the server restricts usage
of the <br>
&gt; lock token inside an &quot;If&quot; request header to specific principals,
the <br>
&gt; authenticated principal for this request MUST be one of them.&quot;<br>
&gt; <br>
&gt; <br>
&gt; b) Change UNLOCK precondition DAV:lock-owner-matches to:<br>
&gt; <br>
&gt; &quot;(DAV:lock-removal-allowed): As dicussed above, the principal
<br>
&gt; authenticated for the UNLOCK request MUST be allowed to remove the
<br>
&gt; identified lock (note that servers that support the &quot;WebDAV Access
<br>
&gt; Control Protocol&quot; should use the DAV:need-privileges precondition
<br>
&gt; defined in section 7.1.1 of [RFC3744]).&quot;<br>
&gt; <br>
&gt; <br>
&gt; c) Update &quot;Write Locks and the If Request Header&quot; as follows:<br>
&gt; <br>
&gt; OLD:<br>
&gt; &nbsp; &nbsp; &quot;In order to prevent these collisions a lock token
MUST be submitted <br>
&gt; by an authorized principal in the If header for all locked resources
<br>
&gt; that a method may interact with or the method MUST fail. For example,
if <br>
&gt; a resource is to be moved and both the source and destination are
locked <br>
&gt; then two lock tokens must be submitted, one for the source and the
other <br>
&gt; for the destination.&quot;<br>
&gt; <br>
&gt; NEW:<br>
&gt; &nbsp; &nbsp; &quot;In order to prevent these collisions a lock token
MUST be submitted <br>
&gt; in the If header for all locked resources that a method may interact
<br>
&gt; with or the method MUST fail. For example, if a resource is to be
moved <br>
&gt; and both the source and destination are locked then two lock tokens
must <br>
&gt; be submitted, one for the source and the other for the destination.<br>
&gt; <br>
&gt; Servers SHOULD restrict usage of the lock token to exactly the <br>
&gt; authenticated principal who created the lock. Servers MAY also allow
<br>
&gt; other privileged authenticated principals or even unauthenticated
<br>
&gt; principals to use the lock token.&quot;<br>
&gt; <br>
&gt; <br>
&gt; Best regards, Julian<br>
&gt; <br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; <br>
</tt></font>
--=_alternative 00411A4C85256EB7_=--



From w3c-dist-auth-request@w3.org  Fri Jun 18 08:17:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16253
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 08:17:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5C66EA05CD; Fri, 18 Jun 2004 08:17:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 85471A05CD
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 08:17:44 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BbIJU-0002Wj-Bx
	for w3c-dist-auth@w3.org; Fri, 18 Jun 2004 08:17:44 -0400
Received: (qmail 11190 invoked by uid 65534); 18 Jun 2004 12:17:13 -0000
Received: from p508245B8.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.69.184)
  by mail.gmx.net (mp006) with SMTP; 18 Jun 2004 14:17:13 +0200
X-Authenticated: #1915285
Message-ID: <40D2DD45.9070100@gmx.de>
Date: Fri, 18 Jun 2004 14:17:09 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF17713204.421C88C8-ON85256EB7.0040E0E1-85256EB7.00411A4D@us.ibm.com>
In-Reply-To: <OF17713204.421C88C8-ON85256EB7.0040E0E1-85256EB7.00411A4D@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: resolving 057_LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/40D2DD45.9070100@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8598
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618121747.5C66EA05CD@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 08:17:47 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:
> 
> This is all fine with me, except I'd like to delete the "MAY"
> clause from the last sentence in the update to (c).
> Weakening this to a SHOULD is as far as we should go.
> Explicitly adding in the MAY sentence looks too much like
> encouragement to do the wrong thing.

Agreed. Saying

"Servers SHOULD do x, but MAY do not(x)"

isn't very useful.


Julian

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



From w3c-dist-auth-request@w3.org  Fri Jun 18 09:15:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18961
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 09:15:33 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9674DA0ABC; Fri, 18 Jun 2004 09:15:33 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4F185A0ACE
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 09:15:28 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BbJDM-0002Lp-6Q
	for w3c-dist-auth@w3.org; Fri, 18 Jun 2004 09:15:28 -0400
Received: (qmail 11442 invoked by uid 65534); 18 Jun 2004 13:14:57 -0000
Received: from p508911CB.dip0.t-ipconnect.de (EHLO pcjpl) (80.137.17.203)
  by mail.gmx.net (mp026) with SMTP; 18 Jun 2004 15:14:57 +0200
X-Authenticated: #8750622
From: <webdav-standards@webdav.info>
To: <w3c-dist-auth@w3.org>
Date: Fri, 18 Jun 2004 15:14:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRVKqd66+hL+gPvT6+zyH23uOQ/HAACI3MA
In-Reply-To: <OF17713204.421C88C8-ON85256EB7.0040E0E1-85256EB7.00411A4D@us.ibm.com>
Message-Id: <20040618131528.4F185A0ACE@frink.w3.org>
Subject: new auto-version value
X-Archived-At: http://www.w3.org/mid/20040618131528.4F185A0ACE@frink.w3.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8599
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618131533.9674DA0ABC@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 09:15:33 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hello,

the auto-version property can currently hold 5 different values: Empty, checkout-checkin, checkout-unlock-checkin, checkout and
locked-checkout.

I would like to propose a new value, named something like: checkout-ignore-unlock. It will carry the same semantics as the
checkout value, but an unlock command will not issue an implicit check-in command, instead the resource stays in the checked-out
state and an explicit check-in command is required.

Use-case:

A document is controlled by a workflow process. Creating a document takes this document in the initial-author state, in which only
explicit check-in command should create new versions. If this newly created resource is implicitly put under version-control and
the auto-version property is set to the new suggested value, we can receive this behaviour. Now the document can be modified
either with an http client (via put) or with a WebDAV client (Lock - Put* - Unlock) and still the resource is never implicitly
checked-in. 
The same effect could be reached by an explicit check-out, but this will require an additional user interaction to issue the
check-out command, which we do not want to expose. Our user is then only required to use our state manipulation GUI tool, in case
of a real state change. The creation and manipulation of a new resource will feel like modification on the hard disc: create it,
modify it (with any tool) and then publish or change the state with an additional tool.

Does this make a more general sense, or would you think this is a too specific requirement to go into any new version of the
delta-v standard?


Best regards

Juergen Pill
Premium WebDAV Consultancy and Services 
www.webdav.info






From w3c-dist-auth-request@w3.org  Fri Jun 18 10:56:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28786
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 10:56:46 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9CC05A1616; Fri, 18 Jun 2004 10:56:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6FDFCA1616
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 10:56:45 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BbKnN-0000ap-5R
	for w3c-dist-auth@w3.org; Fri, 18 Jun 2004 10:56:45 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5IEtcJL000906
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 18 Jun 2004 07:55:41 -0700
In-Reply-To: <20040618131528.4F185A0ACE@frink.w3.org>
References: <20040618131528.4F185A0ACE@frink.w3.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AF74D13A-C137-11D8-A549-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: <w3c-dist-auth@w3.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 18 Jun 2004 07:56:31 -0700
To: <webdav-standards@webdav.info>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: new auto-version value
X-Archived-At: http://www.w3.org/mid/AF74D13A-C137-11D8-A549-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8600
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618145647.9CC05A1616@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 10:56:47 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm a little confused.  If you don't want the user to have to go to the 
external state-manipulation tool, then why not use 
checkout-unlock-checkin?  I would think you would want the checkin to 
happen when editing is done, to publish the state.  Also note that the 
state is "published" regardless, in that any changes made by any client 
are visible on the resource checked out, whether or not it's checked in 
again -- it seems pretty clear in this case you're talking about 
in-place checkout.

The auto-version property is a bit of a hack to deal with 
non-DeltaV-aware clients that can never know when to check out and 
check in.  Adding more values to this property runs a risk of confusing 
DeltaV clients that are aware of this property but only know the values 
in the initial standard.  OTOH I'm not aware of any clients at all that 
use the value of this property as yet so it would be good to hear if 
there are any.

Lisa

On Jun 18, 2004, at 6:14 AM, <webdav-standards@webdav.info> wrote:

>
> Hello,
>
> the auto-version property can currently hold 5 different values: 
> Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> locked-checkout.
>
> I would like to propose a new value, named something like: 
> checkout-ignore-unlock. It will carry the same semantics as the
> checkout value, but an unlock command will not issue an implicit 
> check-in command, instead the resource stays in the checked-out
> state and an explicit check-in command is required.
>
> Use-case:
>
> A document is controlled by a workflow process. Creating a document 
> takes this document in the initial-author state, in which only
> explicit check-in command should create new versions. If this newly 
> created resource is implicitly put under version-control and
> the auto-version property is set to the new suggested value, we can 
> receive this behaviour. Now the document can be modified
> either with an http client (via put) or with a WebDAV client (Lock - 
> Put* - Unlock) and still the resource is never implicitly
> checked-in.
> The same effect could be reached by an explicit check-out, but this 
> will require an additional user interaction to issue the
> check-out command, which we do not want to expose. Our user is then 
> only required to use our state manipulation GUI tool, in case
> of a real state change. The creation and manipulation of a new 
> resource will feel like modification on the hard disc: create it,
> modify it (with any tool) and then publish or change the state with an 
> additional tool.
>
> Does this make a more general sense, or would you think this is a too 
> specific requirement to go into any new version of the
> delta-v standard?
>
>
> Best regards
>
> Juergen Pill
> Premium WebDAV Consultancy and Services
> www.webdav.info
>
>
>
>



From w3c-dist-auth-request@w3.org  Fri Jun 18 15:30:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14070
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 15:30:48 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A9CCDA12EB; Fri, 18 Jun 2004 15:30:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EC74EA18B5
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 15:29:44 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BbOtt-00083j-W6
	for w3c-dist-auth@w3c.org; Fri, 18 Jun 2004 15:19:46 -0400
Received: (qmail 9408 invoked by uid 65534); 18 Jun 2004 19:19:14 -0000
Received: from pD9535EFE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.254)
  by mail.gmx.net (mp025) with SMTP; 18 Jun 2004 21:19:14 +0200
X-Authenticated: #1915285
Message-ID: <40D3402F.6000604@gmx.de>
Date: Fri, 18 Jun 2004 21:19:11 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: multipart/mixed;
 boundary="------------050208050704080902070305"
Subject: Issue #66: MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL
X-Archived-At: http://www.w3.org/mid/40D3402F.6000604@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8601
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618193043.A9CCDA12EB@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 15:30:43 -0400 (EDT)


This is a multi-part message in MIME format.
--------------050208050704080902070305
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

quoting from <http://www.webdav.org/wg/rfcdev/issues.htm>:

"Right now the server uses the IF: header to verify that a client knows 
what locks it has that are affected by an operation before it allows the 
operation.  Must the client provide the root URL of a lock, any URL for 
a pertainent loc, or some specific URL  in the IF: header.

Post: 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html: 
It is felt by the group that it’s important that the client not just own 
and hold the lock token, but that it also know where the lock is rooted 
before it does tasks related to that lock.  This is just a point of 
info.  The issue itself still needs to be brought up and answered.still"

(see also 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL>)

I just did some test with Apache/moddav2, Xythos and SAP Enterprise 
Portal 5 (IIS doesn't support deep locks; test case script attached). It 
seems that none of these servers is indeed enforcing that in tagged if 
lists, the *root* of the URL needs to be submitted. That is, it doesn't 
matter which of the resources locked by a deep lock is listed in the 
tagged-list, as long as it is indeed affected by the lock.

This leaves us with the following options:

1) Just document things as they seem to be implemented (not requiring 
that the client uses the URI of the lock root),

2) Keep our earlier statement -- basically clients MUST submit the lock 
token with the URL of the lock root; and state that otherwise the 
behaviour is server-defined (thus interoperable).

As 2) is what we discussed before, I think I prefer that point of view. 
However, if people think we should explicitly allow 1), I'll happily 
document that as well.

Feedback appreciated,

Julian

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

--------------050208050704080902070305
Content-Type: application/x-gzip;
 name="066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL.js.gz"
Content-Disposition: inline;
 filename="066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL.js.gz"
Content-Transfer-Encoding: base64

H4sICLH20UAAAzA2Nl9NVVNUX0FOX0lGX0hFQURFUl9DSEVDS19USEVfUk9PVF9PRl9VUkwu
anMAzVbbbts4EH2uAf/DLB8aaetbspcH1zYQNAVaNGmytbcbYNEHWRpLamRK4SVx0PbfO6Qk
R5K9jYu4i76JM3OGh2eGQ914AgRewxg43sKxr+IbvDyff0RfgcPOppdnp0e9KYobFPT5aja7
YO7zdqvduiGgFjEB/5n6Is5U71iEeolcSWdgQmyARGFS6yQpLNltcG9ot+IFOBv4XoI8VBFM
4NCFT+0WlHk2dzo0O33ZIdORzfQk334zz9E6T7u10JxkSDkEepm9Q5mlXKIjCiol9qUfpY7o
SeUpLQ16wxWiOk6SMsEr9AIU0nG3xooiaoYrtabS74Mv0FMIfpokaEm1WzUkO3vz4vwUGDwz
xTBIKmYvzZAXLtYxjg4svERixwrZMUUoQyXywDELo59jLfZEMIKjwQA+f4aKbTKG3wYDF54+
rVp/GcPvgz+2ycM0x1VGxDGAIljTMcEyGxrSlTTP6BSlqSnHfd6/dKzW1aoXCK/zziTZMq1I
M66otk3BLv6elXKZLfseq6tG/lyzwvuAdGyRpnNPsFLCHRXcXSviM4QfJVWdwen5izfbW8l4
Hu4k9Q6vNUqVt7rDTjBTEcFYzBcxj9Ud++/YWbzEVCsTPUUqXdD9c8DqSo9OhknqX1GyFFbL
hMvhyfjg5Pj98GBSuKRPdM0CV36iJY2y/mTUb/jMQt3l37ciVpWY3Ny/32diKWzXzkwzC0qv
kFdnmhJ3eX2rXnOM0Jy6Og0cZkK6NoYVhfI95UfgrKhH1nOtkijfx3RVzcjY1p6SdnBDEAfA
U0UklBbcIsFCO0BkYx5C2UUwT4O8TM0RtbXVqlZ6HkxdLwTpLNSdQ3UsZtapx0PthWiKe3nh
UU/k6KY+9UwGPCVuCb5NA3RYv//rv4Twki73lui444NI4OLgA3N7igjl6iH15qb46++e1HOp
BGV1DjsVc/FMdKH+nlSuHGm8eZut8XCr8uvc+eVdL90mzzqMJEi18NGWy4Aw6BTjYB9TwA5H
6Zm7CH6E/tXQzBe4jVVElw9eLyCyjfng0LQQIglxCXnkGPW+cdOIs84C+w5GcRKUe3eVF3aT
WKp7Ejvz3oJ9xAGaw+z1wrS6M6pV3uSZuOyRxybeIQYN6uB81LRWURlatpH7sCDfmXDvKo3q
j7FVCXaSbv6zareMpcyQ/tiC/1m9+XfJ5+9bv3xe7bP5mhl/qH57aLuvTFMBoU4NAAA=
--------------050208050704080902070305--



From w3c-dist-auth-request@w3.org  Fri Jun 18 15:44:32 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14641
	for <webdav-archive@lists.ietf.org>; Fri, 18 Jun 2004 15:44:32 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 90AF1A0BFF; Fri, 18 Jun 2004 15:44:31 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A4826A0918
	for <w3c-dist-auth@listhub.w3.org>; Fri, 18 Jun 2004 15:44:28 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BbPHo-0003fX-Ci
	for w3c-dist-auth@w3c.org; Fri, 18 Jun 2004 15:44:28 -0400
Received: (qmail 6040 invoked by uid 65534); 18 Jun 2004 19:43:56 -0000
Received: from pD9535EFE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.254)
  by mail.gmx.net (mp016) with SMTP; 18 Jun 2004 21:43:56 +0200
X-Authenticated: #1915285
Message-ID: <40D345F8.9050106@gmx.de>
Date: Fri, 18 Jun 2004 21:43:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: multipart/mixed;
 boundary="------------000605090306030608050506"
Subject: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/40D345F8.9050106@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8602
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040618194431.90AF1A0BFF@frink.w3.org>
Resent-Date: Fri, 18 Jun 2004 15:44:31 -0400 (EDT)


This is a multi-part message in MIME format.
--------------000605090306030608050506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

quoting from <http://www.webdav.org/wg/rfcdev/issues.htm>:

"In some cases, such as when the parent collection of a resource is 
locked, a 423 (Locked) status code is returned even though the resource 
identified by the Request-URI is not locked. This can be confusing, 
since it is not possible for a client to easily discover which resource 
is causing the locked status code to be returned. An improved status 
report would indicate the resource causing the lock message."

(see also 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.044_REPORT_OTHER_RESOURCE_LOCKED>).

I just did tests - again - with Apache/moddav2, Xythos and SAP EP5 (test 
case attached), confirming that all of them indeed return 423 Locked.

So I'd recommend that we define a new precondition (applying to *all* 
methods) specifically for use in this case, that also will contain the 
URI of the resource causing the failure inside a <href> element, similar 
to <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1> 
(where the same situation occurs for missing privileges).

For instance:

(DAV:need-submitted-lock-token): If a request would modify the content 
for a locked resource, a dead property of a locked resource, a live 
property that is defined to be lockable for a locked resource, or an 
internal member URI of a locked collection, the request MUST fail unless 
the lock-token for that lock is submitted in the request. An internal 
member URI of a collection is considered to be modified if it is added, 
removed, or identifies a different resource.

<!ELEMENT need-submitted-lock-token (href)* >

(the text is taken from one of the GULP rules, see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C.6>).

Feedback appreciated,

Julian

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


--------------000605090306030608050506
Content-Type: application/x-gzip;
 name="044_REPORT_OTHER_RESOURCE_LOCKED.js.gz"
Content-Disposition: inline;
 filename="044_REPORT_OTHER_RESOURCE_LOCKED.js.gz"
Content-Transfer-Encoding: base64

H4sICFtE00AAAzA0NF9SRVBPUlRfT1RIRVJfUkVTT1VSQ0VfTE9DS0VELmpzALVV227aQBB9
LhL/MN2HYhruvTzQgIQCUqqQhgbaRqr6YOwB3Ji1s97loqb/3tm1TWwgSiq1b7szc2bPnpmd
XdkCBN5BBziuoedIb4U3V9Of6Eiw2OX45nLYqo1RrFDQ8nwyGbHyh2KhWFgRUAmPgN/GjvBC
WeuJuVoil5HV0CEmIEKhUyvfTyzh2n0wFAveDKwDfM1HPpcL6EKzDL+KBUjzHJ7U1Cf9fkam
lsn0Ij7+ME9rl6dYmClOMgQcXLUMrzEKAx6hJRIqKXbgLAJL1CJpSxVp9IFrjrLn+2mCc7Rd
FJFVPhorkqgJbuSOSr0OjkBbIjiB76MhVSzkkOzy4uxqCAxOdDE0kopZC0LkiYtVtKMCM9uP
sGKErOgipKERctfSG62fZSzmRnAKrUYD7u8hY+t24E2jUYZXr7LWlx1423h3TB6mOG5CIo4u
JMGKrgmGWVuTzqQ5oVukpn05HvJ+Vp7cVStfILyLO5NkC5Ukzbik2u4LNvoySeXSR9ZtlleN
/LFmifcJ6dgsCKa2YKmEz1Tw+VoRnzb8L6nyDIZXZxfHW0l7nu4keY13CiMZt7rF+hjKBcGY
x2ce9+SWPR478ZYYKKmjx0ilc6vvGyyv9Gm/7QfOLSULYLP0edTud0r93td2qZu4Iofo6g1u
HF9FNMrq3dP6nk9v5DZer4UnMzGxuf5wTtdQOK6dnmYGFNwiz840KbZxfbNefY25vnV2GlhM
h1RNDEsK5djSWYC1oR7ZzbVMovgc3VU5I2NHeyoygxtczwUeSCIhleAGCQZaASLr8TmkXQTT
wI3LtD+ijrZa1krfg67rSJDOQm4tqmMys4Y2nyt7jrq4NyObeiJG7+uTz6TBY+Lm46fARYvV
66+/E8L2q9xeolXulBYCZ6UfrFyTRChWD6k3D8XfrWuRmkZSUFarWcmYk2+iCvn/JPPkSOPD
12yMzaPK73LHj3e3Le/zzMNIgkAJB025NAjdSjIO/sUUMMPRlhKXoYT+YDiYDGDtyQW9PPg4
g4Xpyv2xkMTlhuYO5aWovTEag/5mkj7+0v4A/NvgYKQIAAA=
--------------000605090306030608050506--



From w3c-dist-auth-request@w3.org  Sat Jun 19 09:39:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20220
	for <webdav-archive@lists.ietf.org>; Sat, 19 Jun 2004 09:39:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D6636A1D57; Sat, 19 Jun 2004 09:39:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8CD7CA1D54
	for <w3c-dist-auth@listhub.w3.org>; Sat, 19 Jun 2004 09:39:27 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1Bbg47-0002sm-7g
	for w3c-dist-auth@w3c.org; Sat, 19 Jun 2004 09:39:27 -0400
Received: (qmail 15396 invoked by uid 65534); 19 Jun 2004 13:38:54 -0000
Received: from p50824BED.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.75.237)
  by mail.gmx.net (mp008) with SMTP; 19 Jun 2004 15:38:54 +0200
X-Authenticated: #1915285
Message-ID: <40D441ED.6000806@gmx.de>
Date: Sat, 19 Jun 2004 15:38:53 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
References: <40D345F8.9050106@gmx.de>
In-Reply-To: <40D345F8.9050106@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/40D441ED.6000806@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8603
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040619133930.D6636A1D57@frink.w3.org>
Resent-Date: Sat, 19 Jun 2004 09:39:30 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Full text:

7.2.2  DAV:need-lock-token precondition

    If a request would modify the content for a locked resource, a dead
    property of a locked resource, a live property that is defined to be
    lockable for a locked resource, or an internal member URI of a locked
    collection, the request MUST fail unless the lock-token for that lock
    is submitted in the request.  An internal member URI of a collection
    is considered to be modified if it is added, removed, or identifies a
    different resource.  [[anchor28: Copied from GULP.  --reschke]]

       <!ELEMENT need-lock-token (href)* >

    Servers SHOULD insert DAV:href elements for the URLs of each root of
    a lock for which a lock token was needed, unless that URL identies
    the same resource to that the request was sent.

7.2.2.1  Example

    In the example below, a client unaware of a "Depth: infinity" lock on
    the parent collection "/workspace/webdav/" attempts to modify the
    collection member "/workspace/webdav/proposal.doc".

    >>Request

       PUT /workspace/webdav/proposal.doc HTTP/1.1
       Host: example.com

    >>Response

       HTTP/1.1 423 Locked
       Content-Type: text/xml; charset="utf-8"
       Content-Length: xxxx

       <?xml version="1.0" encoding="utf-8" ?>
       <D:error xmlns:D="DAV:">
         <D:need-lock-token>
           <D:href>/workspace/webdav/</D:href>
         </D:need-lock-token>
       </D:error>


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



From w3c-dist-auth-request@w3.org  Sat Jun 19 14:56:38 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03361
	for <webdav-archive@lists.ietf.org>; Sat, 19 Jun 2004 14:56:37 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA43AA1BCE; Sat, 19 Jun 2004 14:56:36 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 02617A1C1E
	for <w3c-dist-auth@listhub.w3.org>; Sat, 19 Jun 2004 14:56:34 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1Bbl0z-0003IO-PK
	for w3c-dist-auth@w3c.org; Sat, 19 Jun 2004 14:56:33 -0400
Received: (qmail 23803 invoked by uid 65534); 19 Jun 2004 18:56:01 -0000
Received: from pD9535932.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.50)
  by mail.gmx.net (mp025) with SMTP; 19 Jun 2004 20:56:01 +0200
X-Authenticated: #1915285
Message-ID: <40D48C3C.1040604@gmx.de>
Date: Sat, 19 Jun 2004 20:55:56 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: multipart/mixed;
 boundary="------------050201070508040800080700"
Subject: Issue #56: DEPTH_LOCK_AND_IF
X-Archived-At: http://www.w3.org/mid/40D48C3C.1040604@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8604
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040619185636.EA43AA1BCE@frink.w3.org>
Resent-Date: Sat, 19 Jun 2004 14:56:36 -0400 (EDT)


This is a multi-part message in MIME format.
--------------050201070508040800080700
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

quoting from <http://www.webdav.org/wg/rfcdev/issues.htm>:

"The specification is currently silent on how to use the If header for 
submitting a locktoken when performing a DELETE in a Depth infinity 
locked collection.  Should the If header have both the collection URL 
and the Request-URI, or just the Request-URI? An example of this is needed."

(see also 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.056_DEPTH_LOCK_AND_IF>).

I just did tests - again - with Apache/moddav2, Xythos and SAP EP5 (test 
case attached), confirming that all accept the DELETE request no matter 
for which URI the lock token is submitted.

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 
currently defines:

"If a request would modify the content for a locked resource, a dead 
property of a locked resource, a live property that is defined to be 
lockable for a locked resource, or an internal member URI of a locked 
collection, the request MUST fail unless the lock-token for that lock is 
submitted in the request. An internal member URI of a collection is 
considered to be modified if it is added, removed, or identifies a 
different resource."

and GULP (still to be integrated says) goes on saying:

"A lock token is "submitted" in a request when it appears in an "If" 
request header." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#semantics.5>)

Summary: the server behaviour we see is consistent with GULP (you need 
to submit the lock token, and it counts as submitted if it appears 
anywhere in the "If" header).

The locking spec *still* needs to define the specifics of lock token 
evaluation in the "If" header, though (so I'll add the comments above to 
the issue and move it down to the "If header considerations" section).


Julian


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


--------------050201070508040800080700
Content-Type: application/x-gzip;
 name="056_DEPTH_LOCK_AND_IF.js.gz"
Content-Disposition: inline;
 filename="056_DEPTH_LOCK_AND_IF.js.gz"
Content-Transfer-Encoding: base64

H4sICH+J1EAAAzA1Nl9ERVBUSF9MT0NLX0FORF9JRi5qcwDdVU1v20YQPVeA/sN0DzHVSKLs
tD2okgAjMpAgcu1Eamug6GFFDik21JLeD1tG0//e2SUlkxQTu2gPRW/kzLy3s29mZ+64BIm3
MAWB93Ae6OQOb67Wv2OgwWOXy5vLxdlwifIOJX2+Wa2uWe+HbqfbuSOgkQkBf1kGMsn18FzG
ZotCK29kQ1yAQmmpTZqWlvw+fDR0O0kE3hF+mKKI9QZmcNqDP7od2PMcn3RqT/rzGUxnjumr
4vhjnrMDT7cTGUEyZAJCs80/oMozodCTZSp77EWwyTw5VJproyz6yBWjPk/TPcEb5CFK5fVa
Y2UZtcKdPqTi+xBI5BohyNIUXVLdTg3JLt+9vloAg5e2GBZJxRxmOYrSxfrW0YeIpwr7Tsi+
LcI+VKEIPftj9fOcxd0IJnA2GsGnT1CxzabwajTqwYsXVevXU/h29F2bPMwI3OWUOIZQBhu6
JrjMxjbpCs1LusXe1JTjkfe9SfShWvUC4W3RmSRbbjRpJjTVtinY9U+rvVz2SJ+zumrkLzQr
vU9Ix6IsW3PJ9hI+U8Hna0X5jOG/IdX6i1Kt/99S1TNYXL1+1/7qrOfpR6c/4K1BpYup4LE5
5npDMJaIKBGJfmCfj10lW8yMttFLpNKFg+9HrK70ZD5Os+AjkWWw26ZCjefTk/n5z+OTWelS
AaVrf3AXpEbR1PdnE7/hsz/6ofi+l4muxBRm//GcmUuhXTs7+B0o+4iiOv61fCjqW/Xaa8T2
1tXB6TEbMnAxrCxUwHWwAW9HPXJYARWi4hzbVTUjY609pdyOgzAJQWSaktBGCocEB+0DJZuI
GPZdBOssLMrUnOatrVa10ia1db2WpLPUDx7VsRzvCy5iw2O0xb255tQTBbqpT53JgpeUW4o/
ZiF6zPe/+ZUQPB0IvkWvNz3ZSIxOfmO9oaaECvWQevNY/MP3UJm10pJYvdN+xVxu1AHUV2/l
yZHGx6/ZGU9blT9wF4/38Ntr5lmHkQSZkQG6clkQhv1yHPwbU8ANR641bnMN84vFxeoCNI9j
DAdpojS8jWDjOhOiTILPmxOihNRWTY2ABtbR8ilAz94/zcnwNrJ9M6mdOQNvUpPVmme9+sD4
/NP9OyLkXLZskRYh1k0hCuRTYnx5wzwtxj+S4i91418AKQsAAA==
--------------050201070508040800080700--



From w3c-dist-auth-request@w3.org  Sat Jun 19 22:56:01 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24272
	for <webdav-archive@lists.ietf.org>; Sat, 19 Jun 2004 22:56:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B414CA2131; Sat, 19 Jun 2004 22:56:01 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 58A57A2131
	for <w3c-dist-auth@listhub.w3.org>; Sat, 19 Jun 2004 22:55:58 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BbsUw-0004u8-73
	for w3c-dist-auth@w3.org; Sat, 19 Jun 2004 22:55:58 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5K2tMrn383408
	for <w3c-dist-auth@w3.org>; Sat, 19 Jun 2004 22:55:22 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5K2uUol050766
	for <w3c-dist-auth@w3.org>; Sat, 19 Jun 2004 22:56:30 -0400
In-Reply-To: <AF74D13A-C137-11D8-A549-000A95B2BB72@osafoundation.org>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF91E07658.F231C0A5-ON85256EB9.000F78BD-85256EB9.00100DA7@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 19 Jun 2004 22:54:50 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/19/2004 22:54:51,
	Serialize complete at 06/19/2004 22:54:51
Content-Type: multipart/alternative; boundary="=_alternative 00100DA185256EB9_="
Subject: Re: new auto-version value
X-Archived-At: http://www.w3.org/mid/OF91E07658.F231C0A5-ON85256EB9.000F78BD-85256EB9.00100DA7@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8605
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040620025601.B414CA2131@frink.w3.org>
Resent-Date: Sat, 19 Jun 2004 22:56:01 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 00100DA185256EB9_=
Content-Type: text/plain; charset="US-ASCII"

This new auto-version value only makes sense if the "checkin"
operation is used to promote a change in the workflow.  This is
probably non-optimal, since it doesn't let a client save an
intermediate state of the resource in the version history
(i.e. before it is ready to publish).  In addition, a step
in the workflow often requires changing multiple resources,
so you can't really infer from one being checked-in that the
task is complete.  So I would be against encouraging this 
model in the standard (and therefore would not
be in favor of standardizing on this new value).

WRT Lisa's question, he doesn't want the user to have to go to
the external state-manipulation tool to start a modification,
but he does expect the user to have to go to the external
state-manipulation tool to say "I'm finished with this task".
I agree that this is reasonable, but I'm against standardizing
on "checkin" to mean "I'm finished with this task".

Cheers,
Geoff

Lisa wrote on 06/18/2004 10:56:31 AM:
> I'm a little confused.  If you don't want the user to have to go to the 
> external state-manipulation tool, then why not use 
> checkout-unlock-checkin?  I would think you would want the checkin to 
> happen when editing is done, to publish the state.  Also note that the 
> state is "published" regardless, in that any changes made by any client 
> are visible on the resource checked out, whether or not it's checked in 
> again -- it seems pretty clear in this case you're talking about 
> in-place checkout.
> 
> The auto-version property is a bit of a hack to deal with 
> non-DeltaV-aware clients that can never know when to check out and 
> check in.  Adding more values to this property runs a risk of confusing 
> DeltaV clients that are aware of this property but only know the values 
> in the initial standard.  OTOH I'm not aware of any clients at all that 
> use the value of this property as yet so it would be good to hear if 
> there are any.

> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
> > the auto-version property can currently hold 5 different values: 
> > Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> > locked-checkout.
> >
> > I would like to propose a new value, named something like: 
> > checkout-ignore-unlock. It will carry the same semantics as the
> > checkout value, but an unlock command will not issue an implicit 
> > check-in command, instead the resource stays in the checked-out
> > state and an explicit check-in command is required.
> >
> > Use-case:
> >
> > A document is controlled by a workflow process. Creating a document 
> > takes this document in the initial-author state, in which only
> > explicit check-in command should create new versions. If this newly 
> > created resource is implicitly put under version-control and
> > the auto-version property is set to the new suggested value, we can 
> > receive this behaviour. Now the document can be modified
> > either with an http client (via put) or with a WebDAV client (Lock - 
> > Put* - Unlock) and still the resource is never implicitly
> > checked-in.
> > The same effect could be reached by an explicit check-out, but this 
> > will require an additional user interaction to issue the
> > check-out command, which we do not want to expose. Our user is then 
> > only required to use our state manipulation GUI tool, in case
> > of a real state change. The creation and manipulation of a new 
> > resource will feel like modification on the hard disc: create it,
> > modify it (with any tool) and then publish or change the state with an 

> > additional tool.
> >
> > Does this make a more general sense, or would you think this is a too 
> > specific requirement to go into any new version of the
> > delta-v standard?

--=_alternative 00100DA185256EB9_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>This new auto-version value only makes sense if the
&quot;checkin&quot;</tt></font>
<br><font size=2><tt>operation is used to promote a change in the workflow.
&nbsp;This is</tt></font>
<br><font size=2><tt>probably non-optimal, since it doesn't let a client
save an</tt></font>
<br><font size=2><tt>intermediate state of the resource in the version
history</tt></font>
<br><font size=2><tt>(i.e. before it is ready to publish). &nbsp;In addition,
a step</tt></font>
<br><font size=2><tt>in the workflow often requires changing multiple resources,</tt></font>
<br><font size=2><tt>so you can't really infer from one being checked-in
that the</tt></font>
<br><font size=2><tt>task is complete. &nbsp;So I would be against encouraging
this </tt></font>
<br><font size=2><tt>model in the standard (and therefore would not</tt></font>
<br><font size=2><tt>be in favor of standardizing on this new value).</tt></font>
<br>
<br><font size=2><tt>WRT Lisa's question, he doesn't want the user to have
to go to</tt></font>
<br><font size=2><tt>the external state-manipulation tool to start a modification,</tt></font>
<br><font size=2><tt>but he does expect the user to have to go to the external</tt></font>
<br><font size=2><tt>state-manipulation tool to say &quot;I'm finished
with this task&quot;.</tt></font>
<br><font size=2><tt>I agree that this is reasonable, but I'm against standardizing</tt></font>
<br><font size=2><tt>on &quot;checkin&quot; to mean &quot;I'm finished
with this task&quot;.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Lisa wrote on 06/18/2004 10:56:31 AM:<br>
&gt; I'm a little confused. &nbsp;If you don't want the user to have to
go to the <br>
&gt; external state-manipulation tool, then why not use <br>
&gt; checkout-unlock-checkin? &nbsp;I would think you would want the checkin
to <br>
&gt; happen when editing is done, to publish the state. &nbsp;Also note
that the <br>
&gt; state is &quot;published&quot; regardless, in that any changes made
by any client <br>
&gt; are visible on the resource checked out, whether or not it's checked
in <br>
&gt; again -- it seems pretty clear in this case you're talking about <br>
&gt; in-place checkout.<br>
&gt; <br>
&gt; The auto-version property is a bit of a hack to deal with <br>
&gt; non-DeltaV-aware clients that can never know when to check out and
<br>
&gt; check in. &nbsp;Adding more values to this property runs a risk of
confusing <br>
&gt; DeltaV clients that are aware of this property but only know the values
<br>
&gt; in the initial standard. &nbsp;OTOH I'm not aware of any clients at
all that <br>
&gt; use the value of this property as yet so it would be good to hear
if <br>
&gt; there are any.<br>
<br>
&gt; On Jun 18, 2004, at 6:14 AM, Juergen wrote:<br>
&gt; &gt; the auto-version property can currently hold 5 different values:
<br>
&gt; &gt; Empty, checkout-checkin, checkout-unlock-checkin, checkout and<br>
&gt; &gt; locked-checkout.<br>
&gt; &gt;<br>
&gt; &gt; I would like to propose a new value, named something like: <br>
&gt; &gt; checkout-ignore-unlock. It will carry the same semantics as the<br>
&gt; &gt; checkout value, but an unlock command will not issue an implicit
<br>
&gt; &gt; check-in command, instead the resource stays in the checked-out<br>
&gt; &gt; state and an explicit check-in command is required.<br>
&gt; &gt;<br>
&gt; &gt; Use-case:<br>
&gt; &gt;<br>
&gt; &gt; A document is controlled by a workflow process. Creating a document
<br>
&gt; &gt; takes this document in the initial-author state, in which only<br>
&gt; &gt; explicit check-in command should create new versions. If this
newly <br>
&gt; &gt; created resource is implicitly put under version-control and<br>
&gt; &gt; the auto-version property is set to the new suggested value,
we can <br>
&gt; &gt; receive this behaviour. Now the document can be modified<br>
&gt; &gt; either with an http client (via put) or with a WebDAV client
(Lock - <br>
&gt; &gt; Put* - Unlock) and still the resource is never implicitly<br>
&gt; &gt; checked-in.<br>
&gt; &gt; The same effect could be reached by an explicit check-out, but
this <br>
&gt; &gt; will require an additional user interaction to issue the<br>
&gt; &gt; check-out command, which we do not want to expose. Our user is
then <br>
&gt; &gt; only required to use our state manipulation GUI tool, in case<br>
&gt; &gt; of a real state change. The creation and manipulation of a new
<br>
&gt; &gt; resource will feel like modification on the hard disc: create
it,<br>
&gt; &gt; modify it (with any tool) and then publish or change the state
with an <br>
&gt; &gt; additional tool.<br>
&gt; &gt;<br>
&gt; &gt; Does this make a more general sense, or would you think this
is a too <br>
&gt; &gt; specific requirement to go into any new version of the<br>
&gt; &gt; delta-v standard?<br>
</tt></font>
--=_alternative 00100DA185256EB9_=--



From w3c-dist-auth-request@w3.org  Mon Jun 21 06:15:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27606
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 06:15:49 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 91EBAA2FA9; Mon, 21 Jun 2004 06:15:46 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A2796A2FA9
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 06:15:43 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BcLq3-0007sw-6u
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 06:15:43 -0400
Received: (qmail 26098 invoked by uid 65534); 21 Jun 2004 10:15:11 -0000
Received: from p50891472.dip0.t-ipconnect.de (EHLO pcjpl) (80.137.20.114)
  by mail.gmx.net (mp001) with SMTP; 21 Jun 2004 12:15:11 +0200
X-Authenticated: #8750622
From: <webdav-standards@webdav.info>
To: "'Geoffrey M Clemm'" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3.org>
Date: Mon, 21 Jun 2004 12:15:21 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0028_01C45789.6CC2D360"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRWciKaY4nrBcQYTRe3gXzzzln9JABBVkdQ
In-Reply-To: <OF91E07658.F231C0A5-ON85256EB9.000F78BD-85256EB9.00100DA7@us.ibm.com>
Message-Id: <20040621101543.A2796A2FA9@frink.w3.org>
Subject: AW: new auto-version value
X-Archived-At: http://www.w3.org/mid/20040621101543.A2796A2FA9@frink.w3.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8606
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621101546.91EBAA2FA9@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 06:15:46 -0400 (EDT)


This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C45789.6CC2D360
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Geoff,

 

The state machine was our initial motivation for this new auto-version property. Yes you are right the explicit check-in will
change the state, but return in the initial state again.

 

From the standard point of view we could argue that this new value would have for http and WebDAV clients the same post-condition,
namely the resource is kept checked-out. We would not tied together unlock and implicit checkin.

 

Anyway, there seems to be more points not to add it to the standard, than adding it to the standard. 

 


Best regards

Juergen Pill
Premium WebDAV Consultancy and Services 
www.webdav.info

  _____  

Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] Im Auftrag von Geoffrey M Clemm
Gesendet: Sonntag, 20. Juni 2004 04:55
An: w3c-dist-auth@w3.org
Betreff: Re: new auto-version value

 


This new auto-version value only makes sense if the "checkin" 
operation is used to promote a change in the workflow.  This is 
probably non-optimal, since it doesn't let a client save an 
intermediate state of the resource in the version history 
(i.e. before it is ready to publish).  In addition, a step 
in the workflow often requires changing multiple resources, 
so you can't really infer from one being checked-in that the 
task is complete.  So I would be against encouraging this 
model in the standard (and therefore would not 
be in favor of standardizing on this new value). 

WRT Lisa's question, he doesn't want the user to have to go to 
the external state-manipulation tool to start a modification, 
but he does expect the user to have to go to the external 
state-manipulation tool to say "I'm finished with this task". 
I agree that this is reasonable, but I'm against standardizing 
on "checkin" to mean "I'm finished with this task". 

Cheers, 
Geoff 

Lisa wrote on 06/18/2004 10:56:31 AM:
> I'm a little confused.  If you don't want the user to have to go to the 
> external state-manipulation tool, then why not use 
> checkout-unlock-checkin?  I would think you would want the checkin to 
> happen when editing is done, to publish the state.  Also note that the 
> state is "published" regardless, in that any changes made by any client 
> are visible on the resource checked out, whether or not it's checked in 
> again -- it seems pretty clear in this case you're talking about 
> in-place checkout.
> 
> The auto-version property is a bit of a hack to deal with 
> non-DeltaV-aware clients that can never know when to check out and 
> check in.  Adding more values to this property runs a risk of confusing 
> DeltaV clients that are aware of this property but only know the values 
> in the initial standard.  OTOH I'm not aware of any clients at all that 
> use the value of this property as yet so it would be good to hear if 
> there are any.

> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
> > the auto-version property can currently hold 5 different values: 
> > Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> > locked-checkout.
> >
> > I would like to propose a new value, named something like: 
> > checkout-ignore-unlock. It will carry the same semantics as the
> > checkout value, but an unlock command will not issue an implicit 
> > check-in command, instead the resource stays in the checked-out
> > state and an explicit check-in command is required.
> >
> > Use-case:
> >
> > A document is controlled by a workflow process. Creating a document 
> > takes this document in the initial-author state, in which only
> > explicit check-in command should create new versions. If this newly 
> > created resource is implicitly put under version-control and
> > the auto-version property is set to the new suggested value, we can 
> > receive this behaviour. Now the document can be modified
> > either with an http client (via put) or with a WebDAV client (Lock - 
> > Put* - Unlock) and still the resource is never implicitly
> > checked-in.
> > The same effect could be reached by an explicit check-out, but this 
> > will require an additional user interaction to issue the
> > check-out command, which we do not want to expose. Our user is then 
> > only required to use our state manipulation GUI tool, in case
> > of a real state change. The creation and manipulation of a new 
> > resource will feel like modification on the hard disc: create it,
> > modify it (with any tool) and then publish or change the state with an 
> > additional tool.
> >
> > Does this make a more general sense, or would you think this is a too 
> > specific requirement to go into any new version of the
> > delta-v standard?


------=_NextPart_000_0028_01C45789.6CC2D360
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
span.E-MailFormatvorlage18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DDE link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello =
Geoff,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The state =
machine was our
initial motivation for this new auto-version property. Yes you are right =
the explicit
check-in will change the state, but return in the initial state =
again.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>From the =
standard point
of view we could argue that this new value would have for http and =
WebDAV clients
the same post-condition, namely the resource is kept checked-out. We =
would not
tied together unlock and implicit checkin.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Anyway, there =
seems to be
more points not to add it to the standard, than adding it to the =
standard. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dnavy
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt;color:navy'><br>
Best regards<br>
<br>
Juergen Pill<br>
Premium WebDAV Consultancy and Services <br>
www.webdav.info</span></font><span lang=3DEN-GB><o:p></o:p></span></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>Von:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] =
<b><span
style=3D'font-weight:bold'>Im Auftrag von </span></b>Geoffrey M =
Clemm<br>
<b><span style=3D'font-weight:bold'>Gesendet:</span></b> Sonntag, 20. =
Juni 2004
04:55<br>
<b><span style=3D'font-weight:bold'>An:</span></b> =
w3c-dist-auth@w3.org<br>
<b><span style=3D'font-weight:bold'>Betreff:</span></b> Re: new =
auto-version
value</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>This
new auto-version value only makes sense if the =
&quot;checkin&quot;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>operation is
used to promote a change in the workflow. &nbsp;This =
is</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>probably
non-optimal, since it doesn't let a client save an</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>intermediate
state of the resource in the version history</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>(i.e. before
it is ready to publish). &nbsp;In addition, a step</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>in the
workflow often requires changing multiple resources,</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>so you can't
really infer from one being checked-in that the</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>task is
complete. &nbsp;So I would be against encouraging this =
</span></font></tt><br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>model in the
standard (and therefore would not</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>be in favor
of standardizing on this new value).</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>WRT Lisa's
question, he doesn't want the user to have to go to</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>the external
state-manipulation tool to start a modification,</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>but he does
expect the user to have to go to the external</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>state-manipulation
tool to say &quot;I'm finished with this task&quot;.</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I agree that
this is reasonable, but I'm against standardizing</span></font></tt> =
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>on
&quot;checkin&quot; to mean &quot;I'm finished with this =
task&quot;.</span></font></tt>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Cheers,</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Geoff</span></font></tt>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Lisa wrote
on 06/18/2004 10:56:31 AM:</span></font></tt><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; I'm a little confused. &nbsp;If you =
don't
want the user to have to go to the </font></tt><br>
<tt><font face=3D"Courier New">&gt; external state-manipulation tool, =
then why
not use </font></tt><br>
<tt><font face=3D"Courier New">&gt; checkout-unlock-checkin? &nbsp;I =
would think
you would want the checkin to </font></tt><br>
<tt><font face=3D"Courier New">&gt; happen when editing is done, to =
publish the
state. &nbsp;Also note that the </font></tt><br>
<tt><font face=3D"Courier New">&gt; state is &quot;published&quot; =
regardless, in
that any changes made by any client </font></tt><br>
<tt><font face=3D"Courier New">&gt; are visible on the resource checked =
out,
whether or not it's checked in </font></tt><br>
<tt><font face=3D"Courier New">&gt; again -- it seems pretty clear in =
this case
you're talking about </font></tt><br>
<tt><font face=3D"Courier New">&gt; in-place checkout.</font></tt><br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; The auto-version property is a bit =
of a hack
to deal with </font></tt><br>
<tt><font face=3D"Courier New">&gt; non-DeltaV-aware clients that can =
never know
when to check out and </font></tt><br>
<tt><font face=3D"Courier New">&gt; check in. &nbsp;Adding more values =
to this
property runs a risk of confusing </font></tt><br>
<tt><font face=3D"Courier New">&gt; DeltaV clients that are aware of =
this
property but only know the values </font></tt><br>
<tt><font face=3D"Courier New">&gt; in the initial standard. &nbsp;OTOH =
I'm not
aware of any clients at all that </font></tt><br>
<tt><font face=3D"Courier New">&gt; use the value of this property as =
yet so it
would be good to hear if </font></tt><br>
<tt><font face=3D"Courier New">&gt; there are any.</font></tt><br>
<br>
<tt><font face=3D"Courier New">&gt; On Jun 18, 2004, at 6:14 AM, Juergen =
wrote:</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; the auto-version property can =
currently
hold 5 different values: </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; Empty, checkout-checkin,
checkout-unlock-checkin, checkout and</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; =
locked-checkout.</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt;</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; I would like to propose a new =
value,
named something like: </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; checkout-ignore-unlock. It will =
carry
the same semantics as the</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; checkout value, but an unlock =
command
will not issue an implicit </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; check-in command, instead the =
resource
stays in the checked-out</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; state and an explicit check-in =
command
is required.</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt;</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; Use-case:</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt;</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; A document is controlled by a =
workflow
process. Creating a document </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; takes this document in the
initial-author state, in which only</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; explicit check-in command =
should create
new versions. If this newly </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; created resource is implicitly =
put under
version-control and</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; the auto-version property is =
set to the
new suggested value, we can </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; receive this behaviour. Now the =
document
can be modified</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; either with an http client (via =
put) or
with a WebDAV client (Lock - </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; Put* - Unlock) and still the =
resource is
never implicitly</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; checked-in.</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; The same effect could be =
reached by an
explicit check-out, but this </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; will require an additional user
interaction to issue the</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; check-out command, which we do =
not want
to expose. Our user is then </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; only required to use our state
manipulation GUI tool, in case</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; of a real state change. The =
creation and
manipulation of a new </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; resource will feel like =
modification on
the hard disc: create it,</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; modify it (with any tool) and =
then
publish or change the state with an </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; additional =
tool.</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt;</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; Does this make a more general =
sense, or
would you think this is a too </font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; specific requirement to go into =
any new
version of the</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt; delta-v =
standard?</font></tt></span></font><o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0028_01C45789.6CC2D360--



From w3c-dist-auth-request@w3.org  Mon Jun 21 11:23:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20163
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 11:23:48 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E9945A1113; Mon, 21 Jun 2004 11:23:49 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 7B623A28F9
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 11:23:47 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BcQeB-00068E-E6
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 11:23:47 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5LFMbJL012293
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 21 Jun 2004 08:22:40 -0700
In-Reply-To: <20040621101543.A2796A2FA9@frink.w3.org>
References: <20040621101543.A2796A2FA9@frink.w3.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F5E2E859-C396-11D8-A549-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: WebDAV <w3c-dist-auth@w3.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 21 Jun 2004 08:23:34 -0700
To: <webdav-standards@webdav.info>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: AW: new auto-version value
X-Archived-At: http://www.w3.org/mid/F5E2E859-C396-11D8-A549-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8607
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621152349.E9945A1113@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 11:23:49 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Would another separate property work as well, or better?  A 'publish' 
property for manual setting, or an 'auto-publish' property indicating 
when the server should try to publish?  You might find support for that 
kind of thing orthogonal from versioning.

Lisa


On Jun 21, 2004, at 3:15 AM, <webdav-standards@webdav.info> wrote:

> Hello Geoff,
>
>
>
> The state machine was our initial motivation for this new auto-version 
> property. Yes you are right the explicit check-in will
> change the state, but return in the initial state again.
>
>
>
> From the standard point of view we could argue that this new value 
> would have for http and WebDAV clients the same post-condition,
> namely the resource is kept checked-out. We would not tied together 
> unlock and implicit checkin.
>
>
>
> Anyway, there seems to be more points not to add it to the standard, 
> than adding it to the standard.
>
>
>
>
> Best regards
>
> Juergen Pill
> Premium WebDAV Consultancy and Services
> www.webdav.info
>
>   _____
>
> Von: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] Im Auftrag von Geoffrey M Clemm
> Gesendet: Sonntag, 20. Juni 2004 04:55
> An: w3c-dist-auth@w3.org
> Betreff: Re: new auto-version value
>
>
>
>
> This new auto-version value only makes sense if the "checkin"
> operation is used to promote a change in the workflow.  This is
> probably non-optimal, since it doesn't let a client save an
> intermediate state of the resource in the version history
> (i.e. before it is ready to publish).  In addition, a step
> in the workflow often requires changing multiple resources,
> so you can't really infer from one being checked-in that the
> task is complete.  So I would be against encouraging this
> model in the standard (and therefore would not
> be in favor of standardizing on this new value).
>
> WRT Lisa's question, he doesn't want the user to have to go to
> the external state-manipulation tool to start a modification,
> but he does expect the user to have to go to the external
> state-manipulation tool to say "I'm finished with this task".
> I agree that this is reasonable, but I'm against standardizing
> on "checkin" to mean "I'm finished with this task".
>
> Cheers,
> Geoff
>
> Lisa wrote on 06/18/2004 10:56:31 AM:
>> I'm a little confused.  If you don't want the user to have to go to 
>> the
>> external state-manipulation tool, then why not use
>> checkout-unlock-checkin?  I would think you would want the checkin to
>> happen when editing is done, to publish the state.  Also note that the
>> state is "published" regardless, in that any changes made by any 
>> client
>> are visible on the resource checked out, whether or not it's checked 
>> in
>> again -- it seems pretty clear in this case you're talking about
>> in-place checkout.
>>
>> The auto-version property is a bit of a hack to deal with
>> non-DeltaV-aware clients that can never know when to check out and
>> check in.  Adding more values to this property runs a risk of 
>> confusing
>> DeltaV clients that are aware of this property but only know the 
>> values
>> in the initial standard.  OTOH I'm not aware of any clients at all 
>> that
>> use the value of this property as yet so it would be good to hear if
>> there are any.
>
>> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
>>> the auto-version property can currently hold 5 different values:
>>> Empty, checkout-checkin, checkout-unlock-checkin, checkout and
>>> locked-checkout.
>>>
>>> I would like to propose a new value, named something like:
>>> checkout-ignore-unlock. It will carry the same semantics as the
>>> checkout value, but an unlock command will not issue an implicit
>>> check-in command, instead the resource stays in the checked-out
>>> state and an explicit check-in command is required.
>>>
>>> Use-case:
>>>
>>> A document is controlled by a workflow process. Creating a document
>>> takes this document in the initial-author state, in which only
>>> explicit check-in command should create new versions. If this newly
>>> created resource is implicitly put under version-control and
>>> the auto-version property is set to the new suggested value, we can
>>> receive this behaviour. Now the document can be modified
>>> either with an http client (via put) or with a WebDAV client (Lock -
>>> Put* - Unlock) and still the resource is never implicitly
>>> checked-in.
>>> The same effect could be reached by an explicit check-out, but this
>>> will require an additional user interaction to issue the
>>> check-out command, which we do not want to expose. Our user is then
>>> only required to use our state manipulation GUI tool, in case
>>> of a real state change. The creation and manipulation of a new
>>> resource will feel like modification on the hard disc: create it,
>>> modify it (with any tool) and then publish or change the state with 
>>> an
>>> additional tool.
>>>
>>> Does this make a more general sense, or would you think this is a too
>>> specific requirement to go into any new version of the
>>> delta-v standard?
>



From w3c-dist-auth-request@w3.org  Mon Jun 21 13:17:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07074
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 13:17:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4CBFEA1F86; Mon, 21 Jun 2004 13:17:51 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E0166A1FB8
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 13:17:47 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BcSQN-00059N-RK
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 13:17:40 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5LHGVJL003784
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 21 Jun 2004 10:16:31 -0700
In-Reply-To: <40B20BBD.6070609@gmx.de>
References: <40B20BBD.6070609@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 21 Jun 2004 10:17:28 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue 079_UNLOCK_BY_NON_LOCK_OWNER
X-Archived-At: http://www.w3.org/mid/DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8608
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621171751.4CBFEA1F86@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 13:17:51 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm fine with 1 and 2, but I don't understand problem #3.

What this text attempts to say is that the server SHOULD redirect an 
UNLOCK request to the correct URI if the UNLOCK request has the wrong 
URI for the lock token -- that's the ideal response.  If the server 
can't do that, then as Plan B, the server MAY [or SHOULD?] return a 
simple error.

What's wrong with a specification having a Plan B if the software can't 
do Plan A for some reason?  Returning errors is the typical Plan B 
anyway...

I agree the text needs a little more specifics about what kind of 
redirect -- suggestions?

Lisa

On May 24, 2004, at 7:50 AM, Julian Reschke wrote:

>
> Hi,
>
> while I was looking for the resolution for 
> "079_UNLOCK_BY_NON_LOCK_OWNER", I came across the following text in 
> bis-05:
>
>> 8.12    UNLOCK Method        The UNLOCK method removes the lock 
>> identified by the lock token in    the Lock-Token request header from 
>> the Request-URI and all other    resources included in the lock.  The 
>> root of the lock MUST be named    by the Request-URI, not any other 
>> resource within the scope of the    lock.  Servers SHOULD redirect 
>> the UNLOCK request to the lock root.     Failing that, servers MAY 
>> fail an UNLOCK request to a resource that    is not directly locked 
>> (not the root of the lock) with error code    400 (Bad Request).
>
>
> 1) It should say "...in the Lock-Token request header from the 
> resource identified by the Request-URI and all other resources 
> included in the lock." (old text from RFC2518)
>
> 2) "The root of the lock MUST be named by the Request-URI, not any 
> other resource within the scope of the lock.": What is this supposed 
> to mean? That the Request-URI MUST identify the lock root? I think 
> this needs clarification.
>
> 3) "Servers SHOULD redirect the UNLOCK request to the lock root. 
> Failing that, servers MAY fail an UNLOCK request to a resource that is 
> not directly locked (not the root of the lock) with error code 400 
> (Bad Request).": Again, I'm not sure what this is supposed to mean. If 
> the resource identified by the Request-URI is not the lock root, it 
> seems that the previous statement REQUIRES the server to fail the 
> request, not to do a "redirect" (what kind of redirect would that 
> be?).
>
> Back to issue "079_UNLOCK_BY_NON_LOCK_OWNER":
>
> "Resolved in part by putting it under ACL control: 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html 
> and the response that follows it."
>
> The referenced mailing list entry indicates that we want text to be 
> added to the spec, yet I can't find in in bis-05 (al least not under 
> UNLOCK).
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Mon Jun 21 13:31:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09960
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 13:31:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0554AA0939; Mon, 21 Jun 2004 13:31:42 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5D8BAA0939
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 13:31:40 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BcSdw-0007X6-0M
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 13:31:40 -0400
Received: (qmail 854 invoked by uid 65534); 21 Jun 2004 17:31:08 -0000
Received: from p508244CC.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.68.204)
  by mail.gmx.net (mp010) with SMTP; 21 Jun 2004 19:31:08 +0200
X-Authenticated: #1915285
Message-ID: <40D71B55.7010603@gmx.de>
Date: Mon, 21 Jun 2004 19:31:01 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: w3c-dist-auth@w3.org
References: <40B20BBD.6070609@gmx.de> <DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org>
In-Reply-To: <DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 079_UNLOCK_BY_NON_LOCK_OWNER
X-Archived-At: http://www.w3.org/mid/40D71B55.7010603@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8609
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621173142.0554AA0939@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 13:31:42 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'm fine with 1 and 2, but I don't understand problem #3.
> 
> What this text attempts to say is that the server SHOULD redirect an 
> UNLOCK request to the correct URI if the UNLOCK request has the wrong 
> URI for the lock token -- that's the ideal response.  If the server 
> can't do that, then as Plan B, the server MAY [or SHOULD?] return a 
> simple error.
> 
> What's wrong with a specification having a Plan B if the software can't 
> do Plan A for some reason?  Returning errors is the typical Plan B 
> anyway...
> 
> I agree the text needs a little more specifics about what kind of 
> redirect -- suggestions?

Well, if in the context of an HTTP related spec you talk about 
"redirecting" something, many will read that as having to do with a 3xx 
status code. I'm still not sure whether this is what you intend to say 
or not.

If, on the other hand, you're saying that the server SHOULD accept the 
UNLOCK even if the request URI is only indirectly locked (and just do 
the unlock then), then it doesn't make sense to add any more text. As 
Geoff pointed out recently about text *I* did write, saying "server 
SHOULD do 'x' and MAY do not('x')" is bad specification text; it only 
confuses the audience.

Anyway, quoting myself in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0170.html>:

"OK,

here are some actual test results:

a) Apache/moddav: allows UNLOCK on indirectly locked resources,
b) Xythos: same,
c) SAP Enterprise Portal: same,
d) Microsoft IIS: no support for depth infinity locks.

Thus the current text in the issues resolution "Resolved that you can
specify any URL locked by the lock you want to unlock" does indeed
reflect current implementation experience, and this is what spec
revisions should be saying.

Thus:

1) RFC2518bis should undo that change, and
2) GULP should be updated accordingly (I'll do that for my in-document
copy of GULP at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C>."


...and that's what I did with (a) my draft and (b) GULP (they both are 
now consistent with what the issues list states as working group 
consensus, see issue 65).

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



From w3c-dist-auth-request@w3.org  Mon Jun 21 13:38:05 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10839
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 13:38:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9D8A1A1090; Mon, 21 Jun 2004 13:38:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D0898A1090
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 13:38:03 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BcSk7-0000Xv-HC
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 13:38:03 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5LHavJL013630
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3.org>; Mon, 21 Jun 2004 10:36:58 -0700
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40D71B55.7010603@gmx.de>
References: <40B20BBD.6070609@gmx.de> <DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org> <40D71B55.7010603@gmx.de>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BADE6896-C3A9-11D8-82D6-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 21 Jun 2004 10:37:55 -0700
To: WebDAV <w3c-dist-auth@w3.org>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/BADE6896-C3A9-11D8-82D6-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8610
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621173806.9D8A1A1090@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 13:38:06 -0400 (EDT)
Content-Transfer-Encoding: 7bit


This would overturn a consensus that had previously been determined at  
a WG meeting that happened together with an interoperability meeting,  
and the consensus was not challenged on the mailing list at that time.

However, given that we have new information -- actual research!   
(thanks) -- it does make sense to reconsider.

WG members please indicate your old, new, and/ or current preference,  
with reasons if they've not already been stated here:
1. Should servers accept an UNLOCK request where the Request-URI names  
any resource covered by the lock named in the lock token?
2. Or, should servers redirect that UNLOCK request to the root of the  
lock?
3. If something else, please explain.

Part of the rationale for #2 in the original consensus was to make sure  
that clients understood the scope of the lock they were attempting to  
remove -- so that the entire collection, if previously marked as  
locked, would now be shown as unlocked, rather than just the resources  
covered by the Request-URI.

Please indicate your preference by July 6.

Lisa

On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> I'm fine with 1 and 2, but I don't understand problem #3.
>> What this text attempts to say is that the server SHOULD redirect an  
>> UNLOCK request to the correct URI if the UNLOCK request has the wrong  
>> URI for the lock token -- that's the ideal response.  If the server  
>> can't do that, then as Plan B, the server MAY [or SHOULD?] return a  
>> simple error.
>> What's wrong with a specification having a Plan B if the software  
>> can't do Plan A for some reason?  Returning errors is the typical  
>> Plan B anyway...
>> I agree the text needs a little more specifics about what kind of  
>> redirect -- suggestions?
>
> Well, if in the context of an HTTP related spec you talk about  
> "redirecting" something, many will read that as having to do with a  
> 3xx status code. I'm still not sure whether this is what you intend to  
> say or not.
>
> If, on the other hand, you're saying that the server SHOULD accept the  
> UNLOCK even if the request URI is only indirectly locked (and just do  
> the unlock then), then it doesn't make sense to add any more text. As  
> Geoff pointed out recently about text *I* did write, saying "server  
> SHOULD do 'x' and MAY do not('x')" is bad specification text; it only  
> confuses the audience.
>
> Anyway, quoting myself in
>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> 0170.html>:
>
> "OK,
>
> here are some actual test results:
>
> a) Apache/moddav: allows UNLOCK on indirectly locked resources,
> b) Xythos: same,
> c) SAP Enterprise Portal: same,
> d) Microsoft IIS: no support for depth infinity locks.
>
> Thus the current text in the issues resolution "Resolved that you can
> specify any URL locked by the lock you want to unlock" does indeed
> reflect current implementation experience, and this is what spec
> revisions should be saying.
>
> Thus:
>
> 1) RFC2518bis should undo that change, and
> 2) GULP should be updated accordingly (I'll do that for my in-document
> copy of GULP at
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> latest.html#rfc.section.C>."
>
>
> ...and that's what I did with (a) my draft and (b) GULP (they both are  
> now consistent with what the issues list states as working group  
> consensus, see issue 65).
>
> Best regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Mon Jun 21 13:46:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11583
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 13:46:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E6278A1DD3; Mon, 21 Jun 2004 13:46:28 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 338CBA1DD3
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 13:46:26 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BcSsD-0001wG-VE
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 13:46:26 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5LHjKJL020292
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3.org>; Mon, 21 Jun 2004 10:45:21 -0700
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <B7979DCC-C3AA-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: WebDAV <w3c-dist-auth@w3.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 21 Jun 2004 10:44:59 -0700
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Status of RFC2518bis
X-Archived-At: http://www.w3.org/mid/B7979DCC-C3AA-11D8-B2D4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8611
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621174628.E6278A1DD3@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 13:46:28 -0400 (EDT)
Content-Transfer-Encoding: 7bit


As you know, progress on RFC 2518 bis has been a little slow.  I've had
a bunch of issues stopping me from devoting as much effort as I wanted
to. In particular, co-chair changes have required a lot of attention and
made it hard to declare consensus on RFC2518bis changes. Also,
I changed jobs back in March, and my new job definitely had a
learning curve to climb, but in the long run OSAF strongly supports
my work at the IETF, so this is a good thing.

Anyway I'm back in the saddle and preparing the next revision, which
I'll make sure to publish before the Internet-Draft cutoff date for
the August meeting.  It may well not be the final version because of
those same consensus issues, but at least it will be progress, and
we'll have lots to discuss in August in person, and on the list.

Thanks for your patience!

Lisa



From w3c-dist-auth-request@w3.org  Mon Jun 21 13:51:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11826
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 13:51:23 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 86FAAA1A0A; Mon, 21 Jun 2004 13:51:24 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3A9E5A2962
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 13:51:21 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BcSwy-0003Pj-UK
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 13:51:21 -0400
Received: (qmail 3589 invoked by uid 65534); 21 Jun 2004 17:50:50 -0000
Received: from p508244CC.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.68.204)
  by mail.gmx.net (mp020) with SMTP; 21 Jun 2004 19:50:50 +0200
X-Authenticated: #1915285
Message-ID: <40D71FF8.5050700@gmx.de>
Date: Mon, 21 Jun 2004 19:50:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <w3c-dist-auth@w3.org>
References: <40B20BBD.6070609@gmx.de> <DF782A84-C3A6-11D8-A549-000A95B2BB72@osafoundation.org> <40D71B55.7010603@gmx.de> <BADE6896-C3A9-11D8-82D6-000A95B2BB72@osafoundation.org>
In-Reply-To: <BADE6896-C3A9-11D8-82D6-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/40D71FF8.5050700@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8612
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621175124.86FAAA1A0A@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 13:51:24 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> This would overturn a consensus that had previously been determined at  
> a WG meeting that happened together with an interoperability meeting,  
> and the consensus was not challenged on the mailing list at that time.
 > ...

Procedural comment: we have the RFC2518 issues list to capture issues 
and their resolutions. If the issues list records a *different* 
consensus than then one you were basing your edits on RFC2518bis on, 
this is a problem. So it's really essential that if consensus indeed 
*changes* at some point of time, this is explicitly 
announced/discussed/reviewed here, and  the issues list indeed gets 
updated accordingly.

That being said, I really don't care a lot about what way we go. 
However, disallowing a behaviour that current servers currently *do* 
allow seems to a bit dangerous. We will at least need to convince 
ourselves that making that change doesn't break any existing clients.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon Jun 21 15:45:44 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21439
	for <webdav-archive@lists.ietf.org>; Mon, 21 Jun 2004 15:45:44 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4F71DA252E; Mon, 21 Jun 2004 15:45:45 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AD8B6A1775
	for <w3c-dist-auth@listhub.w3.org>; Mon, 21 Jun 2004 15:45:42 -0400 (EDT)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BcUje-0008PC-Hc
	for w3c-dist-auth@w3.org; Mon, 21 Jun 2004 15:45:42 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5LJj7kw603898
	for <w3c-dist-auth@w3.org>; Mon, 21 Jun 2004 15:45:07 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5LJjqru099084
	for <w3c-dist-auth@w3.org>; Mon, 21 Jun 2004 15:45:53 -0400
In-Reply-To: <BADE6896-C3A9-11D8-82D6-000A95B2BB72@osafoundation.org>
To: WebDAV <w3c-dist-auth@w3.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF65D87D4E.1B868715-ON85256EBA.006B2B6C-85256EBA.006C7F7A@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 21 Jun 2004 15:44:34 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/21/2004 15:44:33,
	Serialize complete at 06/21/2004 15:44:33
Content-Type: multipart/alternative; boundary="=_alternative 006C7F7685256EBA_="
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/OF65D87D4E.1B868715-ON85256EBA.006B2B6C-85256EBA.006C7F7A@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8613
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040621194545.4F71DA252E@frink.w3.org>
Resent-Date: Mon, 21 Jun 2004 15:45:45 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 006C7F7685256EBA_=
Content-Type: text/plain; charset="US-ASCII"

No preference.  If we had no existing clients counting on this,
I'd go with the requirement that UNLOCK MUST be applied to the
lock root, but if there existing clients would fail in some non-trivial
way because of this, then I'd allow the UNLOCK to apply to any URL
that was protected by that LOCK.

Cheers,
Geoff

Lisa wrote on 06/21/2004 01:37:55 PM:

> WG members please indicate your old, new, and/ or current preference, 
> with reasons if they've not already been stated here:
> 1. Should servers accept an UNLOCK request where the Request-URI names 
> any resource covered by the lock named in the lock token?
> 2. Or, should servers redirect that UNLOCK request to the root of the 
> lock?
> 3. If something else, please explain.
> 
> Part of the rationale for #2 in the original consensus was to make sure 
> that clients understood the scope of the lock they were attempting to 
> remove -- so that the entire collection, if previously marked as 
> locked, would now be shown as unlocked, rather than just the resources 
> covered by the Request-URI.
> 
> Please indicate your preference by July 6.
> 
> Lisa
> 
> On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:
> 
> >
> > Lisa Dusseault wrote:
> >
> >> I'm fine with 1 and 2, but I don't understand problem #3.
> >> What this text attempts to say is that the server SHOULD redirect an 
> >> UNLOCK request to the correct URI if the UNLOCK request has the wrong 
 
> >> URI for the lock token -- that's the ideal response.  If the server 
> >> can't do that, then as Plan B, the server MAY [or SHOULD?] return a 
> >> simple error.
> >> What's wrong with a specification having a Plan B if the software 
> >> can't do Plan A for some reason?  Returning errors is the typical 
> >> Plan B anyway...
> >> I agree the text needs a little more specifics about what kind of 
> >> redirect -- suggestions?
> >
> > Well, if in the context of an HTTP related spec you talk about 
> > "redirecting" something, many will read that as having to do with a 
> > 3xx status code. I'm still not sure whether this is what you intend to 
 
> > say or not.
> >
> > If, on the other hand, you're saying that the server SHOULD accept the 
 
> > UNLOCK even if the request URI is only indirectly locked (and just do 
> > the unlock then), then it doesn't make sense to add any more text. As 
> > Geoff pointed out recently about text *I* did write, saying "server 
> > SHOULD do 'x' and MAY do not('x')" is bad specification text; it only 
> > confuses the audience.
> >
> > Anyway, quoting myself in
> >
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> > 0170.html>:
> >
> > "OK,
> >
> > here are some actual test results:
> >
> > a) Apache/moddav: allows UNLOCK on indirectly locked resources,
> > b) Xythos: same,
> > c) SAP Enterprise Portal: same,
> > d) Microsoft IIS: no support for depth infinity locks.
> >
> > Thus the current text in the issues resolution "Resolved that you can
> > specify any URL locked by the lock you want to unlock" does indeed
> > reflect current implementation experience, and this is what spec
> > revisions should be saying.
> >
> > Thus:
> >
> > 1) RFC2518bis should undo that change, and
> > 2) GULP should be updated accordingly (I'll do that for my in-document
> > copy of GULP at
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> > latest.html#rfc.section.C>."
> >
> >
> > ...and that's what I did with (a) my draft and (b) GULP (they both are 
 
> > now consistent with what the issues list states as working group 
> > consensus, see issue 65).
> >
> > Best regards, Julian
> > -- 
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> 

--=_alternative 006C7F7685256EBA_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>No preference. &nbsp;If we had no existing clients
counting on this,</tt></font>
<br><font size=2><tt>I'd go with the requirement that UNLOCK MUST be applied
to the</tt></font>
<br><font size=2><tt>lock root, but if there existing clients would fail
in some non-trivial</tt></font>
<br><font size=2><tt>way because of this, then I'd allow the UNLOCK to
apply to any URL</tt></font>
<br><font size=2><tt>that was protected by that LOCK.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Lisa wrote on 06/21/2004 01:37:55 PM:<br>
<br>
&gt; WG members please indicate your old, new, and/ or current preference,
&nbsp;<br>
&gt; with reasons if they've not already been stated here:<br>
&gt; 1. Should servers accept an UNLOCK request where the Request-URI names
&nbsp;<br>
&gt; any resource covered by the lock named in the lock token?<br>
&gt; 2. Or, should servers redirect that UNLOCK request to the root of
the &nbsp;<br>
&gt; lock?<br>
&gt; 3. If something else, please explain.<br>
&gt; <br>
&gt; Part of the rationale for #2 in the original consensus was to make
sure &nbsp;<br>
&gt; that clients understood the scope of the lock they were attempting
to &nbsp;<br>
&gt; remove -- so that the entire collection, if previously marked as &nbsp;<br>
&gt; locked, would now be shown as unlocked, rather than just the resources
&nbsp;<br>
&gt; covered by the Request-URI.<br>
&gt; <br>
&gt; Please indicate your preference by July 6.<br>
&gt; <br>
&gt; Lisa<br>
&gt; <br>
&gt; On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:<br>
&gt; <br>
&gt; &gt;<br>
&gt; &gt; Lisa Dusseault wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt; I'm fine with 1 and 2, but I don't understand problem #3.<br>
&gt; &gt;&gt; What this text attempts to say is that the server SHOULD
redirect an &nbsp;<br>
&gt; &gt;&gt; UNLOCK request to the correct URI if the UNLOCK request has
the wrong &nbsp;<br>
&gt; &gt;&gt; URI for the lock token -- that's the ideal response. &nbsp;If
the server &nbsp;<br>
&gt; &gt;&gt; can't do that, then as Plan B, the server MAY [or SHOULD?]
return a &nbsp;<br>
&gt; &gt;&gt; simple error.<br>
&gt; &gt;&gt; What's wrong with a specification having a Plan B if the
software &nbsp;<br>
&gt; &gt;&gt; can't do Plan A for some reason? &nbsp;Returning errors is
the typical &nbsp;<br>
&gt; &gt;&gt; Plan B anyway...<br>
&gt; &gt;&gt; I agree the text needs a little more specifics about what
kind of &nbsp;<br>
&gt; &gt;&gt; redirect -- suggestions?<br>
&gt; &gt;<br>
&gt; &gt; Well, if in the context of an HTTP related spec you talk about
&nbsp;<br>
&gt; &gt; &quot;redirecting&quot; something, many will read that as having
to do with a &nbsp;<br>
&gt; &gt; 3xx status code. I'm still not sure whether this is what you
intend to &nbsp;<br>
&gt; &gt; say or not.<br>
&gt; &gt;<br>
&gt; &gt; If, on the other hand, you're saying that the server SHOULD accept
the &nbsp;<br>
&gt; &gt; UNLOCK even if the request URI is only indirectly locked (and
just do &nbsp;<br>
&gt; &gt; the unlock then), then it doesn't make sense to add any more
text. As &nbsp;<br>
&gt; &gt; Geoff pointed out recently about text *I* did write, saying &quot;server
&nbsp;<br>
&gt; &gt; SHOULD do 'x' and MAY do not('x')&quot; is bad specification
text; it only &nbsp;<br>
&gt; &gt; confuses the audience.<br>
&gt; &gt;<br>
&gt; &gt; Anyway, quoting myself in<br>
&gt; &gt;<br>
&gt; &gt; &lt;http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/
<br>
&gt; &gt; 0170.html&gt;:<br>
&gt; &gt;<br>
&gt; &gt; &quot;OK,<br>
&gt; &gt;<br>
&gt; &gt; here are some actual test results:<br>
&gt; &gt;<br>
&gt; &gt; a) Apache/moddav: allows UNLOCK on indirectly locked resources,<br>
&gt; &gt; b) Xythos: same,<br>
&gt; &gt; c) SAP Enterprise Portal: same,<br>
&gt; &gt; d) Microsoft IIS: no support for depth infinity locks.<br>
&gt; &gt;<br>
&gt; &gt; Thus the current text in the issues resolution &quot;Resolved
that you can<br>
&gt; &gt; specify any URL locked by the lock you want to unlock&quot; does
indeed<br>
&gt; &gt; reflect current implementation experience, and this is what spec<br>
&gt; &gt; revisions should be saying.<br>
&gt; &gt;<br>
&gt; &gt; Thus:<br>
&gt; &gt;<br>
&gt; &gt; 1) RFC2518bis should undo that change, and<br>
&gt; &gt; 2) GULP should be updated accordingly (I'll do that for my in-document<br>
&gt; &gt; copy of GULP at<br>
&gt; &gt; &lt;http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
<br>
&gt; &gt; latest.html#rfc.section.C&gt;.&quot;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ...and that's what I did with (a) my draft and (b) GULP (they
both are &nbsp;<br>
&gt; &gt; now consistent with what the issues list states as working group
&nbsp;<br>
&gt; &gt; consensus, see issue 65).<br>
&gt; &gt;<br>
&gt; &gt; Best regards, Julian<br>
&gt; &gt; -- <br>
&gt; &gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; &gt;<br>
&gt; <br>
</tt></font>
--=_alternative 006C7F7685256EBA_=--



From w3c-dist-auth-request@w3.org  Tue Jun 22 03:13:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12833
	for <webdav-archive@lists.ietf.org>; Tue, 22 Jun 2004 03:13:30 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CCBD1A2266; Tue, 22 Jun 2004 03:13:29 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9799CA21D2
	for <w3c-dist-auth@listhub.w3.org>; Tue, 22 Jun 2004 03:13:25 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BcfSz-00089X-OH
	for w3c-dist-auth@w3.org; Tue, 22 Jun 2004 03:13:14 -0400
Received: (qmail 22544 invoked by uid 65534); 22 Jun 2004 07:12:42 -0000
Received: from pD9E519BC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.25.188)
  by mail.gmx.net (mp008) with SMTP; 22 Jun 2004 09:12:42 +0200
X-Authenticated: #1915285
Message-ID: <40D7DBE0.4030106@gmx.de>
Date: Tue, 22 Jun 2004 09:12:32 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: ID: draft-reschke-webdav-locking-03
X-Archived-At: http://www.w3.org/mid/40D7DBE0.4030106@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8614
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040622071329.CCBD1A2266@frink.w3.org>
Resent-Date: Tue, 22 Jun 2004 03:13:29 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I have submitted another version of my experimental stand-alone locking
protocol document.  Revision 03
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-03.html> 
and 
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-03.txt>)
have the following changes:

E.3  Since draft-reschke-webdav-locking-02

    Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04",
    "040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS",
    "067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN".
    Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version
    (5.7).  Add and resolve new issue "7.5_DELETE_vs_URIs".  Start work
    on "additional marshalling" and "introduction".  Update issues
    "044_REPORT_OTHER_RESOURCE_LOCKED" and
    "066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL".

(The HTML versions have all changes highlighted, so it's easy to see 
what actually has been changing between revisions since the "import" of 
text from RFC2518).

As usual, edits are ongoing on
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>. 

The current issues list is at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>.

I'm now busy rewriting the LOCK *creation* method description and also 
adding precondition names (also for some non-LOCK related issues that 
however can occur when using LOCK or UNLOCK).

Feedback appreciated, Julian


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



From w3c-dist-auth-request@w3.org  Tue Jun 22 22:54:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26305
	for <webdav-archive@lists.ietf.org>; Tue, 22 Jun 2004 22:54:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7EC69A31C1; Tue, 22 Jun 2004 22:54:22 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DC3DAA31C1
	for <w3c-dist-auth@listhub.w3.org>; Tue, 22 Jun 2004 22:54:19 -0400 (EDT)
Received: from dsl081-100-205.den1.dsl.speakeasy.net ([64.81.100.205] helo=giles.cursive.net)
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1Bcxtz-0000YI-Kl
	for w3c-dist-auth@w3.org; Tue, 22 Jun 2004 22:54:19 -0400
Received: from [10.71.0.137] ([66.234.237.2]) by giles.cursive.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 22 Jun 2004 20:53:48 -0600
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: w3c-dist-auth@w3.org
From: Joe Hildebrand <joe@cursive.net>
Date: Tue, 22 Jun 2004 22:53:43 -0400
X-Mailer: Apple Mail (2.618)
X-OriginalArrivalTime: 23 Jun 2004 02:53:48.0324 (UTC) FILETIME=[4E967640:01C458CD]
Subject: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8615
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623025422.7EC69A31C1@frink.w3.org>
Resent-Date: Tue, 22 Jun 2004 22:54:22 -0400 (EDT)
Content-Transfer-Encoding: 7bit


In the interest of trying to get things moving on BIND, I've got some 
review comments.  I'm unburdened by knowing where the WG has already 
achieved consensus, so please let me know if I step on something 
unintentionally.

Meta:
  - Who is maintaining the webdav.org site for specs?  The latest draft 
for bind there is -02.
  - Is the canonical issue list the one at webdav.org?  It looks like it 
was last updated almost a year ago.

1.1
  - 'DAV:' is a namespace URI, not a namespace name.
  - Path segment being the characters found *between* slashes is 
confusing, since the last piece  of a URL is also a segment.

1.3
  - Is the first paragraph meant to be an exhaustive list of error 
codes?  Wouldn't 404 be more appropriate for (DAV:bind-source-exists) 
failing, for example?
  - Second paragraph: how might I otherwise negotiate?  The DAV:bind 
header?

2.1
- I can't find a good reference for the 506 error code. It's not in 
2616 or 2518, and is not mentioned by any of the pointers at 
http://www.iana.org/assignments/http-status-codes.  Is this a candidate 
for the IANA considerations, or are we missing a normative reference?

2.2
  - first sentence doesn't parse.  I think it was supposed to be "to 
resource R *is* to be added"

2.3
  - last paragraph is a little confusing.  I'm not seeing the timeline 
of a COPY request that may have partially succeeded.  Perhaps this is 
just unclear pronoun references, and too may copies of "copy" in one 
sentence... :)

2.5
  - last paragraph is a repeat of text two paragraphs before
  - if I'm understanding this right, MOVE is the same as REBIND, except 
for atomicity guarantees.  since we've got the same sort of issue for 
UNBIND/DELETE, isn't it possible a client could figure out that the 
server supports bind (using the DAV: header), specify an 'Atomic: T' 
header, and save us from creating two HTTP methods?  I know that 
creating http methods doesn't have the same stigma in this group as in 
others, and I don't feel strongly about this one, just trying to 
understand the design choice, since it looks like this was tracked with 
the ATOMIC issue.

3.2 (and others)
  - Should all of the DTD be gathered into a single place in an appendix 
(like 23.1 of 2518)?  Is it time to think about schema, as well?

4 (and others)
  - (DAV:locked-update-allowed) what if the resource is locked?  I 
understand that this is a property of the resource, not the binding, 
but since 2518 doesn't say anything about bindings, I think we could 
use a paragraph at some point that spells this out explicitly.  Perhaps 
another sub-section in section 2?
  - Is this what 4_LOCK_BEHAVIOR refers to?  "Done" as the resolution 
doesn't give me quite enough to go on...	

7.1
  - IANA notification for 208?

7.1.1
  - I think this would be clearer if it included D:resource-id in the 
request and response, so you could tell where the loop happened.  Are 
resource-id's likely to be costly to return?

8.2
  - The DAV: request header only has peripheral importance to this spec. 
  This is just the first place it was needed.  Is it too late for this 
to go into 2518bis, instead?  Seems to be a layering problem.  No 
matter where it ends up, we ought to think about IANA registration of 
these compliance class names.

8.2.1
  - last paragraph "it's" -> "its"

11
  - Isn't there an IANA registry for HTTP methods and request headers?  
I don't see one.  If there was one I'd want to add BIND, UNBIND, 
REBIND, and DAV:.
  - the other IANA actions i've listed above

5.1_LOOP_STATUS
  - Is there anything left to do on this?

Sorry some of these are nit-picky.

-- 
Joe Hildebrand
Denver, CO, USA



From w3c-dist-auth-request@w3.org  Wed Jun 23 03:52:13 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29525
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 03:52:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 28C46A2197; Wed, 23 Jun 2004 03:52:14 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3CC26A26C2
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 03:52:09 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1Bd2YC-0007CZ-Q2
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 03:52:09 -0400
Received: (qmail 13086 invoked by uid 65534); 23 Jun 2004 07:51:35 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp006) with SMTP; 23 Jun 2004 09:51:35 +0200
X-Authenticated: #1915285
Message-ID: <40D93685.70206@gmx.de>
Date: Wed, 23 Jun 2004 09:51:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Hildebrand <joe@cursive.net>
Cc: w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
In-Reply-To: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D93685.70206@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8616
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623075214.28C46A2197@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 03:52:14 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Joe Hildebrand wrote:
> 
> In the interest of trying to get things moving on BIND, I've got some 
> review comments.  I'm unburdened by knowing where the WG has already 
> achieved consensus, so please let me know if I step on something 
> unintentionally.

Joe, thanks for doing the review. This is what we need to finally get 
back to make progress.

> Meta:
>  - Who is maintaining the webdav.org site for specs?  The latest draft 
> for bind there is -02.

Not me. I'd love to be able to update it, but I can't. In the meantime, 
the current edits are in

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>

and the current issues lists lives at:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

>  - Is the canonical issue list the one at webdav.org?  It looks like it 
> was last updated almost a year ago.

Nope. See above.

> 1.1
>  - 'DAV:' is a namespace URI, not a namespace name.

As far as I can tell, both terms are used interchamgeably. "namespace 
name" is the one defined in the XMLNS rec: 
<http://www.w3.org/TR/REC-xml-names/#dt-NSName>.

>  - Path segment being the characters found *between* slashes is 
> confusing, since the last piece  of a URL is also a segment.

That term is defined that way in 
<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.3.3>.

> 1.3
>  - Is the first paragraph meant to be an exhaustive list of error 
> codes?  Wouldn't 404 be more appropriate for (DAV:bind-source-exists) 
> failing, for example?

a) no, it's not exhaustive,

b) and no, 404 would be incorrect because it should only occur when 
there's a problem with the resource identified by the Request-URI 
(<http://greenbytes.de/tech/webdav/rfc2616.html#status.404>):

" The server has not found anything matching the Request-URI. No 
indication is given of whether the condition is temporary or permanent. 
The 410 (Gone) status code SHOULD be used if the server knows, through 
some internally configurable mechanism, that an old resource is 
permanently unavailable and has no forwarding address. This status code 
is commonly used when the server does not wish to reveal exactly why the 
request has been refused, or when no other response is applicable."

>  - Second paragraph: how might I otherwise negotiate?  The DAV:bind header?

Good point. As far as I can tell, this text was inherited from RFC3253 
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>). 
Geoff, do you remember what this is supposed to mean? Can/should we 
clarify that?

> 2.1
> - I can't find a good reference for the 506 error code. It's not in 2616 
> or 2518, and is not mentioned by any of the pointers at 
> http://www.iana.org/assignments/http-status-codes.  Is this a candidate 
> for the IANA considerations, or are we missing a normative reference?

This is a new status code (it appears under "Additional Status Codes", 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.7.2>).

Last time I checked the IETF instructions for "IANA considerations", I 
got the impression that it's reserved for declaring *new* registries 
that the IANA needs to take care of, not adding new items to existing 
registries (such as HTTP method names, headers or status codes). Can you 
point to a normative document that clarifies?

> 2.2
>  - first sentence doesn't parse.  I think it was supposed to be "to 
> resource R *is* to be added"

Ok.

> 2.3
>  - last paragraph is a little confusing.  I'm not seeing the timeline of 
> a COPY request that may have partially succeeded.  Perhaps this is just 
> unclear pronoun references, and too may copies of "copy" in one 
> sentence... :)

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.p.5>:

"If a COPY request would cause a new resource to be created as a copy of 
an existing resource, and that COPY request has already created a copy 
of that existing resource, the COPY request instead creates another 
binding to the previous copy, instead of creating a new resource."

What this says is that while copying, the COPY request should try to 
preserve the source structure (like in a filesystem copy where an 
operation may want to try to preserve existing hard links rather than 
creating additional files). Any proposal how this can be made clearer?

> 2.5
>  - last paragraph is a repeat of text two paragraphs before

ok (it's just the first sentence, though).

>  - if I'm understanding this right, MOVE is the same as REBIND, except 
> for atomicity guarantees.  since we've got the same sort of issue for 
> UNBIND/DELETE, isn't it possible a client could figure out that the 
> server supports bind (using the DAV: header), specify an 'Atomic: T' 
> header, and save us from creating two HTTP methods?  I know that 
> creating http methods doesn't have the same stigma in this group as in 
> others, and I don't feel strongly about this one, just trying to 
> understand the design choice, since it looks like this was tracked with 
> the ATOMIC issue.

Almost. The issue here is that RFC2518 allows MOVE to be implemented as 
a COPY/DELETE sequence. That sequence wouldn't preserve for instance the 
DAV:resource-id property as required. So there are more differences, and 
as some people weren't happy with adding new requirements/restrictions 
to MOVE, the WG choose to add a separate method.

Note that a server can always do a "best effort" MOVE, but would have to 
reject the REBIND request when it can't do it "properly" (in particular, 
preserving (almost) all live properties).

> 3.2 (and others)
>  - Should all of the DTD be gathered into a single place in an appendix 
> (like 23.1 of 2518)?  Is it time to think about schema, as well?

This is a permathread (I think last time we had that back last summer). 
My take:

- the DTD fragments are there as a short notation; however WebDAV 
messages never ever can be validated using a DTD, so it's unclear what 
we gain by repeating the information in a second place in the spec (for 
the same reason it was removed from RFC2518bis)

- *if* we change notation, I'd vote for one that (1) is easy to read and 
(2) can *indeed* validate WebDAV XML messages. XML Schema can't due to 
the extensibility model we use. RelaxNG could. See 
<http://greenbytes.de/tech/webdav/rfc3470.html#rfc.section.4.7> for more 
information on this topic.

Specs that extend RFC2518 (such as earlier ACL and ORDERED-COLLECTIONS) 
should stick with RFC2518's format. If we want to change this, we should 
  do this while upgrading RFC2518 itself.

> 4 (and others)
>  - (DAV:locked-update-allowed) what if the resource is locked?  I 
> understand that this is a property of the resource, not the binding, but 
> since 2518 doesn't say anything about bindings, I think we could use a 
> paragraph at some point that spells this out explicitly.  Perhaps 
> another sub-section in section 2?

That's incorrect. In particular, 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:

"A resource may be made available through more than one URI. However 
locks apply to resources, not URIs. Therefore a LOCK request on a 
resource MUST NOT succeed if can not be honored by all the URIs through 
which the resource is addressable."

That being said, a large amount of the open issues raised against 
RFC2518 are about locking semantics. The authors of the BIND spec feel 
that it's a bad idea to try to clarify locking semantics in a document 
that's completely independant and optional. Locking semantics should be 
fully defined in a single place.

One way to do this is to wait for RFC2518bis. Another one is to factor 
out locking from the base protocol, and publish this as "update" to 
RFC2518 (at "proposed" level), and let the BIND spec refer to that. This 
is what I'm currently working on (and I'm planning to submit a complete 
rewrite in time before the IETF meeting).

I've summarized the issue at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>. 
   So far, I've seen many people agree, and it would be really good if 
the working group would come to a decision on this matter.

>  - Is this what 4_LOCK_BEHAVIOR refers to?  "Done" as the resolution 
> doesn't give me quite enough to go on...

No, I think that was a separate issue. We may want to go through the 
original message 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0200.html>) 
and make sure all things are indeed answered.

> 7.1
>  - IANA notification for 208?

See dicussion above (same for 506).

> 7.1.1
>  - I think this would be clearer if it included D:resource-id in the 
> request and response, so you could tell where the loop happened.  Are 
> resource-id's likely to be costly to return?

No, they should be cheap. I think we should update the example accordingly.

> 8.2
>  - The DAV: request header only has peripheral importance to this spec. 
>  This is just the first place it was needed.  Is it too late for this to 
> go into 2518bis, instead?  Seems to be a layering problem.  No matter 
> where it ends up, we ought to think about IANA registration of these 
> compliance class names.

It is in RFC2518bis, but the authors of RFC2518bis have repeatedly made 
clear that they don't have any estimate about when RFC2518bis will be 
done, and thus BIND should not rely in any way on RFC2518bis' contents.

> 8.2.1
>  - last paragraph "it's" -> "its"

Ok.

> 11
>  - Isn't there an IANA registry for HTTP methods and request headers?  I 
> don't see one.  If there was one I'd want to add BIND, UNBIND, REBIND, 
> and DAV:.

I think this is work-in-progress.

>  - the other IANA actions i've listed above

Yes, we need to clarify those.

> 5.1_LOOP_STATUS
>  - Is there anything left to do on this?

No, see latest issues list.

> Sorry some of these are nit-picky.

No reason to. As a matter of fact, this kind of review is what we need. 
Let's try to get things moving so that we can get back on track (BIND 
was supposed to be last-called in May according to the just updated 
working group charter).

Best regards. Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 07:05:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18058
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 07:05:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BBCCFA1B53; Wed, 23 Jun 2004 07:05:57 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D1451A1DA6
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 07:05:52 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1Bd5Zg-0007Pp-Jq
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 07:05:52 -0400
Received: (qmail 13709 invoked by uid 65534); 23 Jun 2004 11:05:21 -0000
Received: from p50824650.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.70.80)
  by mail.gmx.net (mp004) with SMTP; 23 Jun 2004 13:05:21 +0200
X-Authenticated: #1915285
Message-ID: <40D963F0.5040306@gmx.de>
Date: Wed, 23 Jun 2004 13:05:20 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Hildebrand <joe@cursive.net>
Cc: w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <40D93685.70206@gmx.de>
In-Reply-To: <40D93685.70206@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D963F0.5040306@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8617
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623110557.BBCCFA1B53@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 07:05:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I have updated
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>
with some of Joe's issues.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 07:13:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18751
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 07:13:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 43D9FA21DE; Wed, 23 Jun 2004 07:13:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D3148A21DE
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 07:13:24 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1Bd5ga-0000GL-5L
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 07:13:00 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5NBCTgA870546
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 07:12:29 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NBDHJk109678
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 07:13:17 -0400
In-Reply-To: <40D93685.70206@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Message-ID: <OF2279D0B8.93126218-ON85256EBC.003C2509-85256EBC.003D8BA1@us.ibm.com>
Date: Wed, 23 Jun 2004 07:11:54 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 07:11:55,
	Serialize complete at 06/23/2004 07:11:55
Content-Type: multipart/alternative; boundary="=_alternative 003D6E4A85256EBC_="
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/OF2279D0B8.93126218-ON85256EBC.003C2509-85256EBC.003D8BA1@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8618
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623111330.43D9FA21DE@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 07:13:30 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 003D6E4A85256EBC_=
Content-Type: text/plain; charset="US-ASCII"

Julian wrote on 06/23/2004 03:51:33 AM:

> Joe Hildebrand wrote:
> > Meta:
> >  - Who is maintaining the webdav.org site for specs?  The latest draft 

> > for bind there is -02.

That would be me ... it should be up-to-date now (with the latest 
information
from Julian's site).  In particular, I've linked the issues list directly
to Julian's issues list, since he's maintaining that document.  Also, I've
made a copy of Julian's "latest" and made it version 05.1.

> > 1.3
> >  - Second paragraph: how might I otherwise negotiate?  The DAV:bind 
header?
> 
> Good point. As far as I can tell, this text was inherited from RFC3253 
> (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>). 
> Geoff, do you remember what this is supposed to mean? Can/should we 
> clarify that?

This is just a placeholder for our deciding to marshal things differently.
In particular, suppose we had a request header that specified "return 
error
information in html format" (that was contemplated at one time).  Then the
error info would be marshalled as html in the response body, rather than 
in the xml format that is used by default.



> > 7.1.1
> >  - I think this would be clearer if it included D:resource-id in the 
> > request and response, so you could tell where the loop happened.  Are 
> > resource-id's likely to be costly to return?
> 
> No, they should be cheap. I think we should update the example 
accordingly.

I agree.


> > Sorry some of these are nit-picky.
> 
> No reason to. As a matter of fact, this kind of review is what we need. 

Definitely.  Since we are (or should be) at last call, now's the time
to nit-pick.

> Let's try to get things moving so that we can get back on track (BIND 
> was supposed to be last-called in May according to the just updated 
> working group charter).

Yes!

Cheers,
Geoff


--=_alternative 003D6E4A85256EBC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Julian wrote on 06/23/2004 03:51:33 AM:<br>
<br>
&gt; Joe Hildebrand wrote:<br>
&gt; &gt; Meta:<br>
&gt; &gt; &nbsp;- Who is maintaining the webdav.org site for specs? &nbsp;The
latest draft <br>
&gt; &gt; for bind there is -02.<br>
</tt></font>
<br><font size=2><tt>That would be me ... it should be up-to-date now (with
the latest information</tt></font>
<br><font size=2><tt>from Julian's site). &nbsp;In particular, I've linked
the issues list directly</tt></font>
<br><font size=2><tt>to Julian's issues list, since he's maintaining that
document. &nbsp;Also, I've</tt></font>
<br><font size=2><tt>made a copy of Julian's &quot;latest&quot; and made
it version 05.1.<br>
<br>
&gt; &gt; 1.3</tt></font>
<br><font size=2><tt>&gt; &gt; &nbsp;- Second paragraph: how might I otherwise
negotiate? &nbsp;The DAV:bind header?<br>
&gt; <br>
&gt; Good point. As far as I can tell, this text was inherited from RFC3253
<br>
&gt; (&lt;http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6&gt;).
<br>
&gt; Geoff, do you remember what this is supposed to mean? Can/should we
<br>
&gt; clarify that?</tt></font>
<br>
<br><font size=2><tt>This is just a placeholder for our deciding to marshal
things differently.</tt></font>
<br><font size=2><tt>In particular, suppose we had a request header that
specified &quot;return error</tt></font>
<br><font size=2><tt>information in html format&quot; (that was contemplated
at one time). &nbsp;Then the</tt></font>
<br><font size=2><tt>error info would be marshalled as html in the response
body, rather than </tt></font>
<br><font size=2><tt>in the xml format that is used by default.</tt></font>
<br><font size=2><tt><br>
<br>
<br>
&gt; &gt; 7.1.1<br>
&gt; &gt; &nbsp;- I think this would be clearer if it included D:resource-id
in the <br>
&gt; &gt; request and response, so you could tell where the loop happened.
&nbsp;Are <br>
&gt; &gt; resource-id's likely to be costly to return?<br>
&gt; <br>
&gt; No, they should be cheap. I think we should update the example accordingly.<br>
</tt></font>
<br><font size=2><tt>I agree.</tt></font>
<br><font size=2><tt><br>
<br>
&gt; &gt; Sorry some of these are nit-picky.<br>
&gt; <br>
&gt; No reason to. As a matter of fact, this kind of review is what we
need. </tt></font>
<br>
<br><font size=2><tt>Definitely. &nbsp;Since we are (or should be) at last
call, now's the time</tt></font>
<br><font size=2><tt>to nit-pick.</tt></font>
<br><font size=2><tt><br>
&gt; Let's try to get things moving so that we can get back on track (BIND
<br>
&gt; was supposed to be last-called in May according to the just updated
<br>
&gt; working group charter).<br>
</tt></font>
<br><font size=2><tt>Yes!</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br><font size=2><tt><br>
</tt></font>
--=_alternative 003D6E4A85256EBC_=--



From w3c-dist-auth-request@w3.org  Wed Jun 23 07:33:57 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20134
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 07:33:57 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 796C7A30DE; Wed, 23 Jun 2004 07:33:57 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9AFFAA30DE
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 07:33:54 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1Bd60o-0004NZ-8R
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 07:33:54 -0400
Received: (qmail 14602 invoked by uid 65534); 23 Jun 2004 11:33:23 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10)
  by mail.gmx.net (mp019) with SMTP; 23 Jun 2004 13:33:23 +0200
X-Authenticated: #1915285
Message-ID: <40D96A7F.30804@gmx.de>
Date: Wed, 23 Jun 2004 13:33:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF2279D0B8.93126218-ON85256EBC.003C2509-85256EBC.003D8BA1@us.ibm.com>
In-Reply-To: <OF2279D0B8.93126218-ON85256EBC.003C2509-85256EBC.003D8BA1@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D96A7F.30804@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8619
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623113357.796C7A30DE@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 07:33:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> ...
>  > Good point. As far as I can tell, this text was inherited from RFC3253
>  > (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>).
>  > Geoff, do you remember what this is supposed to mean? Can/should we
>  > clarify that?
> 
> This is just a placeholder for our deciding to marshal things differently.
> In particular, suppose we had a request header that specified "return error
> information in html format" (that was contemplated at one time).  Then the
> error info would be marshalled as html in the response body, rather than
> in the xml format that is used by default.

So should we change anything here to clarify?

>  > > 7.1.1
>  > >  - I think this would be clearer if it included D:resource-id in the
>  > > request and response, so you could tell where the loop happened.  Are
>  > > resource-id's likely to be costly to return?
>  >
>  > No, they should be cheap. I think we should update the example 
> accordingly.
> 
> I agree.

-> 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.7.1.1_add_resource_id>

> ..

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 07:50:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21024
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 07:50:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E4E91A2E00; Wed, 23 Jun 2004 07:50:56 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 74322A2F1E
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 07:50:48 -0400 (EDT)
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1Bd6Gs-0007H5-H2
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 07:50:30 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5NBo0Dk787872
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 07:50:00 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NBp80r084880
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 07:51:08 -0400
In-Reply-To: <40D96A7F.30804@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 07:49:24 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 07:49:26,
	Serialize complete at 06/23/2004 07:49:26
Content-Type: multipart/alternative; boundary="=_alternative 0040FFBA85256EBC_="
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8620
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623115056.E4E91A2E00@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 07:50:56 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0040FFBA85256EBC_=
Content-Type: text/plain; charset="US-ASCII"

Julian wrote on 06/23/2004 07:33:19 AM:

> Geoffrey M Clemm wrote:
> 
> > ...
> >  > Good point. As far as I can tell, this text was inherited from 
RFC3253
> >  > (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>).
> >  > Geoff, do you remember what this is supposed to mean? Can/should we
> >  > clarify that?
> > 
> > This is just a placeholder for our deciding to marshal things 
differently.
> > In particular, suppose we had a request header that specified "return 
error
> > information in html format" (that was contemplated at one time).  Then 
the
> > error info would be marshalled as html in the response body, rather 
than
> > in the xml format that is used by default.
> 
> So should we change anything here to clarify?

I can't think of anything very sensible to add here, without speculating 
about what these other marshalling mechanisms might be (which doesn't seem
like something that should appear in the spec).

Cheers,
Geoff

--=_alternative 0040FFBA85256EBC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Julian wrote on 06/23/2004 07:33:19 AM:<br>
<br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; <br>
&gt; &gt; ...<br>
&gt; &gt; &nbsp;&gt; Good point. As far as I can tell, this text was inherited
from RFC3253<br>
&gt; &gt; &nbsp;&gt; (&lt;http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6&gt;).<br>
&gt; &gt; &nbsp;&gt; Geoff, do you remember what this is supposed to mean?
Can/should we<br>
&gt; &gt; &nbsp;&gt; clarify that?<br>
&gt; &gt; <br>
&gt; &gt; This is just a placeholder for our deciding to marshal things
differently.<br>
&gt; &gt; In particular, suppose we had a request header that specified
&quot;return error<br>
&gt; &gt; information in html format&quot; (that was contemplated at one
time). &nbsp;Then the<br>
&gt; &gt; error info would be marshalled as html in the response body,
rather than<br>
&gt; &gt; in the xml format that is used by default.<br>
&gt; <br>
&gt; So should we change anything here to clarify?<br>
<br>
I can't think of anything very sensible to add here, without speculating
</tt></font>
<br><font size=2><tt>about what these other marshalling mechanisms might
be (which doesn't seem</tt></font>
<br><font size=2><tt>like something that should appear in the spec).</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
--=_alternative 0040FFBA85256EBC_=--



From w3c-dist-auth-request@w3.org  Wed Jun 23 10:22:35 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02473
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 10:22:35 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0CD3BA06F3; Wed, 23 Jun 2004 10:22:37 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9BF90A05E4
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 10:22:31 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1Bd8dz-0005TU-GW
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 10:22:31 -0400
Received: (qmail 4658 invoked by uid 65534); 23 Jun 2004 14:22:00 -0000
Received: from p50824650.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.70.80)
  by mail.gmx.net (mp018) with SMTP; 23 Jun 2004 16:22:00 +0200
X-Authenticated: #1915285
Message-ID: <40D99207.7060101@gmx.de>
Date: Wed, 23 Jun 2004 16:21:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: joe@cursive.net
References: <OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com>
In-Reply-To: <OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D99207.7060101@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8621
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623142237.0CD3BA06F3@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 10:22:37 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

>  > So should we change anything here to clarify?
> 
> I can't think of anything very sensible to add here, without speculating
> about what these other marshalling mechanisms might be (which doesn't seem
> like something that should appear in the spec).

Joe, is that explanation sufficient, or do you think we need to rewrite 
that statement in some way?

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 12:10:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10865
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 12:10:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6787CA1666; Wed, 23 Jun 2004 12:10:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2D280A31FF
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 12:10:20 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdAKJ-0001RQ-Vv
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 12:10:20 -0400
Received: (qmail 26779 invoked by uid 65534); 23 Jun 2004 16:09:48 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10)
  by mail.gmx.net (mp008) with SMTP; 23 Jun 2004 18:09:48 +0200
X-Authenticated: #1915285
Message-ID: <40D9AB4B.8010209@gmx.de>
Date: Wed, 23 Jun 2004 18:09:47 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Geoff Clemm <geoffrey.clemm@us.ibm.com>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <40D93685.70206@gmx.de> <40D963F0.5040306@gmx.de>
In-Reply-To: <40D963F0.5040306@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9AB4B.8010209@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8622
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623161023.6787CA1666@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 12:10:23 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoff,

looking at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.5_language>...

Can we remove the first sentence from the last paragraph 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.5.p.6>) 
without losing semantics?

Or is there another simple way to avoid the repeating "Although 
[RFC2518] allows a MOVE on a collection to be a non-atomic operation, a 
MOVE implemented as a REBIND MUST be atomic."? (the same statement was 
already made in a more general way two paragraphs earlier).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 13:12:18 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14118
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 13:12:17 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 770E4A0E35; Wed, 23 Jun 2004 13:12:18 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 20C83A116E
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 13:12:13 -0400 (EDT)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdBIC-0004YR-Uy
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 13:12:13 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NHBb57006724;
	Wed, 23 Jun 2004 10:11:37 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NHBY4L006551;
	Wed, 23 Jun 2004 10:11:35 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110400bcff69319c50@[129.46.227.161]>
In-Reply-To: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
Date: Wed, 23 Jun 2004 10:11:33 -0700
To: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/p06110400bcff69319c50@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8623
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623171218.770E4A0E35@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 13:12:18 -0400 (EDT)


At 10:53 PM -0400 6/22/04, Joe Hildebrand wrote:
>
>1.1
>  - 'DAV:' is a namespace URI, not a namespace name.

I think it might be more accurate to say that dav: is a URI
scheme.  See http://www.iana.org/assignments/uri-schemes.
So the following statement in 1.1: "all XML elements defined by this
specification use the XML namespace name "DAV:" might be
re-written as "The XML namespaces used in this document all
use the DAV: uri scheme".

Just my personal opinion,
			regards,
				Ted Hardie



From w3c-dist-auth-request@w3.org  Wed Jun 23 13:36:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17156
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 13:36:33 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C6324A169B; Wed, 23 Jun 2004 13:36:33 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CF769A15A8
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 13:36:28 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdBfV-00005L-Eu
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 13:36:17 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5NHZkgA885436
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 13:35:46 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NHaXJk066276
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 13:36:34 -0400
In-Reply-To: <40D9AB4B.8010209@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 13:35:11 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 13:35:11,
	Serialize complete at 06/23/2004 13:35:11
Content-Type: multipart/alternative; boundary="=_alternative 0060A7DD85256EBC_="
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8624
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623173633.C6324A169B@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 13:36:33 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0060A7DD85256EBC_=
Content-Type: text/plain; charset="US-ASCII"

Yes, we can simplify that.  In particular, I would just move
the second sentence of the last paragraph to the end of the second 
paragraph,
and then delete the rest of the last paragraph. 

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 06/23/2004 12:09:47 PM:

> Geoff,
> 
> looking at 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#rfc.issue.2.5_language>...
> 
> Can we remove the first sentence from the last paragraph 
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#rfc.section.2.5.p.6>) 
> without losing semantics?
> 
> Or is there another simple way to avoid the repeating "Although 
> [RFC2518] allows a MOVE on a collection to be a non-atomic operation, a 
> MOVE implemented as a REBIND MUST be atomic."? (the same statement was 
> already made in a more general way two paragraphs earlier).
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

--=_alternative 0060A7DD85256EBC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Yes, we can simplify that. &nbsp;In particular, I
would just move</tt></font>
<br><font size=2><tt>the second sentence of the last paragraph to the end
of the second paragraph,</tt></font>
<br><font size=2><tt>and then delete the rest of the last paragraph. &nbsp;</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote
on 06/23/2004 12:09:47 PM:<br>
<br>
&gt; Geoff,<br>
&gt; <br>
&gt; looking at <br>
&gt; &lt;http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.<br>
&gt; html#rfc.issue.2.5_language&gt;...<br>
&gt; <br>
&gt; Can we remove the first sentence from the last paragraph <br>
&gt; (&lt;http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.<br>
&gt; html#rfc.section.2.5.p.6&gt;) <br>
&gt; without losing semantics?<br>
&gt; <br>
&gt; Or is there another simple way to avoid the repeating &quot;Although
<br>
&gt; [RFC2518] allows a MOVE on a collection to be a non-atomic operation,
a <br>
&gt; MOVE implemented as a REBIND MUST be atomic.&quot;? (the same statement
was <br>
&gt; already made in a more general way two paragraphs earlier).<br>
&gt; <br>
&gt; Best regards, Julian<br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
</tt></font>
--=_alternative 0060A7DD85256EBC_=--



From w3c-dist-auth-request@w3.org  Wed Jun 23 14:17:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26913
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 14:17:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F0EDCA1322; Wed, 23 Jun 2004 14:17:45 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BAB7BA494B
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 14:17:42 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdCJa-0007Pk-JW
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 14:17:42 -0400
Received: (qmail 15922 invoked by uid 65534); 23 Jun 2004 18:17:11 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp018) with SMTP; 23 Jun 2004 20:17:11 +0200
X-Authenticated: #1915285
Message-ID: <40D9C918.90106@gmx.de>
Date: Wed, 23 Jun 2004 20:16:56 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <p06110400bcff69319c50@[129.46.227.161]>
In-Reply-To: <p06110400bcff69319c50@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9C918.90106@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8625
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623181745.F0EDCA1322@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 14:17:45 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:
> 
> At 10:53 PM -0400 6/22/04, Joe Hildebrand wrote:
> 
>>
>> 1.1
>>  - 'DAV:' is a namespace URI, not a namespace name.
> 
> 
> I think it might be more accurate to say that dav: is a URI
> scheme.  See http://www.iana.org/assignments/uri-schemes.
> So the following statement in 1.1: "all XML elements defined by this
> specification use the XML namespace name "DAV:" might be
> re-written as "The XML namespaces used in this document all
> use the DAV: uri scheme".
> 
> Just my personal opinion,
>             regards,
>                 Ted Hardie

Ted,

as a matter of fact, "DAV:" isn't a URI at all (as RFC2396 doesn't allow 
empty scheme-specific parts). Only RFC2396bis will actually make "DAV:" 
a legal URI.

You're proposed change however is inaccurate -- the specification itself 
  uses a single namespace, and that namespace has the name "DAV:". So I 
think there's really nothing that needs to change.

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Wed Jun 23 14:24:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28409
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 14:24:27 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B0491A497D; Wed, 23 Jun 2004 14:24:28 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3270AA497D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 14:24:25 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdCQ5-0000BF-4W
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 14:24:25 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NINn1i006319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Jun 2004 11:23:49 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NINj0D017956;
	Wed, 23 Jun 2004 11:23:46 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110404bcff7a90ae7c@[129.46.227.161]>
In-Reply-To: <40D9C918.90106@gmx.de>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
 <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de>
Date: Wed, 23 Jun 2004 11:23:44 -0700
To: Julian Reschke <julian.reschke@gmx.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/p06110404bcff7a90ae7c@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8626
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623182428.B0491A497D@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 14:24:28 -0400 (EDT)


Julian,
	I didn't say "dav:" was a URI, I said it was a URI
_scheme_; see the URI scheme assignments maintained by
IANA I referenced below.  The namespaces used in the bind
draft fall into the DAV: uri scheme if you require
they begin "dav:".
			regards,
				Ted Hardie


At 8:16 PM +0200 6/23/04, Julian Reschke wrote:
>Ted Hardie wrote:
>>
>>At 10:53 PM -0400 6/22/04, Joe Hildebrand wrote:
>>
>>>
>>>1.1
>>>  - 'DAV:' is a namespace URI, not a namespace name.
>>
>>
>>I think it might be more accurate to say that dav: is a URI
>>scheme.  See http://www.iana.org/assignments/uri-schemes.
>>So the following statement in 1.1: "all XML elements defined by this
>>specification use the XML namespace name "DAV:" might be
>>re-written as "The XML namespaces used in this document all
>>use the DAV: uri scheme".
>>
>>Just my personal opinion,
>>             regards,
>>                 Ted Hardie
>
>Ted,
>
>as a matter of fact, "DAV:" isn't a URI at all (as RFC2396 doesn't 
>allow empty scheme-specific parts). Only RFC2396bis will actually 
>make "DAV:" a legal URI.
>
>You're proposed change however is inaccurate -- the specification 
>itself  uses a single namespace, and that namespace has the name 
>"DAV:". So I think there's really nothing that needs to change.
>
>Best regards, Julian
>
>
>--
><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 23 14:28:13 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29450
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 14:28:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7BB04A49B8; Wed, 23 Jun 2004 14:28:14 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E35B8A49B8
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 14:28:11 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdCTj-00010x-R7
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 14:28:12 -0400
Received: (qmail 27888 invoked by uid 65534); 23 Jun 2004 18:27:40 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp019) with SMTP; 23 Jun 2004 20:27:40 +0200
X-Authenticated: #1915285
Message-ID: <40D9CB98.1090400@gmx.de>
Date: Wed, 23 Jun 2004 20:27:36 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com>
In-Reply-To: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9CB98.1090400@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8627
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623182814.7BB04A49B8@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 14:28:14 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> 
> Yes, we can simplify that.  In particular, I would just move
> the second sentence of the last paragraph to the end of the second 
> paragraph,
> and then delete the rest of the last paragraph.  

OK, here's the section after the simplification:


2.5  MOVE and Bindings

    When MOVE is applied to a resource, the other bindings to that
    resource MUST be unaffected, and if the resource being moved is a
    collection, the bindings to any members of that collection MUST be
    unaffected.  Also, if MOVE is used with Overwrite:T to delete an
    existing resource, the constraints specified for DELETE apply.

    If the destination collection of a MOVE request supports the REBIND
    method (see Section 6), a MOVE of a resource into that collection MAY
    be implemented as a REBIND request.  Although [RFC2518] allows a MOVE
    to be a non-atomic operation, when the MOVE operation is implemented
    as a REBIND, the operation is atomic.  In particular, applying a MOVE
    to a Request-URI and a Destination URI has the effect of removing a
    binding to a resource (at the Request-URI), and creating a new
    binding to that resource (at the Destination URI).

    As an example, suppose that a MOVE is issued to URI-3 for resource R
    below (which is also mapped to URI-1 and URI-2), with the Destination
    header set to URI-X.  After successful completion of the MOVE
    operation, a new binding has been created which creates the URI
    mapping between URI-X and resource R.  The binding corresponding to
    the final segment of URI-3 has been removed, which also causes the
    URI mapping between URI-3 and R to be removed.  If resource R were a
    collection, old URI-3 based mappings to members of R would have been
    removed, and new URI-X based mappings to members of R would have been
    created.  Even when the Request-URI identifies a collection, the MOVE
    operation involves only removing one binding to that collection and
    adding another.

    >> Before Request:

     URI-1   URI-2    URI-3
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

    >> After Request:

     URI-1   URI-2    URI-X
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+




Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 14:31:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00321
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 14:31:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B1021A1213; Wed, 23 Jun 2004 14:31:57 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9A9ADA1213
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 14:31:54 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdCXK-00026u-8P
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 14:31:54 -0400
Received: (qmail 4845 invoked by uid 65534); 23 Jun 2004 18:31:22 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp025) with SMTP; 23 Jun 2004 20:31:22 +0200
X-Authenticated: #1915285
Message-ID: <40D9CC77.2080102@gmx.de>
Date: Wed, 23 Jun 2004 20:31:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de> <p06110404bcff7a90ae7c@[129.46.227.161]>
In-Reply-To: <p06110404bcff7a90ae7c@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9CC77.2080102@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8628
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623183157.B1021A1213@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 14:31:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> Julian,
>     I didn't say "dav:" was a URI, I said it was a URI

I know you didn't say that. I just wanted to point out, that, in order 
to be a legal namespace name, "DAV:" would *need* to be a legal URI. 
Unfortunately it isn't.

> _scheme_; see the URI scheme assignments maintained by
> IANA I referenced below.  The namespaces used in the bind
> draft fall into the DAV: uri scheme if you require
> they begin "dav:".

But the BIND spec isn't defining any new namespaces, and the only XML 
namespace is uses is just the one named "DAV:" (defined in RFC2518).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 15:38:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09908
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 15:38:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C92B8A0740; Wed, 23 Jun 2004 15:38:00 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BB47DA0755
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 15:37:55 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdDZD-0005SO-Fi
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 15:37:55 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NJbF1i012113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Jun 2004 12:37:15 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NJbCo4027929;
	Wed, 23 Jun 2004 12:37:13 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110406bcff8b569cf0@[129.46.227.161]>
In-Reply-To: <40D9CC77.2080102@gmx.de>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
 <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de>
 <p06110404bcff7a90ae7c@[129.46.227.161]> <40D9CC77.2080102@gmx.de>
Date: Wed, 23 Jun 2004 12:37:11 -0700
To: Julian Reschke <julian.reschke@gmx.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/p06110406bcff8b569cf0@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8629
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623193800.C92B8A0740@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 15:38:00 -0400 (EDT)


At 8:31 PM +0200 6/23/04, Julian Reschke wrote:
>Ted Hardie wrote:
>
>>Julian,
>>     I didn't say "dav:" was a URI, I said it was a URI
>
>I know you didn't say that. I just wanted to point out, that, in 
>order to be a legal namespace name, "DAV:" would *need* to be a 
>legal URI. Unfortunately it isn't.

That's not my reading of http://www.w3.org/TR/1999/REC-xml-names-19990114;
you seem to believe that a URI reference used as namespace cannot be the
bare scheme.  The "qualified names" discussion seems to contradict this
view, at least in my reading.

			regards,
				Ted Hardie



From w3c-dist-auth-request@w3.org  Wed Jun 23 15:42:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10263
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 15:42:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D04E6A076D; Wed, 23 Jun 2004 15:42:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 757A3A076D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 15:42:25 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdDdZ-0006Kx-4q
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 15:42:25 -0400
Received: (qmail 21929 invoked by uid 65534); 23 Jun 2004 19:41:53 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp011) with SMTP; 23 Jun 2004 21:41:53 +0200
X-Authenticated: #1915285
Message-ID: <40D9DCFC.9030104@gmx.de>
Date: Wed, 23 Jun 2004 21:41:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de> <p06110404bcff7a90ae7c@[129.46.227.161]> <40D9CC77.2080102@gmx.de> <p06110406bcff8b569cf0@[129.46.227.161]>
In-Reply-To: <p06110406bcff8b569cf0@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9DCFC.9030104@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8630
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623194230.D04E6A076D@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 15:42:30 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> That's not my reading of http://www.w3.org/TR/1999/REC-xml-names-19990114;
> you seem to believe that a URI reference used as namespace cannot be the
> bare scheme.  The "qualified names" discussion seems to contradict this
> view, at least in my reading.

"DAV:" isn't a RFC2396-compliant URI reference either, because it starts 
with a scheme name.

This issue has been discussed extensively in autumn 2002, the result 
being that RFC2396bis will change the grammar to allow empty scheme 
names, thus (finally) making "DAV:" a valid URI and thus a legal 
namespace name.

See: 
<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html#014-empty-opaque_part>

Best regards,

Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 15:45:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10522
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 15:45:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 507B2A0929; Wed, 23 Jun 2004 15:45:53 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 26AE8A0929
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 15:45:51 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdDgs-0006pe-TR
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 15:45:51 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5NJhTJL019932
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 23 Jun 2004 12:43:35 -0700
In-Reply-To: <40D9CB98.1090400@gmx.de>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 23 Jun 2004 12:44:27 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8631
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623194553.507B2A0929@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 15:45:53 -0400 (EDT)
Content-Transfer-Encoding: 7bit


This has a little problem with terminology:

>    If the destination collection of a MOVE request supports the REBIND
>    method (see Section 6), a MOVE of a resource into that collection 
> MAY
>    be implemented as a REBIND request.

The "destination collection" seems here to refer to the collection 
named in the Request-URI, not the collection named in the Destination 
header.  Since destination collection is ambiguous, this could be the 
"target collection", the "collection named in the Request-URI", or "the 
collection named in the Destination header".  Those aren't all the same 
thing obviously.

The rest is a good addition to the spec.

thanks,
Lisa


> Although [RFC2518] allows a MOVE
>    to be a non-atomic operation, when the MOVE operation is implemented
>    as a REBIND, the operation is atomic.  In particular, applying a 
> MOVE
>    to a Request-URI and a Destination URI has the effect of removing a
>    binding to a resource (at the Request-URI), and creating a new
>    binding to that resource (at the Destination URI).
>
>    As an example, suppose that a MOVE is issued to URI-3 for resource R
>    below (which is also mapped to URI-1 and URI-2), with the 
> Destination
>    header set to URI-X.  After successful completion of the MOVE
>    operation, a new binding has been created which creates the URI
>    mapping between URI-X and resource R.  The binding corresponding to
>    the final segment of URI-3 has been removed, which also causes the
>    URI mapping between URI-3 and R to be removed.  If resource R were a
>    collection, old URI-3 based mappings to members of R would have been
>    removed, and new URI-X based mappings to members of R would have 
> been
>    created.  Even when the Request-URI identifies a collection, the 
> MOVE
>    operation involves only removing one binding to that collection and
>    adding another.
>
>    >> Before Request:
>
>     URI-1   URI-2    URI-3
>       |       |        |
>       |       |        |      <---- URI Mappings
>       |       |        |
>    +---------------------+
>    |     Resource R      |
>    +---------------------+
>
>    >> After Request:
>
>     URI-1   URI-2    URI-X
>       |       |        |
>       |       |        |      <---- URI Mappings
>       |       |        |
>    +---------------------+
>    |     Resource R      |
>    +---------------------+
>
>
>
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Jun 23 15:58:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11629
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 15:58:19 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 57D6BA0C58; Wed, 23 Jun 2004 15:58:20 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2F3ABA053C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 15:58:17 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdDsu-0000Cv-Ug
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 15:58:17 -0400
Received: (qmail 7298 invoked by uid 65534); 23 Jun 2004 19:57:44 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp004) with SMTP; 23 Jun 2004 21:57:44 +0200
X-Authenticated: #1915285
Message-ID: <40D9E0B4.3060401@gmx.de>
Date: Wed, 23 Jun 2004 21:57:40 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org>
In-Reply-To: <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9E0B4.3060401@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8632
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623195820.57D6BA0C58@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 15:58:20 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> This has a little problem with terminology:
> 
>>    If the destination collection of a MOVE request supports the REBIND
>>    method (see Section 6), a MOVE of a resource into that collection MAY
>>    be implemented as a REBIND request.
> 
> 
> The "destination collection" seems here to refer to the collection named 
> in the Request-URI, not the collection named in the Destination header.  

Can't follow. When talking about a MOVE request, why would you ever 
understand "destination collection" as the thing identified by the 
Reuqest-URI (which is clearly the source), not the thing identified by 
the "Destination" header?

Please explain.

> ...

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 16:05:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12105
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 16:05:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 66F0DA07AA; Wed, 23 Jun 2004 16:05:03 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 998C4A07AA
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 16:04:58 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdDzO-0001To-ER
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 16:04:58 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NK4C1i014679
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Jun 2004 13:04:13 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5NK47Bl011662;
	Wed, 23 Jun 2004 13:04:08 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110407bcff90aadc76@[129.46.227.161]>
In-Reply-To: <40D9DCFC.9030104@gmx.de>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net>
 <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de>
 <p06110404bcff7a90ae7c@[129.46.227.161]> <40D9CC77.2080102@gmx.de>
 <p06110406bcff8b569cf0@[129.46.227.161]> <40D9DCFC.9030104@gmx.de>
Date: Wed, 23 Jun 2004 13:04:06 -0700
To: Julian Reschke <julian.reschke@gmx.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/p06110407bcff90aadc76@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8633
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623200503.66F0DA07AA@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 16:05:03 -0400 (EDT)


At 9:41 PM +0200 6/23/04, Julian Reschke wrote:
>Ted Hardie wrote:
>
>>That's not my reading of http://www.w3.org/TR/1999/REC-xml-names-19990114;
>>you seem to believe that a URI reference used as namespace cannot be the
>>bare scheme.  The "qualified names" discussion seems to contradict this
>>view, at least in my reading.
>
>"DAV:" isn't a RFC2396-compliant URI reference either, because it 
>starts with a scheme name.

I think you're mistaking an ABNF change between 2396 and 2396bis for
an architectural point.  If you go back to 1738, the predecessor to 2396,
the schemepart's inclusion of *xchar clearly allows zero according
to the rules of the BNF syntax it references from 822 (see 2.4 in
RFC 822).
			regards,
				Ted Hardie



From w3c-dist-auth-request@w3.org  Wed Jun 23 16:10:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12625
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 16:10:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BC0A6A2FFC; Wed, 23 Jun 2004 16:10:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 0FB7DA2FFC
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 16:10:45 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdE4y-00024L-Tu
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 16:10:45 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5NK8xJL025464
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 23 Jun 2004 13:09:02 -0700
In-Reply-To: <40D9E0B4.3060401@gmx.de>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9E0B4.3060401@gmx.de>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 23 Jun 2004 13:09:58 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8634
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623201052.BC0A6A2FFC@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 16:10:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Because the sentence talked only about one collection supporting 
REBIND, and I would think that the most important collection to support 
REBIND in this case would be the source collection.  I think that was a 
reasonable and careful read of the text.

Perhaps my assumption would not have held up if the sentence had said 
"if the destination collection and the source resource of a MOVE 
request both support the REBIND method ..." etc.

Lisa

On Jun 23, 2004, at 12:57 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> This has a little problem with terminology:
>>>    If the destination collection of a MOVE request supports the 
>>> REBIND
>>>    method (see Section 6), a MOVE of a resource into that collection 
>>> MAY
>>>    be implemented as a REBIND request.
>> The "destination collection" seems here to refer to the collection 
>> named in the Request-URI, not the collection named in the Destination 
>> header.
>
> Can't follow. When talking about a MOVE request, why would you ever 
> understand "destination collection" as the thing identified by the 
> Reuqest-URI (which is clearly the source), not the thing identified by 
> the "Destination" header?
>
> Please explain.
>
>> ...
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 23 16:18:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13238
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 16:18:32 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 94559A1864; Wed, 23 Jun 2004 16:18:34 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3477FA1868
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 16:18:29 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdECT-0003Xy-1x
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 16:18:29 -0400
Received: (qmail 23215 invoked by uid 65534); 23 Jun 2004 20:17:57 -0000
Received: from pD9E51EF9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.249)
  by mail.gmx.net (mp010) with SMTP; 23 Jun 2004 22:17:57 +0200
X-Authenticated: #1915285
Message-ID: <40D9E56C.6080704@gmx.de>
Date: Wed, 23 Jun 2004 22:17:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Joe Hildebrand <joe@cursive.net>, w3c-dist-auth@w3.org
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <p06110400bcff69319c50@[129.46.227.161]> <40D9C918.90106@gmx.de> <p06110404bcff7a90ae7c@[129.46.227.161]> <40D9CC77.2080102@gmx.de> <p06110406bcff8b569cf0@[129.46.227.161]> <40D9DCFC.9030104@gmx.de> <p06110407bcff90aadc76@[129.46.227.161]>
In-Reply-To: <p06110407bcff90aadc76@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9E56C.6080704@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8635
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623201834.94559A1864@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 16:18:34 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> I think you're mistaking an ABNF change between 2396 and 2396bis for
> an architectural point.  If you go back to 1738, the predecessor to 2396,
> the schemepart's inclusion of *xchar clearly allows zero according
> to the rules of the BNF syntax it references from 822 (see 2.4 in
> RFC 822).

Ted,

I was only mentioning that in 2001 (not 2002 as I realized) we found 
that the bare string "DAV:" isn't a legal URI according to RFC2396. This 
was discussed with Roy Fielding, and as a consequence RFC2396bis changes 
this.

Anyway, this is really not relevant for BIND. BIND doesn't define any 
new namespaces in the "DAV:" scheme, it just puts more elements into the 
  XML namespace named "DAV:", which is already defined in RFC2518. Thus 
there's IMHO nothing that needs to change in BIND.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 16:43:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15836
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 16:43:41 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 70809A0FC8; Wed, 23 Jun 2004 16:43:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 70849A0FC8
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 16:43:40 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdEaq-0000dG-4c
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 16:43:40 -0400
Received: (qmail 24635 invoked by uid 65534); 23 Jun 2004 20:43:07 -0000
Received: from pD9FF0934.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.9.52)
  by mail.gmx.net (mp014) with SMTP; 23 Jun 2004 22:43:07 +0200
X-Authenticated: #1915285
Message-ID: <40D9EB56.1020008@gmx.de>
Date: Wed, 23 Jun 2004 22:43:02 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9E0B4.3060401@gmx.de> <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org>
In-Reply-To: <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40D9EB56.1020008@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8636
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623204343.70809A0FC8@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 16:43:43 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Because the sentence talked only about one collection supporting REBIND, 
> and I would think that the most important collection to support REBIND 
> in this case would be the source collection.  I think that was a 
> reasonable and careful read of the text.

Well, no:

"If the destination collection of a MOVE request supports the REBIND 
method (see Section 6), a MOVE of a resource into that collection MAY be 
implemented as a REBIND request."

The text clearly talks about the destination collection, and as far as I 
can tell, it's doing that on purpose.

> Perhaps my assumption would not have held up if the sentence had said 
> "if the destination collection and the source resource of a MOVE request 
> both support the REBIND method ..." etc.

The source resource doesn't need to support REBIND - REBIND is a method 
where the Request-URI is the target collection into which the new 
binding is added.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 17:03:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17808
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 17:03:29 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9D8FCA4A4D; Wed, 23 Jun 2004 17:03:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 24863A4A4D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 17:03:27 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdEty-0004Pb-UZ
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 17:03:27 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5NL1vJL029176
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 23 Jun 2004 14:01:59 -0700
In-Reply-To: <40D9EB56.1020008@gmx.de>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9E0B4.3060401@gmx.de> <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9EB56.1020008@gmx.de>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B136DF12-C558-11D8-B2D4-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 23 Jun 2004 14:02:52 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/B136DF12-C558-11D8-B2D4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8637
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623210330.9D8FCA4A4D@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 17:03:30 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Well, I certainly read it wrong although I read it carefully, because I 
forgot that REBIND is defined differently than MOVE so that the 
Request-URI is the target collection.  And it's not obvious to me that 
the source collection doesn't need to implement REBIND for this to 
work.  But if everybody else who reads the spec is clear on this, then 
I'll write it off as an anomaly.

Lisa

On Jun 23, 2004, at 1:43 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> Because the sentence talked only about one collection supporting 
>> REBIND, and I would think that the most important collection to 
>> support REBIND in this case would be the source collection.  I think 
>> that was a reasonable and careful read of the text.
>
> Well, no:
>
> "If the destination collection of a MOVE request supports the REBIND 
> method (see Section 6), a MOVE of a resource into that collection MAY 
> be implemented as a REBIND request."
>
> The text clearly talks about the destination collection, and as far as 
> I can tell, it's doing that on purpose.
>
>> Perhaps my assumption would not have held up if the sentence had said 
>> "if the destination collection and the source resource of a MOVE 
>> request both support the REBIND method ..." etc.
>
> The source resource doesn't need to support REBIND - REBIND is a 
> method where the Request-URI is the target collection into which the 
> new binding is added.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 23 18:14:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23254
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 18:14:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B3F7FA4AC6; Wed, 23 Jun 2004 18:14:22 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 463C9A4AC6
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 18:14:19 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdG0Y-0006Bo-Tt
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 18:14:19 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5NMDmgA875914
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 18:13:48 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NMEaJk119776
	for <w3c-dist-auth@w3.org>; Wed, 23 Jun 2004 18:14:36 -0400
In-Reply-To: <40D9CB98.1090400@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF73FA765A.B0A2F47D-ON85256EBC.00666007-85256EBC.007A1C4A@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 18:13:13 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 18:13:13,
	Serialize complete at 06/23/2004 18:13:13
Content-Type: multipart/alternative; boundary="=_alternative 007A1C3A85256EBC_="
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/OF73FA765A.B0A2F47D-ON85256EBC.00666007-85256EBC.007A1C4A@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8638
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623221422.B3F7FA4AC6@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 18:14:22 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 007A1C3A85256EBC_=
Content-Type: text/plain; charset="US-ASCII"

I noticed that you moved the sentence to the end of the third
paragraph instead of to the end of the second paragraph.
I'd prefer it to be at the end of the second paragraph, but
either way is OK.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 06/23/2004 02:27:36 PM:

> Geoffrey M Clemm wrote:
> 
> > 
> > Yes, we can simplify that.  In particular, I would just move
> > the second sentence of the last paragraph to the end of the second 
> > paragraph,
> > and then delete the rest of the last paragraph. 
> 
> OK, here's the section after the simplification:
> 
> 
> 2.5  MOVE and Bindings
> 
>     When MOVE is applied to a resource, the other bindings to that
>     resource MUST be unaffected, and if the resource being moved is a
>     collection, the bindings to any members of that collection MUST be
>     unaffected.  Also, if MOVE is used with Overwrite:T to delete an
>     existing resource, the constraints specified for DELETE apply.
> 
>     If the destination collection of a MOVE request supports the REBIND
>     method (see Section 6), a MOVE of a resource into that collection 
MAY
>     be implemented as a REBIND request.  Although [RFC2518] allows a 
MOVE
>     to be a non-atomic operation, when the MOVE operation is implemented
>     as a REBIND, the operation is atomic.  In particular, applying a 
MOVE
>     to a Request-URI and a Destination URI has the effect of removing a
>     binding to a resource (at the Request-URI), and creating a new
>     binding to that resource (at the Destination URI).
> 
>     As an example, suppose that a MOVE is issued to URI-3 for resource R
>     below (which is also mapped to URI-1 and URI-2), with the 
Destination
>     header set to URI-X.  After successful completion of the MOVE
>     operation, a new binding has been created which creates the URI
>     mapping between URI-X and resource R.  The binding corresponding to
>     the final segment of URI-3 has been removed, which also causes the
>     URI mapping between URI-3 and R to be removed.  If resource R were a
>     collection, old URI-3 based mappings to members of R would have been
>     removed, and new URI-X based mappings to members of R would have 
been
>     created.  Even when the Request-URI identifies a collection, the 
MOVE
>     operation involves only removing one binding to that collection and
>     adding another.
> 
>     >> Before Request:
> 
>      URI-1   URI-2    URI-3
>        |       |        |
>        |       |        |      <---- URI Mappings
>        |       |        |
>     +---------------------+
>     |     Resource R      |
>     +---------------------+
> 
>     >> After Request:
> 
>      URI-1   URI-2    URI-X
>        |       |        |
>        |       |        |      <---- URI Mappings
>        |       |        |
>     +---------------------+
>     |     Resource R      |
>     +---------------------+
> 
> 
> 
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

--=_alternative 007A1C3A85256EBC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I noticed that you moved the sentence to the end of
the third</tt></font>
<br><font size=2><tt>paragraph instead of to the end of the second paragraph.</tt></font>
<br><font size=2><tt>I'd prefer it to be at the end of the second paragraph,
but</tt></font>
<br><font size=2><tt>either way is OK.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote
on 06/23/2004 02:27:36 PM:<br>
<br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; <br>
&gt; &gt; <br>
&gt; &gt; Yes, we can simplify that. &nbsp;In particular, I would just
move<br>
&gt; &gt; the second sentence of the last paragraph to the end of the second
<br>
&gt; &gt; paragraph,<br>
&gt; &gt; and then delete the rest of the last paragraph. &nbsp;<br>
&gt; <br>
&gt; OK, here's the section after the simplification:<br>
&gt; <br>
&gt; <br>
&gt; 2.5 &nbsp;MOVE and Bindings<br>
&gt; <br>
&gt; &nbsp; &nbsp; When MOVE is applied to a resource, the other bindings
to that<br>
&gt; &nbsp; &nbsp; resource MUST be unaffected, and if the resource being
moved is a<br>
&gt; &nbsp; &nbsp; collection, the bindings to any members of that collection
MUST be<br>
&gt; &nbsp; &nbsp; unaffected. &nbsp;Also, if MOVE is used with Overwrite:T
to delete an<br>
&gt; &nbsp; &nbsp; existing resource, the constraints specified for DELETE
apply.<br>
&gt; <br>
&gt; &nbsp; &nbsp; If the destination collection of a MOVE request supports
the REBIND<br>
&gt; &nbsp; &nbsp; method (see Section 6), a MOVE of a resource into that
collection MAY<br>
&gt; &nbsp; &nbsp; be implemented as a REBIND request. &nbsp;Although [RFC2518]
allows a MOVE<br>
&gt; &nbsp; &nbsp; to be a non-atomic operation, when the MOVE operation
is implemented<br>
&gt; &nbsp; &nbsp; as a REBIND, the operation is atomic. &nbsp;In particular,
applying a MOVE<br>
&gt; &nbsp; &nbsp; to a Request-URI and a Destination URI has the effect
of removing a<br>
&gt; &nbsp; &nbsp; binding to a resource (at the Request-URI), and creating
a new<br>
&gt; &nbsp; &nbsp; binding to that resource (at the Destination URI).<br>
&gt; <br>
&gt; &nbsp; &nbsp; As an example, suppose that a MOVE is issued to URI-3
for resource R<br>
&gt; &nbsp; &nbsp; below (which is also mapped to URI-1 and URI-2), with
the Destination<br>
&gt; &nbsp; &nbsp; header set to URI-X. &nbsp;After successful completion
of the MOVE<br>
&gt; &nbsp; &nbsp; operation, a new binding has been created which creates
the URI<br>
&gt; &nbsp; &nbsp; mapping between URI-X and resource R. &nbsp;The binding
corresponding to<br>
&gt; &nbsp; &nbsp; the final segment of URI-3 has been removed, which also
causes the<br>
&gt; &nbsp; &nbsp; URI mapping between URI-3 and R to be removed. &nbsp;If
resource R were a<br>
&gt; &nbsp; &nbsp; collection, old URI-3 based mappings to members of R
would have been<br>
&gt; &nbsp; &nbsp; removed, and new URI-X based mappings to members of
R would have been<br>
&gt; &nbsp; &nbsp; created. &nbsp;Even when the Request-URI identifies
a collection, the MOVE<br>
&gt; &nbsp; &nbsp; operation involves only removing one binding to that
collection and<br>
&gt; &nbsp; &nbsp; adding another.<br>
&gt; <br>
&gt; &nbsp; &nbsp; &gt;&gt; Before Request:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp;URI-1 &nbsp; URI-2 &nbsp; &nbsp;URI-3<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;&lt;---- URI Mappings<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; +---------------------+<br>
&gt; &nbsp; &nbsp; | &nbsp; &nbsp; Resource R &nbsp; &nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; +---------------------+<br>
&gt; <br>
&gt; &nbsp; &nbsp; &gt;&gt; After Request:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp;URI-1 &nbsp; URI-2 &nbsp; &nbsp;URI-X<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;&lt;---- URI Mappings<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; +---------------------+<br>
&gt; &nbsp; &nbsp; | &nbsp; &nbsp; Resource R &nbsp; &nbsp; &nbsp;|<br>
&gt; &nbsp; &nbsp; +---------------------+<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Best regards, Julian<br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
</tt></font>
--=_alternative 007A1C3A85256EBC_=--



From w3c-dist-auth-request@w3.org  Wed Jun 23 18:20:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24075
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 18:20:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 845E3A4B0C; Wed, 23 Jun 2004 18:20:29 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EC2ACA4B0C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 18:20:23 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdG6R-0007Ni-Rz
	for w3c-dist-auth@w3.org; Wed, 23 Jun 2004 18:20:24 -0400
Received: (qmail 17345 invoked by uid 65534); 23 Jun 2004 22:19:52 -0000
Received: from pD9FF0934.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.9.52)
  by mail.gmx.net (mp026) with SMTP; 24 Jun 2004 00:19:52 +0200
X-Authenticated: #1915285
Message-ID: <40DA0202.3050704@gmx.de>
Date: Thu, 24 Jun 2004 00:19:46 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF73FA765A.B0A2F47D-ON85256EBC.00666007-85256EBC.007A1C4A@us.ibm.com>
In-Reply-To: <OF73FA765A.B0A2F47D-ON85256EBC.00666007-85256EBC.007A1C4A@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40DA0202.3050704@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8639
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040623222029.845E3A4B0C@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 18:20:29 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> 
> I noticed that you moved the sentence to the end of the third
> paragraph instead of to the end of the second paragraph.
> I'd prefer it to be at the end of the second paragraph, but
> either way is OK.

That makes more sense -- thanks for checking. New text below:

2.5  MOVE and Bindings

    When MOVE is applied to a resource, the other bindings to that
    resource MUST be unaffected, and if the resource being moved is a
    collection, the bindings to any members of that collection MUST be
    unaffected.  Also, if MOVE is used with Overwrite:T to delete an
    existing resource, the constraints specified for DELETE apply.

    If the destination collection of a MOVE request supports the REBIND
    method (see Section 6), a MOVE of a resource into that collection MAY
    be implemented as a REBIND request.  Although [RFC2518] allows a MOVE
    to be a non-atomic operation, when the MOVE operation is implemented
    as a REBIND, the operation is atomic.  In particular, applying a MOVE
    to a Request-URI and a Destination URI has the effect of removing a
    binding to a resource (at the Request-URI), and creating a new
    binding to that resource (at the Destination URI).  Even when the
    Request-URI identifies a collection, the MOVE operation involves only
    removing one binding to that collection and adding another.

    As an example, suppose that a MOVE is issued to URI-3 for resource R
    below (which is also mapped to URI-1 and URI-2), with the Destination
    header set to URI-X.  After successful completion of the MOVE
    operation, a new binding has been created which creates the URI
    mapping between URI-X and resource R.  The binding corresponding to
    the final segment of URI-3 has been removed, which also causes the
    URI mapping between URI-3 and R to be removed.  If resource R were a
    collection, old URI-3 based mappings to members of R would have been
    removed, and new URI-X based mappings to members of R would have been
    created.

    >> Before Request:

     URI-1   URI-2    URI-3
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

    >> After Request:

     URI-1   URI-2    URI-X
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+


Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 23 22:39:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09649
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 22:39:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 010B6A4C81; Wed, 23 Jun 2004 22:39:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8F393A4C81
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 22:39:10 -0400 (EDT)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdK8q-00084K-97
	for w3c-dist-auth@w3c.org; Wed, 23 Jun 2004 22:39:08 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5O2cZkw672562
	for <w3c-dist-auth@w3c.org>; Wed, 23 Jun 2004 22:38:35 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5O2dh0r113944
	for <w3c-dist-auth@w3c.org>; Wed, 23 Jun 2004 22:39:44 -0400
In-Reply-To: <40D345F8.9050106@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFC511F636.FAFB8B15-ON85256EBD.000E5AC4-85256EBD.000E8474@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 22:38:00 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 22:38:01,
	Serialize complete at 06/23/2004 22:38:01
Content-Type: multipart/alternative; boundary="=_alternative 000E847285256EBD_="
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/OFC511F636.FAFB8B15-ON85256EBD.000E5AC4-85256EBD.000E8474@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8640
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624023913.010B6A4C81@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 22:39:13 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 000E847285256EBD_=
Content-Type: text/plain; charset="US-ASCII"

This precondition sounds fine to me.

I wouldn't say it applies to all methods though; only methods that
modify state on the server (e.g., not PROPFIND or the various
REPORT's).

Cheers,
Geoff

Julian wrote on 06/18/2004 03:43:52 PM:

> So I'd recommend that we define a new precondition (applying to *all* 
> methods) specifically for use in this case, that also will contain the 
> URI of the resource causing the failure inside a <href> element, similar 

> to <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1> 
> (where the same situation occurs for missing privileges).
> 
> For instance:
> 
> (DAV:need-submitted-lock-token): If a request would modify the content 
> for a locked resource, a dead property of a locked resource, a live 
> property that is defined to be lockable for a locked resource, or an 
> internal member URI of a locked collection, the request MUST fail unless 

> the lock-token for that lock is submitted in the request. An internal 
> member URI of a collection is considered to be modified if it is added, 
> removed, or identifies a different resource.
> 
> <!ELEMENT need-submitted-lock-token (href)* >
> 
> (the text is taken from one of the GULP rules, see 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.C.6>).
> 
> Feedback appreciated,

--=_alternative 000E847285256EBD_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>This precondition sounds fine to me.</tt></font>
<br>
<br><font size=2><tt>I wouldn't say it applies to all methods though; only
methods that</tt></font>
<br><font size=2><tt>modify state on the server (e.g., not PROPFIND or
the various</tt></font>
<br><font size=2><tt>REPORT's).</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/18/2004 03:43:52 PM:<br>
<br>
&gt; So I'd recommend that we define a new precondition (applying to *all*
<br>
&gt; methods) specifically for use in this case, that also will contain
the <br>
&gt; URI of the resource causing the failure inside a &lt;href&gt; element,
similar <br>
&gt; to &lt;http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1&gt;
<br>
&gt; (where the same situation occurs for missing privileges).<br>
&gt; <br>
&gt; For instance:<br>
&gt; <br>
&gt; (DAV:need-submitted-lock-token): If a request would modify the content
<br>
&gt; for a locked resource, a dead property of a locked resource, a live
<br>
&gt; property that is defined to be lockable for a locked resource, or
an <br>
&gt; internal member URI of a locked collection, the request MUST fail
unless <br>
&gt; the lock-token for that lock is submitted in the request. An internal
<br>
&gt; member URI of a collection is considered to be modified if it is added,
<br>
&gt; removed, or identifies a different resource.<br>
&gt; <br>
&gt; &lt;!ELEMENT need-submitted-lock-token (href)* &gt;<br>
&gt; <br>
&gt; (the text is taken from one of the GULP rules, see <br>
&gt; &lt;http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-<br>
&gt; latest.html#rfc.section.C.6&gt;).<br>
&gt; <br>
&gt; Feedback appreciated,<br>
</tt></font>
--=_alternative 000E847285256EBD_=--



From w3c-dist-auth-request@w3.org  Wed Jun 23 22:42:40 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10162
	for <webdav-archive@lists.ietf.org>; Wed, 23 Jun 2004 22:42:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CA456A4CBD; Wed, 23 Jun 2004 22:42:41 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 280B4A4CBD
	for <w3c-dist-auth@listhub.w3.org>; Wed, 23 Jun 2004 22:42:39 -0400 (EDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdKCE-0000BN-3k
	for w3c-dist-auth@w3c.org; Wed, 23 Jun 2004 22:42:38 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5O2g7ws600390
	for <w3c-dist-auth@w3c.org>; Wed, 23 Jun 2004 22:42:07 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5O2hF0r095050
	for <w3c-dist-auth@w3c.org>; Wed, 23 Jun 2004 22:43:15 -0400
In-Reply-To: <40D3402F.6000604@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFB4FCE74B.4E887BAD-ON85256EBD.000EB011-85256EBD.000ED704@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 23 Jun 2004 22:41:32 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/23/2004 22:41:32,
	Serialize complete at 06/23/2004 22:41:32
Content-Type: multipart/alternative; boundary="=_alternative 000ED70285256EBD_="
Subject: Re: Issue #66: MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL
X-Archived-At: http://www.w3.org/mid/OFB4FCE74B.4E887BAD-ON85256EBD.000EB011-85256EBD.000ED704@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8641
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624024241.CA456A4CBD@frink.w3.org>
Resent-Date: Wed, 23 Jun 2004 22:42:41 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 000ED70285256EBD_=
Content-Type: text/plain; charset="US-ASCII"

I'm happy either way, but have a slight preference for #2
(BTW, that should read "(thus not interoperable)".

Cheers,
Geoff

Julian wrote on 06/18/2004 03:19:11 PM:

> This leaves us with the following options:
> 
> 1) Just document things as they seem to be implemented (not requiring 
> that the client uses the URI of the lock root),
> 
> 2) Keep our earlier statement -- basically clients MUST submit the lock 
> token with the URL of the lock root; and state that otherwise the 
> behaviour is server-defined (thus interoperable).
> 
> As 2) is what we discussed before, I think I prefer that point of view. 
> However, if people think we should explicitly allow 1), I'll happily 
> document that as well.
> 
> Feedback appreciated,

--=_alternative 000ED70285256EBD_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>I'm happy either way, but have a slight preference
for #2</tt></font>
<br><font size=2><tt>(BTW, that should read &quot;(thus not interoperable)&quot;.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 06/18/2004 03:19:11 PM:<br>
<br>
&gt; This leaves us with the following options:<br>
&gt; <br>
&gt; 1) Just document things as they seem to be implemented (not requiring
<br>
&gt; that the client uses the URI of the lock root),<br>
&gt; <br>
&gt; 2) Keep our earlier statement -- basically clients MUST submit the
lock <br>
&gt; token with the URL of the lock root; and state that otherwise the
<br>
&gt; behaviour is server-defined (thus interoperable).<br>
&gt; <br>
&gt; As 2) is what we discussed before, I think I prefer that point of
view. <br>
&gt; However, if people think we should explicitly allow 1), I'll happily
<br>
&gt; document that as well.<br>
&gt; <br>
&gt; Feedback appreciated,<br>
</tt></font>
--=_alternative 000ED70285256EBD_=--



From w3c-dist-auth-request@w3.org  Thu Jun 24 02:58:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08504
	for <webdav-archive@lists.ietf.org>; Thu, 24 Jun 2004 02:58:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B14BCA0BEB; Thu, 24 Jun 2004 02:58:41 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 434A5A0BEB
	for <w3c-dist-auth@listhub.w3.org>; Thu, 24 Jun 2004 02:58:37 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdOBx-00068V-0k
	for w3c-dist-auth@w3c.org; Thu, 24 Jun 2004 02:58:37 -0400
Received: (qmail 4948 invoked by uid 65534); 24 Jun 2004 06:58:05 -0000
Received: from pD9FF0934.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.9.52)
  by mail.gmx.net (mp020) with SMTP; 24 Jun 2004 08:58:05 +0200
X-Authenticated: #1915285
Message-ID: <40DA7B75.5030403@gmx.de>
Date: Thu, 24 Jun 2004 08:57:57 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <OFC511F636.FAFB8B15-ON85256EBD.000E5AC4-85256EBD.000E8474@us.ibm.com>
In-Reply-To: <OFC511F636.FAFB8B15-ON85256EBD.000E5AC4-85256EBD.000E8474@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/40DA7B75.5030403@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8642
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624065841.B14BCA0BEB@frink.w3.org>
Resent-Date: Thu, 24 Jun 2004 02:58:41 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:
> 
> This precondition sounds fine to me.
> 
> I wouldn't say it applies to all methods though; only methods that
> modify state on the server (e.g., not PROPFIND or the various
> REPORT's).

Right now it starts saying... "If a request would modify the content for 
a locked resource, a dead property of a locked resource, a live 
property that is defined to be lockable for a locked resource, or an 
internal member URI of a locked collection,", thus it *does* apply to 
all methods.

An alternative would be to re-group the conditions; but that would only 
make case if we find more that fall into the same category...

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Jun 24 05:07:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17414
	for <webdav-archive@lists.ietf.org>; Thu, 24 Jun 2004 05:07:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 13429A4D0C; Thu, 24 Jun 2004 05:07:07 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AC7CFA4E3E
	for <w3c-dist-auth@listhub.w3.org>; Thu, 24 Jun 2004 05:06:59 -0400 (EDT)
Received: from [196.12.57.40] (helo=jpmail.jpmil.com)
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdQC7-0002WD-0R
	for w3c-dist-auth@w3c.org; Thu, 24 Jun 2004 05:06:55 -0400
Received: from SainathJ ([196.12.57.41]) by jpmail.jpmil.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 24 Jun 2004 14:37:16 +0530
Message-ID: <020a01c459ca$89c3c170$960510ac@ns.jpsil.com>
From: "Basavaraj" <basavaraj.prabha@jpmil.com>
To: "Lisa Dusseault" <lisa@osafoundation.org>
Cc: <w3c-dist-auth@w3c.org>
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9E0B4.3060401@gmx.de> <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9EB56.1020008@gmx.de> <B136DF12-C558-11D8-B2D4-000A95B2BB72@osafoundation.org>
Date: Thu, 24 Jun 2004 14:36:28 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 24 Jun 2004 09:07:16.0734 (UTC) FILETIME=[A57439E0:01C459CA]
Subject: WebDav
X-Archived-At: http://www.w3.org/mid/020a01c459ca$89c3c170$960510ac@ns.jpsil.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8643
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624090707.13429A4D0C@frink.w3.org>
Resent-Date: Thu, 24 Jun 2004 05:07:07 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi ,
I am Working with WebDav.
I got Struck in Access Tables Fields Through XML
Can you let me know how to access it dynamically.
As of now i have had coded (Sample code Pasted below in color)and making it
work for particular User Only.
Now i want to Dynamically Access Fields from a Table for any user.
        ExUser *userInfo = new ExUser();
        userInfo->Domain = "JPM";// Domain Name
        userInfo->Login = "ikon5"; // User
        userInfo->mailboxId = "ikon5";// Alias to User
        userInfo->mailServer = "JPSERV5";//Exchange Server
        userInfo->Password = "ikon5"; //Password
It would be pleasure if answed.
Thanks in Advance.
-Basavaraj Prabha

----- Original Message ----- 
From: "Lisa Dusseault" <lisa@osafoundation.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3.org>; "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com>
Sent: Thursday, June 24, 2004 2:32 AM
Subject: Re: Issue 2.5_language, was: ID: draft-ietf-webdav-bind-05


>
> Well, I certainly read it wrong although I read it carefully, because I
> forgot that REBIND is defined differently than MOVE so that the
> Request-URI is the target collection.  And it's not obvious to me that
> the source collection doesn't need to implement REBIND for this to
> work.  But if everybody else who reads the spec is clear on this, then
> I'll write it off as an anomaly.
>
> Lisa
>
> On Jun 23, 2004, at 1:43 PM, Julian Reschke wrote:
>
> > Lisa Dusseault wrote:
> >
> >> Because the sentence talked only about one collection supporting
> >> REBIND, and I would think that the most important collection to
> >> support REBIND in this case would be the source collection.  I think
> >> that was a reasonable and careful read of the text.
> >
> > Well, no:
> >
> > "If the destination collection of a MOVE request supports the REBIND
> > method (see Section 6), a MOVE of a resource into that collection MAY
> > be implemented as a REBIND request."
> >
> > The text clearly talks about the destination collection, and as far as
> > I can tell, it's doing that on purpose.
> >
> >> Perhaps my assumption would not have held up if the sentence had said
> >> "if the destination collection and the source resource of a MOVE
> >> request both support the REBIND method ..." etc.
> >
> > The source resource doesn't need to support REBIND - REBIND is a
> > method where the Request-URI is the target collection into which the
> > new binding is added.
> >
> > Best regards, Julian
> >
> > -- 
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Thu Jun 24 05:49:05 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19934
	for <webdav-archive@lists.ietf.org>; Thu, 24 Jun 2004 05:49:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3700FA0CE4; Thu, 24 Jun 2004 05:49:07 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 08713A0D70
	for <w3c-dist-auth@listhub.w3.org>; Thu, 24 Jun 2004 05:49:04 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BdQqt-0000q3-NI
	for w3c-dist-auth@w3c.org; Thu, 24 Jun 2004 05:49:03 -0400
Received: (qmail 22588 invoked by uid 65534); 24 Jun 2004 09:48:31 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.17]) (217.5.201.10)
  by mail.gmx.net (mp026) with SMTP; 24 Jun 2004 11:48:31 +0200
X-Authenticated: #1915285
Message-ID: <40DAA365.2060307@gmx.de>
Date: Thu, 24 Jun 2004 11:48:21 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Basavaraj <basavaraj.prabha@jpmil.com>
Cc: w3c-dist-auth@w3c.org
References: <OFB0539B2A.E27CBE45-ON85256EBC.00603D77-85256EBC.0060A7DF@us.ibm.com> <40D9CB98.1090400@gmx.de> <BCB3B512-C54D-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9E0B4.3060401@gmx.de> <4D463C3A-C551-11D8-B2D4-000A95B2BB72@osafoundation.org> <40D9EB56.1020008@gmx.de> <B136DF12-C558-11D8-B2D4-000A95B2BB72@osafoundation.org> <020a01c459ca$89c3c170$960510ac@ns.jpsil.com>
In-Reply-To: <020a01c459ca$89c3c170$960510ac@ns.jpsil.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: WebDav
X-Archived-At: http://www.w3.org/mid/40DAA365.2060307@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8644
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624094907.3700FA0CE4@frink.w3.org>
Resent-Date: Thu, 24 Jun 2004 05:49:07 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Basavaraj wrote:

> Hi ,
> I am Working with WebDav.
> I got Struck in Access Tables Fields Through XML
> Can you let me know how to access it dynamically.
> As of now i have had coded (Sample code Pasted below in color)and making it
> work for particular User Only.
> Now i want to Dynamically Access Fields from a Table for any user.
>         ExUser *userInfo = new ExUser();
>         userInfo->Domain = "JPM";// Domain Name
>         userInfo->Login = "ikon5"; // User
>         userInfo->mailboxId = "ikon5";// Alias to User
>         userInfo->mailServer = "JPSERV5";//Exchange Server
>         userInfo->Password = "ikon5"; //Password
> It would be pleasure if answed.
> Thanks in Advance.

Hi,

it seems that your question relates to the Exchange API, not WebDAV per 
se. It's unlikely that somebody on this list will be able to help you -- 
you probably should post to a MS-Exchange related mailing list or 
newsgroup instead.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Jun 24 09:24:35 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10718
	for <webdav-archive@lists.ietf.org>; Thu, 24 Jun 2004 09:24:34 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A426FA17E3; Thu, 24 Jun 2004 08:27:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E0FCFA17E3
	for <w3c-dist-auth@listhub.w3.org>; Thu, 24 Jun 2004 08:27:38 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BdTKM-0005X4-W0
	for w3c-dist-auth@w3c.org; Thu, 24 Jun 2004 08:27:39 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5OCR57R348120
	for <w3c-dist-auth@w3c.org>; Thu, 24 Jun 2004 08:27:05 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5OCRriX122828
	for <w3c-dist-auth@w3c.org>; Thu, 24 Jun 2004 08:27:53 -0400
In-Reply-To: <40DA7B75.5030403@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF5712EE22.77227AF7-ON85256EBD.00443E78-85256EBD.004464EE@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 24 Jun 2004 08:26:29 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF333 | June 18, 2004) at
 06/24/2004 08:26:30,
	Serialize complete at 06/24/2004 08:26:30
Content-Type: multipart/alternative; boundary="=_alternative 004464ED85256EBD_="
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/OF5712EE22.77227AF7-ON85256EBD.00443E78-85256EBD.004464EE@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8645
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040624122743.A426FA17E3@frink.w3.org>
Resent-Date: Thu, 24 Jun 2004 08:27:43 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 004464ED85256EBD_=
Content-Type: text/plain; charset="US-ASCII"

Good point ... it is probably simplest to leave it the way you
currently define it.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 06/24/2004 02:57:57 AM:

> Geoffrey M Clemm wrote:
> > 
> > This precondition sounds fine to me.
> > 
> > I wouldn't say it applies to all methods though; only methods that
> > modify state on the server (e.g., not PROPFIND or the various
> > REPORT's).
> 
> Right now it starts saying... "If a request would modify the content for 

> a locked resource, a dead property of a locked resource, a live 
> property that is defined to be lockable for a locked resource, or an 
> internal member URI of a locked collection,", thus it *does* apply to 
> all methods.
> 
> An alternative would be to re-group the conditions; but that would only 
> make case if we find more that fall into the same category...

--=_alternative 004464ED85256EBD_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Good point ... it is probably simplest to leave it
the way you</tt></font>
<br><font size=2><tt>currently define it.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote
on 06/24/2004 02:57:57 AM:<br>
<br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; &gt; <br>
&gt; &gt; This precondition sounds fine to me.<br>
&gt; &gt; <br>
&gt; &gt; I wouldn't say it applies to all methods though; only methods
that<br>
&gt; &gt; modify state on the server (e.g., not PROPFIND or the various<br>
&gt; &gt; REPORT's).<br>
&gt; <br>
&gt; Right now it starts saying... &quot;If a request would modify the
content for <br>
&gt; a locked resource, a dead property of a locked resource, a live <br>
&gt; property that is defined to be lockable for a locked resource, or
an <br>
&gt; internal member URI of a locked collection,&quot;, thus it *does*
apply to <br>
&gt; all methods.<br>
&gt; <br>
&gt; An alternative would be to re-group the conditions; but that would
only <br>
&gt; make case if we find more that fall into the same category...<br>
</tt></font>
--=_alternative 004464ED85256EBD_=--



From w3c-dist-auth-request@w3.org  Sat Jun 26 08:37:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06230
	for <webdav-archive@lists.ietf.org>; Sat, 26 Jun 2004 08:37:43 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2E5D8A2DC8; Sat, 26 Jun 2004 08:37:42 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 53E8EA2DC8
	for <w3c-dist-auth@listhub.w3.org>; Sat, 26 Jun 2004 08:37:39 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BeCR8-0003Fv-Vu
	for w3c-dist-auth@w3.org; Sat, 26 Jun 2004 08:37:39 -0400
Received: (qmail 16460 invoked by uid 65534); 26 Jun 2004 12:37:07 -0000
Received: from p50824A34.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.74.52)
  by mail.gmx.net (mp022) with SMTP; 26 Jun 2004 14:37:07 +0200
X-Authenticated: #1915285
Message-ID: <40DD6DF1.9080304@gmx.de>
Date: Sat, 26 Jun 2004 14:37:05 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com>
In-Reply-To: <OFB3B93022.3153A34E-ON85256EBC.0040CCD8-85256EBC.0040FFBD@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40DD6DF1.9080304@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8646
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040626123742.2E5D8A2DC8@frink.w3.org>
Resent-Date: Sat, 26 Jun 2004 08:37:42 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> I can't think of anything very sensible to add here, without speculating
> about what these other marshalling mechanisms might be (which doesn't seem
> like something that should appear in the spec).

OK. I'll mark that issue closed with a pointer to this mailing list posting:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.1.3_error_negotiation>

Joe, is this ok for you, or would you like to suggest actual replacement 
text?

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Sun Jun 27 00:22:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15748
	for <webdav-archive@lists.ietf.org>; Sun, 27 Jun 2004 00:22:26 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 199BFA1B8C; Sun, 27 Jun 2004 00:22:28 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 303FCA1FC3
	for <w3c-dist-auth@listhub.w3.org>; Sun, 27 Jun 2004 00:22:21 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BeRBN-0000u2-1b
	for w3c-dist-auth@w3.org; Sun, 27 Jun 2004 00:22:21 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5R4MJXN014901 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Sat, 26 Jun 2004 21:22:19 -0700
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by bandage.seagull.net (8.12.10) with ESMTP id i5R4MGm0014855 sender ccjason@us.ibm.com; Sat, 26 Jun 2004 21:22:17 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5R4M2Dk759048; Sun, 27 Jun 2004 00:22:02 -0400
Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5R4NAVh107874; Sun, 27 Jun 2004 00:23:11 -0400
To: Lisa Dusseault <nnlisa___at___osafoundation.org@smallcue.com>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OFB9133436.FB3AC720-ON85256EC0.0016440D-85256EC0.0017F545@us.ibm.com>
Date: Sun, 27 Jun 2004 00:21:50 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 06/27/2004 00:22:02, Serialize complete at 06/27/2004 00:22:02
Content-Type: multipart/alternative; boundary="=_alternative 0017667A85256EC0_="
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/OFB9133436.FB3AC720-ON85256EC0.0016440D-85256EC0.0017F545@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8647
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040627042228.199BFA1B8C@frink.w3.org>
Resent-Date: Sun, 27 Jun 2004 00:22:28 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0017667A85256EC0_=
Content-Type: text/plain; charset="us-ascii"

On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
> This would overturn a consensus that had previously been determined at
> a WG meeting that happened together with an interoperability meeting,
> and the consensus was not challenged on the mailing list at that time.
> 
> However, given that we have new information -- actual research!
> (thanks) -- it does make sense to reconsider.
> 
> WG members please indicate your old, new, and/ or current preference,
> with reasons if they've not already been stated here:
> 1. Should servers accept an UNLOCK request where the Request-URI names
> any resource covered by the lock named in the lock token?
> 2. Or, should servers redirect that UNLOCK request to the root of the
> lock?
> 3. If something else, please explain.
 

No strong preference so just go with what existing servers do. 

J.

--=_alternative 0017667A85256EC0_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault &nbsp;wrote:<br>
&gt; This would overturn a consensus that had previously been determined at<br>
&gt; a WG meeting that happened together with an interoperability meeting,<br>
&gt; and the consensus was not challenged on the mailing list at that time.<br>
&gt; <br>
&gt; However, given that we have new information -- actual research!<br>
&gt; (thanks) -- it does make sense to reconsider.<br>
&gt; <br>
&gt; WG members please indicate your old, new, and/ or current preference,<br>
&gt; with reasons if they've not already been stated here:<br>
&gt; 1. Should servers accept an UNLOCK request where the Request-URI names<br>
&gt; any resource covered by the lock named in the lock token?<br>
&gt; 2. Or, should servers redirect that UNLOCK request to the root of the<br>
&gt; lock?<br>
&gt; 3. If something else, please explain.<br>
 <br>
</font>
<br><font size=2 face="sans-serif">No strong preference so just go with what existing servers do. </font>
<br>
<br><font size=2 face="sans-serif">J.</font>
<br>
--=_alternative 0017667A85256EC0_=--



From w3c-dist-auth-request@w3.org  Sun Jun 27 05:12:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09138
	for <webdav-archive@lists.ietf.org>; Sun, 27 Jun 2004 05:12:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 82ED0A1B8B; Sun, 27 Jun 2004 05:12:18 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8C830A1DEF
	for <w3c-dist-auth@listhub.w3.org>; Sun, 27 Jun 2004 05:10:48 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BeVTn-00038J-7m
	for w3c-dist-auth@w3.org; Sun, 27 Jun 2004 04:57:39 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5R8veXu010800 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Sun, 27 Jun 2004 01:57:40 -0700
Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i5R8vapX010747 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Sun, 27 Jun 2004 01:57:36 -0700
Received: (qmail 3566 invoked by uid 65534); 27 Jun 2004 08:57:21 -0000
Received: from pD9E51A56.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.26.86) by mail.gmx.net (mp005) with SMTP; 27 Jun 2004 10:57:21 +0200
Message-ID: <40DE8BE3.3090502@gmx.de>
Date: Sun, 27 Jun 2004 10:57:07 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Jason Crawford <ccjason@us.ibm.com>
Cc: Lisa Dusseault <nnlisa___at___osafoundation.org@smallcue.com>,
        WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/40DE8BE3.3090502@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8648
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040627091218.82ED0A1B8B@frink.w3.org>
Resent-Date: Sun, 27 Jun 2004 05:12:18 -0400 (EDT)


Jason Crawford wrote:
> 
> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>  > This would overturn a consensus that had previously been determined at
>  > a WG meeting that happened together with an interoperability meeting,
>  > and the consensus was not challenged on the mailing list at that time.
>  >
>  > However, given that we have new information -- actual research!
>  > (thanks) -- it does make sense to reconsider.
>  >
>  > WG members please indicate your old, new, and/ or current preference,
>  > with reasons if they've not already been stated here:
>  > 1. Should servers accept an UNLOCK request where the Request-URI names
>  > any resource covered by the lock named in the lock token?
>  > 2. Or, should servers redirect that UNLOCK request to the root of the
>  > lock?
>  > 3. If something else, please explain.
> 
> 
> No strong preference so just go with what existing servers do.

What do you mean by "redirect"? Please be more specific.

No strong preference either, but some thoughts:

a) Whatever the consensus and the resolution is, it needs to be recorded 
in the official issues list. Right now it says that any URI of a 
resource protected by the lock works.

b) I think we *should* be documenting what is implemented, not what we 
think RFC2518 should have said in the first place. The servers I tested 
do implement behaviour 1).

c) If we only allow UNLOCK on the lock root, we still still need to be 
clear about what the result of other UNLOCK requests are? Undefined? 4xx 
status? In the latter case, all the servers I tested need to be updated, 
and we *may* be breaking existing clients.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue Jun 29 02:04:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14020
	for <webdav-archive@lists.ietf.org>; Tue, 29 Jun 2004 02:04:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EB7C1A2558; Tue, 29 Jun 2004 02:04:27 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DDA4DA2565
	for <w3c-dist-auth@listhub.w3.org>; Tue, 29 Jun 2004 02:04:21 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfBjB-0002Ur-RX
	for w3c-dist-auth@w3c.org; Tue, 29 Jun 2004 02:04:21 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5T63a50498788;
	Tue, 29 Jun 2004 02:03:36 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5T64Qbp100896;
	Tue, 29 Jun 2004 02:04:26 -0400
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@osafoundation.org>, Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OF39659994.C52AAFAC-ON85256EC2.00206580-85256EC2.00214A4E@us.ibm.com>
Date: Tue, 29 Jun 2004 02:03:41 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF339 | June 21, 2004) at
 06/29/2004 02:03:35,
	Serialize complete at 06/29/2004 02:03:35
Content-Type: multipart/alternative; boundary="=_alternative 0020922685256EC2_="
Subject: Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
X-Archived-At: http://www.w3.org/mid/OF39659994.C52AAFAC-ON85256EC2.00206580-85256EC2.00214A4E@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8649
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040629060427.EB7C1A2558@frink.w3.org>
Resent-Date: Tue, 29 Jun 2004 02:04:27 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0020922685256EC2_=
Content-Type: text/plain; charset="us-ascii"

On Wednesday, 06/09/2004 at 03:24 ZE2, Julian Reschke 
<julian.reschke@gmx.de> wrote:
> Julian Reschke wrote:
> >
> > OK,
> >
> > here's my attempt to summarize what Lisa and I discussed. I think this
> > should be used as resolution for the following issues:
> >
> > - LOCK_BODY_SHOULD_BE_MUST
> > - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
> >
> > Note that the description below does *not* change the original
> > semantics; it's just a clarification that seems to be in sync with
> > current implementations (and that's what we should be looking for when
> > updating the protocol)...:
> >
> > 1) A LOCK request with message body is a LOCK create request. A LOCK
> > request without a message body is a LOCK refresh request.
> >
> > 2) A LOCK refresh request refreshes those locks on the request 
resource
> > whose lock tokens are submitted in the "If" header and whose lock-root
> > is the resource identified by the request URI. A server MAY support
> > using the Time-Out header to set a new timeout, but clients can not 
rely
> > on that behaviour.
> >
> > 2a) In the case of a shared lock it's technically feasable to submit
> > lock tokens for multiple locks to be refreshed in one "If" header. The
> > semantics for that seem to be clear from 2), but it's doubtful whether 
a
> > client will ever want to do that. IMHO it doesn't make any sense to 
put
> > in the additional wording to forbid it, though (that's where I 
disagreed
> > with Lisa...).
> >
> > Note that if we stick with this resolution, the LOCK refresh changes 
in
> > RFC2518bis-05 will need to be rolled back.
> 
> OK,
> 
> can we please make a decision?

I really don't like using the If header for so many purposes, but I'm 
willing to give up on that point to get the spec out the door.  Let's hear 
some opinions on what Julian has said above.

J.

--=_alternative 0020922685256EC2_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">On Wednesday, 06/09/2004 at 03:24 ZE2, Julian Reschke &lt;julian.reschke@gmx.de&gt; wrote:<br>
&gt; Julian Reschke wrote:<br>
&gt; &gt;<br>
&gt; &gt; OK,<br>
&gt; &gt;<br>
&gt; &gt; here's my attempt to summarize what Lisa and I discussed. I think this<br>
&gt; &gt; should be used as resolution for the following issues:<br>
&gt; &gt;<br>
&gt; &gt; - LOCK_BODY_SHOULD_BE_MUST<br>
&gt; &gt; - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY<br>
&gt; &gt;<br>
&gt; &gt; Note that the description below does *not* change the original<br>
&gt; &gt; semantics; it's just a clarification that seems to be in sync with<br>
&gt; &gt; current implementations (and that's what we should be looking for when<br>
&gt; &gt; updating the protocol)...:<br>
&gt; &gt;<br>
&gt; &gt; 1) A LOCK request with message body is a LOCK create request. A LOCK<br>
&gt; &gt; request without a message body is a LOCK refresh request.<br>
&gt; &gt;<br>
&gt; &gt; 2) A LOCK refresh request refreshes those locks on the request resource<br>
&gt; &gt; whose lock tokens are submitted in the &quot;If&quot; header and whose lock-root<br>
&gt; &gt; is the resource identified by the request URI. A server MAY support<br>
&gt; &gt; using the Time-Out header to set a new timeout, but clients can not rely<br>
&gt; &gt; on that behaviour.<br>
&gt; &gt;<br>
&gt; &gt; 2a) In the case of a shared lock it's technically feasable to submit<br>
&gt; &gt; lock tokens for multiple locks to be refreshed in one &quot;If&quot; header. The<br>
&gt; &gt; semantics for that seem to be clear from 2), but it's doubtful whether a<br>
&gt; &gt; client will ever want to do that. IMHO it doesn't make any sense to put<br>
&gt; &gt; in the additional wording to forbid it, though (that's where I disagreed<br>
&gt; &gt; with Lisa...).<br>
&gt; &gt;<br>
&gt; &gt; Note that if we stick with this resolution, the LOCK refresh changes in<br>
&gt; &gt; RFC2518bis-05 will need to be rolled back.<br>
&gt; <br>
&gt; OK,<br>
&gt; <br>
&gt; can we please make a decision?</font>
<br>
<br><font size=2 face="sans-serif">I really don't like using the If header for so many purposes, but I'm willing to give up on that point to get the spec out the door. &nbsp;Let's hear some opinions on what Julian has said above.</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
<br>
--=_alternative 0020922685256EC2_=--



From w3c-dist-auth-request@w3.org  Tue Jun 29 08:39:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16018
	for <webdav-archive@lists.ietf.org>; Tue, 29 Jun 2004 08:39:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1E6DFA2A2E; Tue, 29 Jun 2004 08:39:28 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CF66FA2A2E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 29 Jun 2004 08:39:24 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfHtT-0002MH-I8
	for w3c-dist-auth@w3c.org; Tue, 29 Jun 2004 08:39:23 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5TCcq50526552
	for <w3c-dist-auth@w3c.org>; Tue, 29 Jun 2004 08:38:52 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5TCe1Dl105500
	for <w3c-dist-auth@w3c.org>; Tue, 29 Jun 2004 08:40:01 -0400
In-Reply-To: <OF39659994.C52AAFAC-ON85256EC2.00206580-85256EC2.00214A4E@us.ibm.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF4521361F.BE1FC832-ON85256EC2.00451FA2-85256EC2.0045796D@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 29 Jun 2004 08:39:11 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF339 | June 21, 2004) at
 06/29/2004 08:39:13,
	Serialize complete at 06/29/2004 08:39:13
Content-Type: multipart/alternative; boundary="=_alternative 0045796C85256EC2_="
Subject: Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
X-Archived-At: http://www.w3.org/mid/OF4521361F.BE1FC832-ON85256EC2.00451FA2-85256EC2.0045796D@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8650
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040629123928.1E6DFA2A2E@frink.w3.org>
Resent-Date: Tue, 29 Jun 2004 08:39:28 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0045796C85256EC2_=
Content-Type: text/plain; charset="US-ASCII"

If we were starting from scratch, I would agree with Jason that
we should not be overloading the If header the way the original
authors of 2518 did, but since there are implementations that depend
on this syntax, I think it is more important to maximize interoperability
with existing clients/servers than to fix this marshalling.

So I agree with the resolutions that Julian describes below, and also
agree that no special wording/explanation is required for the shared
lock case, both since I believe it follows from the original wording,
and that shared locks are not commonly implemented in any case.

Cheers,
Geoff

Jason wrote on 06/29/2004 02:03:41 AM:
> 
> On Wednesday, 06/09/2004 at 03:24 ZE2, Julian Reschke <julian.
> reschke@gmx.de> wrote:
> > Julian Reschke wrote:
> > >
> > > OK,
> > >
> > > here's my attempt to summarize what Lisa and I discussed. I think 
this
> > > should be used as resolution for the following issues:
> > >
> > > - LOCK_BODY_SHOULD_BE_MUST
> > > - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
> > >
> > > Note that the description below does *not* change the original
> > > semantics; it's just a clarification that seems to be in sync with
> > > current implementations (and that's what we should be looking for 
when
> > > updating the protocol)...:
> > >
> > > 1) A LOCK request with message body is a LOCK create request. A LOCK
> > > request without a message body is a LOCK refresh request.
> > >
> > > 2) A LOCK refresh request refreshes those locks on the request 
resource
> > > whose lock tokens are submitted in the "If" header and whose 
lock-root
> > > is the resource identified by the request URI. A server MAY support
> > > using the Time-Out header to set a new timeout, but clients can not 
rely
> > > on that behaviour.
> > >
> > > 2a) In the case of a shared lock it's technically feasable to submit
> > > lock tokens for multiple locks to be refreshed in one "If" header. 
The
> > > semantics for that seem to be clear from 2), but it's doubtful 
whether a
> > > client will ever want to do that. IMHO it doesn't make any sense to 
put
> > > in the additional wording to forbid it, though (that's where I 
disagreed
> > > with Lisa...).
> > >
> > > Note that if we stick with this resolution, the LOCK refresh changes 
in
> > > RFC2518bis-05 will need to be rolled back.
> > 
> > OK,
> > 
> > can we please make a decision? 
> 
> I really don't like using the If header for so many purposes, but 
> I'm willing to give up on that point to get the spec out the door. 
> Let's hear some opinions on what Julian has said above. 
> 
> J. 
--=_alternative 0045796C85256EC2_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>If we were starting from scratch, I would agree with
Jason that</tt></font>
<br><font size=2><tt>we should not be overloading the If header the way
the original</tt></font>
<br><font size=2><tt>authors of 2518 did, but since there are implementations
that depend</tt></font>
<br><font size=2><tt>on this syntax, I think it is more important to maximize
interoperability</tt></font>
<br><font size=2><tt>with existing clients/servers than to fix this marshalling.</tt></font>
<br>
<br><font size=2><tt>So I agree with the resolutions that Julian describes
below, and also</tt></font>
<br><font size=2><tt>agree that no special wording/explanation is required
for the shared</tt></font>
<br><font size=2><tt>lock case, both since I believe it follows from the
original wording,</tt></font>
<br><font size=2><tt>and that shared locks are not commonly implemented
in any case.</tt></font>
<br>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Jason wrote on 06/29/2004 02:03:41 AM:<br>
&gt; <br>
&gt; On Wednesday, 06/09/2004 at 03:24 ZE2, Julian Reschke &lt;julian.<br>
&gt; reschke@gmx.de&gt; wrote:<br>
&gt; &gt; Julian Reschke wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; OK,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; here's my attempt to summarize what Lisa and I discussed.
I think this<br>
&gt; &gt; &gt; should be used as resolution for the following issues:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; - LOCK_BODY_SHOULD_BE_MUST<br>
&gt; &gt; &gt; - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Note that the description below does *not* change the original<br>
&gt; &gt; &gt; semantics; it's just a clarification that seems to be in
sync with<br>
&gt; &gt; &gt; current implementations (and that's what we should be looking
for when<br>
&gt; &gt; &gt; updating the protocol)...:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1) A LOCK request with message body is a LOCK create request.
A LOCK<br>
&gt; &gt; &gt; request without a message body is a LOCK refresh request.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2) A LOCK refresh request refreshes those locks on the request
resource<br>
&gt; &gt; &gt; whose lock tokens are submitted in the &quot;If&quot; header
and whose lock-root<br>
&gt; &gt; &gt; is the resource identified by the request URI. A server
MAY support<br>
&gt; &gt; &gt; using the Time-Out header to set a new timeout, but clients
can not rely<br>
&gt; &gt; &gt; on that behaviour.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2a) In the case of a shared lock it's technically feasable
to submit<br>
&gt; &gt; &gt; lock tokens for multiple locks to be refreshed in one &quot;If&quot;
header. The<br>
&gt; &gt; &gt; semantics for that seem to be clear from 2), but it's doubtful
whether a<br>
&gt; &gt; &gt; client will ever want to do that. IMHO it doesn't make any
sense to put<br>
&gt; &gt; &gt; in the additional wording to forbid it, though (that's where
I disagreed<br>
&gt; &gt; &gt; with Lisa...).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Note that if we stick with this resolution, the LOCK refresh
changes in<br>
&gt; &gt; &gt; RFC2518bis-05 will need to be rolled back.<br>
&gt; &gt; <br>
&gt; &gt; OK,<br>
&gt; &gt; <br>
&gt; &gt; can we please make a decision? <br>
&gt; <br>
&gt; I really don't like using the If header for so many purposes, but
<br>
&gt; I'm willing to give up on that point to get the spec out the door.
&nbsp;<br>
&gt; Let's hear some opinions on what Julian has said above. <br>
&gt; <br>
&gt; J. </tt></font>
--=_alternative 0045796C85256EC2_=--



From w3c-dist-auth-request@w3.org  Wed Jun 30 03:19:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27944
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 03:19:55 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 068DCA07C1; Wed, 30 Jun 2004 03:19:56 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5205CA077B
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 03:19:50 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BfZNm-0004rP-7p
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 03:19:50 -0400
Received: (qmail 16686 invoked by uid 65534); 30 Jun 2004 07:19:16 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243)
  by mail.gmx.net (mp026) with SMTP; 30 Jun 2004 09:19:16 +0200
X-Authenticated: #1915285
Message-ID: <40E2696E.8010702@gmx.de>
Date: Wed, 30 Jun 2004 09:19:10 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Fwd: I-D ACTION:draft-reschke-webdav-locking-04.txt]
X-Archived-At: http://www.w3.org/mid/40E2696E.8010702@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8651
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630071956.068DCA07C1@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 03:19:56 -0400 (EDT)
Content-Transfer-Encoding: 7bit



Hi,

I have submitted another version of my experimental stand-alone locking
protocol document.  Revision 04
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-04.html> 
and 
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-04.txt>)
have the changes described below:

E.4  Since draft-reschke-webdav-locking-03

    Close issues "import-rfc3253-stuff", "008_URI_URL",
    "015_MOVE_SECTION_6.4.1_TO_APPX", "044_REPORT_OTHER_RESOURCE_LOCKED",
    "056_DEPTH_LOCK_AND_IF" and "072_LOCK_URL_WITH_NO_PARENT_COLLECTION".
    Reformat condition name descriptions.  Add mention of condition
    failure signalling to "Changes" appendix.  Start edit of header
    descriptions (Depth, Timeout) and LOCK creation description.  Open
    and close issue "3.2_lockdiscovery_depth".  Start work on intro.


(The HTML versions have all changes highlighted, so it's easy to see 
what actually has been changing between revisions since the "import" of 
text from RFC2518).

As usual, edits are ongoing on
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>.
The current issues list is at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>.

The next step will be to integrate GULP into the description of write locks.

Feedback appreciated, Julian


-------- Original Message --------
From: - Wed Jun 30 01:30:23 2004
X-UIDL: e921bc2a83b93cd597b37a22a3b82b83
X-Mozilla-Status: 0001
X-Mozilla-Status2: 18000000
Return-Path: <i-d-announce-bounces@ietf.org>
X-Flags: 0000
Delivered-To: GMX delivery to julian.reschke@gmx.de
Received: (qmail 16493 invoked by uid 65534); 29 Jun 2004 20:32:29 -0000
Received: from megatron.ietf.org (EHLO megatron.ietf.org) (132.151.6.71) 
  by mx0.gmx.net (mx005) with SMTP; 29 Jun 2004 22:32:29 +0200
Received: from localhost.localdomain ([127.0.0.1] 
helo=megatron.ietf.org)	by megatron.ietf.org with esmtp (Exim 4.32)	id 
1BfOLY-0005Tc-I7; Tue, 29 Jun 2004 15:32:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)	by 
megatron.ietf.org with esmtp (Exim 4.32) id 1BfOHL-0004bd-ON	for 
i-d-announce@megatron.ietf.org; Tue, 29 Jun 2004 15:28:27 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])	by ietf.org 
(8.9.1a/8.9.1a) with ESMTP id PAA11375	for <i-d-announce@ietf.org>; Tue, 
29 Jun 2004 15:28:26 -0400 (EDT)
Message-Id: <200406291928.PAA11375@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Tue, 29 Jun 2004 15:28:26 -0400
Subject: I-D ACTION:draft-reschke-webdav-locking-04.txt
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: 
<https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
	Author(s)	: J. Reschke
	Filename	: draft-reschke-webdav-locking-04.txt
	Pages		: 48
	Date		: 2004-6-29
	
This document specifies a set of methods and headers ancillary to
    HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
    RFC2518) for the management of resource locking (collision
    avoidance).  It updates those sections from RFC2518 that specify
    WebDAV's locking features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-reschke-webdav-locking-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-reschke-webdav-locking-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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



From w3c-dist-auth-request@w3.org  Wed Jun 30 04:24:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01457
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 04:24:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3D6ADA05F5; Wed, 30 Jun 2004 04:24:21 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8C07BA0615
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 04:24:14 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BfaO6-0006eP-Fu
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 04:24:14 -0400
Received: (qmail 32728 invoked by uid 65534); 30 Jun 2004 08:23:39 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243)
  by mail.gmx.net (mp023) with SMTP; 30 Jun 2004 10:23:39 +0200
X-Authenticated: #1915285
Message-ID: <40E27879.5070709@gmx.de>
Date: Wed, 30 Jun 2004 10:23:21 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: Joe Hildebrand <joe@cursive.net>
References: <89EEF183-C4C0-11D8-8A2C-000A959A17A6@cursive.net> <40D93685.70206@gmx.de>
In-Reply-To: <40D93685.70206@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ID: draft-ietf-webdav-bind-05
X-Archived-At: http://www.w3.org/mid/40E27879.5070709@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8652
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630082421.3D6ADA05F5@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 04:24:21 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:
> 
> Joe Hildebrand wrote:
> 
>>
>> In the interest of trying to get things moving on BIND, I've got some 
>> review comments.  I'm unburdened by knowing where the WG has already 
>> achieved consensus, so please let me know if I step on something 
>> unintentionally.

Hi,

I have updated the latest draft text (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>) 
as follows:

1) Recorded and resolved those issues for which we agreed upon a 
resolution 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.5_language> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.7.1.1_add_resource_id>).

2) Recorded and resolved as "no change" the issue where the consensus 
seemed to be that we don't need a change 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.1.3_error_negotiation>).

3) Re-added issue 4_LOCK_BEHAVIOUR from the old issues list as 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.4_LOCK_BEHAVIOR> 
(with status "closed").

4) No changes at all where it seems that the explanations provided by 
Geoff and myself seem to have been sufficient.

This leaves us with the perma-issue of locking vs binds:

> ...
>> 4 (and others)
>>  - (DAV:locked-update-allowed) what if the resource is locked?  I understand that this is a property of the resource, not the binding, but since 2518 doesn't say anything about bindings, I think we could use a paragraph at some point that spells this out explicitly.  Perhaps another sub-section in section 2?
> 
> 
> That's incorrect. In particular, <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:
> 
> "A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable."
> 
> That being said, a large amount of the open issues raised against RFC2518 are about locking semantics. The authors of the BIND spec feel that it's a bad idea to try to clarify locking semantics in a document that's completely independant and optional. Locking semantics should be fully defined in a single place.
> 
> One way to do this is to wait for RFC2518bis. Another one is to factor out locking from the base protocol, and publish this as "update" to RFC2518 (at "proposed" level), and let the BIND spec refer to that. This is what I'm currently working on (and I'm planning to submit a complete rewrite in time before the IETF meeting).
> 
> I've summarized the issue at <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>.   So far, I've seen many people agree, and it would be really good if the working group would come to a decision on this matter. 
> ...

It would be nice if we could make some progress on that discussion which 
has now been going on for half a year...

Anyway, unless I people feel there's a problem with that, I'll be 
submitting the latest edits as draft 06 so we have an up-to-date 
published version in due time before the IETF meeting.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 30 13:23:58 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00103
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 13:23:58 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 82AA6A114D; Wed, 30 Jun 2004 13:23:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 7D909A11DF
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 13:23:55 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfioN-0004zg-1o
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 13:23:55 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UHNqVd019204 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 10:23:52 -0700
Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i5UHNoid019123 sender lisa@osafoundation.org for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 10:23:50 -0700
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5UHMZJL003539 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 10:22:38 -0700
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3A8A5A6B-CABA-11D8-93E4-000A95B2BB72@osafoundation.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 10:23:40 -0700
To: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
X-Mailer: Apple Mail (2.618)
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/3A8A5A6B-CABA-11D8-93E4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8653
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630172358.82AA6A114D@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 13:23:58 -0400 (EDT)


Here's proposed text to use if we end up allowing UNLOCK against any 
resource covered by the lock token, as is currently the case in most 
implementations:

    The UNLOCK method identifies a lock to remove with the lock token in
    the Lock-Token request header.  The Request-URI MUST identify a
    resource within the scope of the lock.

Then later in the error code information for UNLOCK:

    400 (Bad Request) - No lock token was provided, or request was
    made to a Request-URI that was not within the scope of the lock.

Lisa

On Jun 27, 2004, at 1:57 AM, Julian Reschke wrote:

> Jason Crawford wrote:
>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>>  > This would overturn a consensus that had previously been 
>> determined at
>>  > a WG meeting that happened together with an interoperability 
>> meeting,
>>  > and the consensus was not challenged on the mailing list at that 
>> time.
>>  >
>>  > However, given that we have new information -- actual research!
>>  > (thanks) -- it does make sense to reconsider.
>>  >
>>  > WG members please indicate your old, new, and/ or current 
>> preference,
>>  > with reasons if they've not already been stated here:
>>  > 1. Should servers accept an UNLOCK request where the Request-URI 
>> names
>>  > any resource covered by the lock named in the lock token?
>>  > 2. Or, should servers redirect that UNLOCK request to the root of 
>> the
>>  > lock?
>>  > 3. If something else, please explain.
>> No strong preference so just go with what existing servers do.
>
> What do you mean by "redirect"? Please be more specific.
>
> No strong preference either, but some thoughts:
>
> a) Whatever the consensus and the resolution is, it needs to be 
> recorded in the official issues list. Right now it says that any URI 
> of a resource protected by the lock works.
>
> b) I think we *should* be documenting what is implemented, not what we 
> think RFC2518 should have said in the first place. The servers I 
> tested do implement behaviour 1).
>
> c) If we only allow UNLOCK on the lock root, we still still need to be 
> clear about what the result of other UNLOCK requests are? Undefined? 
> 4xx status? In the latter case, all the servers I tested need to be 
> updated, and we *may* be breaking existing clients.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 30 13:25:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00239
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 13:25:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 11DFFA10DC; Wed, 30 Jun 2004 13:25:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D10E9A10DC
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 13:25:39 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1Bfiq3-0005Fl-N7
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 13:25:39 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UHPc5m020120 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 10:25:38 -0700
Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i5UHPcC7020107 sender lisa@osafoundation.org for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 10:25:38 -0700
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5UHO1JL003615 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 30 Jun 2004 10:24:04 -0700
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6D7DD31E-CABA-11D8-93E4-000A95B2BB72@osafoundation.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 10:25:05 -0700
To: Julian Reschke <julian.reschke@gmx.de>,
        WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
X-Mailer: Apple Mail (2.618)
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/6D7DD31E-CABA-11D8-93E4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8654
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630172543.11DFFA10DC@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 13:25:43 -0400 (EDT)


Hey, I forgot to ask.  Julian, in your research, did you happen to test 
LOCK to refresh a lock as well?  Do server implementations allow LOCK 
on any resource-URI within the scope to successfully refresh the lock?

Lisa

On Jun 27, 2004, at 1:57 AM, Julian Reschke wrote:

> Jason Crawford wrote:
>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>>  > This would overturn a consensus that had previously been 
>> determined at
>>  > a WG meeting that happened together with an interoperability 
>> meeting,
>>  > and the consensus was not challenged on the mailing list at that 
>> time.
>>  >
>>  > However, given that we have new information -- actual research!
>>  > (thanks) -- it does make sense to reconsider.
>>  >
>>  > WG members please indicate your old, new, and/ or current 
>> preference,
>>  > with reasons if they've not already been stated here:
>>  > 1. Should servers accept an UNLOCK request where the Request-URI 
>> names
>>  > any resource covered by the lock named in the lock token?
>>  > 2. Or, should servers redirect that UNLOCK request to the root of 
>> the
>>  > lock?
>>  > 3. If something else, please explain.
>> No strong preference so just go with what existing servers do.
>
> What do you mean by "redirect"? Please be more specific.
>
> No strong preference either, but some thoughts:
>
> a) Whatever the consensus and the resolution is, it needs to be 
> recorded in the official issues list. Right now it says that any URI 
> of a resource protected by the lock works.
>
> b) I think we *should* be documenting what is implemented, not what we 
> think RFC2518 should have said in the first place. The servers I 
> tested do implement behaviour 1).
>
> c) If we only allow UNLOCK on the lock root, we still still need to be 
> clear about what the result of other UNLOCK requests are? Undefined? 
> 4xx status? In the latter case, all the servers I tested need to be 
> updated, and we *may* be breaking existing clients.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 30 13:46:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01301
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 13:46:43 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0ED99A0AB9; Wed, 30 Jun 2004 13:46:44 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 92281A0AB9
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 13:46:41 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfjAP-00044B-Ay
	for w3c-dist-auth@w3c.org; Wed, 30 Jun 2004 13:46:41 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5UHj6JL004850
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 30 Jun 2004 10:45:14 -0700
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40D441ED.6000806@gmx.de>
References: <40D345F8.9050106@gmx.de> <40D441ED.6000806@gmx.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5EEEBB30-CABD-11D8-93E4-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 10:46:09 -0700
To: Julian Reschke <julian.reschke@gmx.de>, Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/5EEEBB30-CABD-11D8-93E4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8655
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630174644.0ED99A0AB9@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 13:46:44 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm mostly happy with this, although as with much of the specs where 
preconditions are defined, it doesn't say in which cases the server 
MUST (or SHOULD or MAY) return this precondition.  For backward 
compatibility, I suggest that servers SHOULD or MAY return this 
precondition in the body of a 423 Locked response.  Other commenters?  
Will servers actually implement this?

Lisa

On Jun 19, 2004, at 6:38 AM, Julian Reschke wrote:

>
> Full text:
>
> 7.2.2  DAV:need-lock-token precondition
>
>    If a request would modify the content for a locked resource, a dead
>    property of a locked resource, a live property that is defined to be
>    lockable for a locked resource, or an internal member URI of a 
> locked
>    collection, the request MUST fail unless the lock-token for that 
> lock
>    is submitted in the request.  An internal member URI of a collection
>    is considered to be modified if it is added, removed, or identifies 
> a
>    different resource.  [[anchor28: Copied from GULP.  --reschke]]
>
>       <!ELEMENT need-lock-token (href)* >
>
>    Servers SHOULD insert DAV:href elements for the URLs of each root of
>    a lock for which a lock token was needed, unless that URL identies
>    the same resource to that the request was sent.
>
> 7.2.2.1  Example
>
>    In the example below, a client unaware of a "Depth: infinity" lock 
> on
>    the parent collection "/workspace/webdav/" attempts to modify the
>    collection member "/workspace/webdav/proposal.doc".
>
>    >>Request
>
>       PUT /workspace/webdav/proposal.doc HTTP/1.1
>       Host: example.com
>
>    >>Response
>
>       HTTP/1.1 423 Locked
>       Content-Type: text/xml; charset="utf-8"
>       Content-Length: xxxx
>
>       <?xml version="1.0" encoding="utf-8" ?>
>       <D:error xmlns:D="DAV:">
>         <D:need-lock-token>
>           <D:href>/workspace/webdav/</D:href>
>         </D:need-lock-token>
>       </D:error>
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Jun 30 13:58:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02151
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 13:58:43 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DC89EA06B8; Wed, 30 Jun 2004 13:58:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CAD83A074B
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 13:58:41 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfjM1-0005at-Jd
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 13:58:41 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3.org>
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5UHvQJL006294
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3.org>; Wed, 30 Jun 2004 10:57:28 -0700
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com>
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com> <40C2E9FA.1090801@gmx.de> <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org> <78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <19365CF2-CABF-11D8-93E4-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 10:58:31 -0700
To: WebDAV <w3c-dist-auth@w3.org>
X-Mailer: Apple Mail (2.618)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/19365CF2-CABF-11D8-93E4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8656
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630175843.DC89EA06B8@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 13:58:43 -0400 (EDT)
Content-Transfer-Encoding: 7bit


So, there hasn't exactly been overwhelming response to this.  We found 
out that one client implementation does not rely on having the 
'lockdiscovery' property in the body of failed LOCK responses (though 
they do use the property in other situations -- and thanks, Jim).

Problem summarized: the spec only shows by example how to include the 
property in the body of a 207, and the example doesn't follow the DTD.

Proposed solutions summarized:
   1. Define a new way to put 'lockdiscovery' in the body of a 207 to 
indicate a failed dependency, make existing servers change.
   2. Leave it out (simpler) because clients don't seem to use it and 
can always make a second trip in this (hopefully rare) failure case.

There's been some mild interest shown in the "leave it out" solution 
mostly because it simplifies the spec, although I think that it's also 
got a significant advantage in not requiring servers to change 
behavior.

Any objections to the "leave it out" solution (or further comments  in 
favour)?

Lisa

On Jun 7, 2004, at 3:17 PM, Jim Luther wrote:

>
> The Mac OS X WebDAV file system client uses exclusive locks. The 
> lockdiscovery property is only used if LOCK is successful.
>
> - Jim
>
> On Jun 7, 2004, at 2:37 PM, Lisa Dusseault wrote:
>
>>
>>
>> Hello client implementors! -- please respond on this thread and let 
>> us know if you use the 'lockdiscovery' property value, which is 
>> returned in failed LOCK requests.
>>
>> (If no clients use the property value as returned in failed LOCK 
>> requests -- maybe they all do another round-trip to get the value -- 
>> then we might as well simplify, rather than optimize for this failure 
>> case)
>>
>> Lisa
>>
>>
>> On Jun 6, 2004, at 2:55 AM, Julian Reschke wrote:
>>
>>>
>>> Geoffrey M Clemm wrote:
>>>
>>> > ...
>>>>  > > I don't think anything needs to be changed here.
>>>>  > > I'm not sure what you had in mind by saying
>>>>  > > "it MUST be returned on successful execution",
>>>>  > > since the whole point is to indicate what existing
>>>>  > > lock caused the LOCK request to fail, i.e. this
>>>>  > > property is returned only for the failure case.
>>>>  >
>>>>  > In RFC2518, the requirement is independant from the success of 
>>>> the LOCK
>>>>  > request: "The response MUST contain the value of the 
>>>> lockdiscovery
>>>>  > property in a prop XML element."
>>>> By "this property", I meant the property on the nested resource that
>>>> returned 424 because that nested resource was already locked.
>>>> I agree that a lockdiscovery property for the resource identified
>>>> by the request-URL must always be returned, whether or not the 
>>>> request
>>>> succeeded.
>>>
>>> Well, the 424 is returned for the request resource (because it has a 
>>> failed dependancy). The non-424 status (in the RFC2518 example 
>>> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> 
>>> it's a 403) comes without the DAV:lockdiscovery property (and I do 
>>> agree that it may be useful here, but that's not what the spec 
>>> says).
>>>
>>>> ...
>>>>  > 2) For a failed LOCK request, there are (at least) two scenarios:
>>>>  >
>>>>  > 2a) The resource at the request URI can not be locked, for 
>>>> instance
>>>>  > because it already has a conflicting lock. In that case, I'd 
>>>> expect a
>>>>  > 4xx status code, and RFC2518 does not define a way to send back
>>>>  > DAV:lockdiscovery. If we require the server to send back a 207 
>>>> with
>>>>  > response body in this case, this really needs to be stated 
>>>> explicitly
>>>>  > because it's far from obvious.
>>>> Well, it is stated in section 8.10.4, but I agree that it is not 
>>>> clearly
>>>> stated, since the only way to guess how to marshall it is by 
>>>> extrapolation
>>>> from example 8.10.10.
>>>
>>> ...but the multistatus response body is only mentioned for 
>>> marshalling failures due to depth:infinity...
>>>
>>> > ...
>>>>  > > WRT the marshalling, I agree that this is not a
>>>>  > > consistent way of using the propstat syntax
>>>>  > > (i.e. the status is not about the property,
>>>>  > > but that was just a convenient place to put it).
>>>>  > > So if nobody implements this,
>>>>  > > we certainly could define a cleaner marshalling,
>>>>  > > but if any client/server does implement it, then we
>>>>  > > should leave it alone.
>>>>  >
>>>>  > Let's find out.
>>>> Yup.
>>>
>>> In the meantime I found out that at least Apache/moddav and 
>>> Sharemation indeed use this format. What we should do...:
>>>
>>> 1) Find out whether there are clients that actually process this 
>>> information. As far as I can tell, it will only be useful if and 
>>> only if you're trying to get an deep, exclusive lock on a resource 
>>> that already has a shared lock. I'm only aware of two clients using 
>>> shared locks. The first one being our own (and I know it doesn't use 
>>> that information), the other being Adobe GoLive (for which I'll 
>>> check).
>>>
>>> 2) If the answer is "yes" *and* we agree not to break them, we'll 
>>> need to figure out how to precisely define that response format (a 
>>> single example is not good enough).
>>>
>>> 3) On the other hand, if the answer is "no" let's define what we 
>>> *like* the protocol to do and come up with a cleaner design 
>>> (precondition code with nested content as in 
>>> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?
>>>
>>>
>>> Best regards,
>>>
>>> Julian
>>>
>>>
>>> -- 
>>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>>
>>
>



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:08:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02531
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:08:43 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D249BA1042; Wed, 30 Jun 2004 14:08:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B95F2A108D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:08:40 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfjVg-0007H2-EN
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 14:08:40 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UI8dxE014864 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 11:08:39 -0700
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i5UI8ZAf014784 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 11:08:35 -0700
Received: (qmail 12474 invoked by uid 65534); 30 Jun 2004 18:08:23 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243) by mail.gmx.net (mp019) with SMTP; 30 Jun 2004 20:08:23 +0200
Message-ID: <40E30193.5030709@gmx.de>
Date: Wed, 30 Jun 2004 20:08:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/40E30193.5030709@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8657
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630180843.D249BA1042@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:08:43 -0400 (EDT)


Lisa Dusseault wrote:
> Hey, I forgot to ask.  Julian, in your research, did you happen to test 
> LOCK to refresh a lock as well?  Do server implementations allow LOCK on 
> any resource-URI within the scope to successfully refresh the lock?

Yes, I did. See 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html#065_UNLOCK_WHAT_URL> 
and in particular: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0170.html>.

-> Servers do not care about whether the resource is directly or 
indirectly locked.

Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:11:52 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02752
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:11:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2F96CA12C8; Wed, 30 Jun 2004 14:11:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1DFD8A12C8
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:11:49 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1BfjYi-0007pF-UI
	for w3c-dist-auth@w3c.org; Wed, 30 Jun 2004 14:11:49 -0400
Received: (qmail 26184 invoked by uid 65534); 30 Jun 2004 18:11:16 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243)
  by mail.gmx.net (mp006) with SMTP; 30 Jun 2004 20:11:16 +0200
X-Authenticated: #1915285
Message-ID: <40E3023D.7040000@gmx.de>
Date: Wed, 30 Jun 2004 20:11:09 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <40D345F8.9050106@gmx.de> <40D441ED.6000806@gmx.de> <5EEEBB30-CABD-11D8-93E4-000A95B2BB72@osafoundation.org>
In-Reply-To: <5EEEBB30-CABD-11D8-93E4-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue #44: REPORT_OTHER_RESOURCE_LOCKED
X-Archived-At: http://www.w3.org/mid/40E3023D.7040000@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8658
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630181152.2F96CA12C8@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:11:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'm mostly happy with this, although as with much of the specs where 
> preconditions are defined, it doesn't say in which cases the server MUST 
> (or SHOULD or MAY) return this precondition.  For backward 
> compatibility, I suggest that servers SHOULD or MAY return this 
> precondition in the body of a 423 Locked response.  Other commenters?  
> Will servers actually implement this?

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#method.preconditions.and.postconditions> 
makes this a "MUST" level requirement. Realistically, we may want to 
make that a SHOULD, because it may be hard for some servers to implement 
that (on the other hand we *do* want them to implement the more 
important changes such as DAV:lockroot). And after all, no big harm is 
done when it's not returned.

Feedback appreciated.

Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:14:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02862
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:14:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 06877A1014; Wed, 30 Jun 2004 14:14:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id F0CA2A1014
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:14:40 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfjbU-0008Qk-Po
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 14:14:41 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UIEdSc017468 sender lisa@osafoundation.org for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 11:14:39 -0700
Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by bandage.seagull.net (8.12.10) with ESMTP id i5UIEc4A017438 sender lisa@osafoundation.org for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 11:14:38 -0700
Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i5UID0JL007167 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 30 Jun 2004 11:13:07 -0700
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <45C20C58-CAC1-11D8-93E4-000A95B2BB72@osafoundation.org>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 30 Jun 2004 11:14:05 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.618)
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/45C20C58-CAC1-11D8-93E4-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8659
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630181443.06877A1014@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:14:43 -0400 (EDT)


Yes, I read these today, but it was my interpretation that this testing  
applied to the UNLOCK request.  What about LOCK request to refresh a  
lock?  Does that also work on resources other than the lock root?  I  
think servers would probably implement them the same way, but I was  
curious whether you'd tested it explicitly.

Lisa

On Jun 30, 2004, at 11:08 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Hey, I forgot to ask.  Julian, in your research, did you happen to  
>> test LOCK to refresh a lock as well?  Do server implementations allow  
>> LOCK on any resource-URI within the scope to successfully refresh the  
>> lock?
>
> Yes, I did. See  
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> issues.html#065_UNLOCK_WHAT_URL> and in particular:  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> 0170.html>.
>
> -> Servers do not care about whether the resource is directly or  
> indirectly locked.
>
> Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:27:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03435
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:27:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 752F6A05EB; Wed, 30 Jun 2004 14:27:21 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D0A2EA05EB
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:27:18 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.32)
	id 1Bfjni-0001VR-KA
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 14:27:18 -0400
Received: (qmail 31168 invoked by uid 65534); 30 Jun 2004 18:26:44 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243)
  by mail.gmx.net (mp014) with SMTP; 30 Jun 2004 20:26:44 +0200
X-Authenticated: #1915285
Message-ID: <40E305D7.5080607@gmx.de>
Date: Wed, 30 Jun 2004 20:26:31 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <w3c-dist-auth@w3.org>
References: <OF8F17E3B3.B8DA2F32-ON85256EAA.00719C87-85256EAA.00734D9C@us.ibm.com> <40C2E9FA.1090801@gmx.de> <DCE9A466-B8CA-11D8-9162-000A95B2BB72@osafoundation.org> <78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com> <19365CF2-CABF-11D8-93E4-000A95B2BB72@osafoundation.org>
In-Reply-To: <19365CF2-CABF-11D8-93E4-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: LOCK error marshalling (lockdiscovery property included?)
X-Archived-At: http://www.w3.org/mid/40E305D7.5080607@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8660
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630182721.752F6A05EB@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:27:21 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> So, there hasn't exactly been overwhelming response to this.  We found 
> out that one client implementation does not rely on having the 
> 'lockdiscovery' property in the body of failed LOCK responses (though 
> they do use the property in other situations -- and thanks, Jim).
> 
> Problem summarized: the spec only shows by example how to include the 
> property in the body of a 207, and the example doesn't follow the DTD.
> 
> Proposed solutions summarized:
>   1. Define a new way to put 'lockdiscovery' in the body of a 207 to 
> indicate a failed dependency, make existing servers change.
>   2. Leave it out (simpler) because clients don't seem to use it and can 
> always make a second trip in this (hopefully rare) failure case.
> 
> There's been some mild interest shown in the "leave it out" solution 
> mostly because it simplifies the spec, although I think that it's also 
> got a significant advantage in not requiring servers to change behavior.
> 
> Any objections to the "leave it out" solution (or further comments  in 
> favour)?

Well, I'm in favor not to put in special cases. Right now my text reads:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 403 Forbidden</D:status>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

(because /webdav/secret just denied the lock without any details). Let's 
assume instead /webdav/secret would have had a lock conflicting with the 
request, then we'd get

    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 423 Locked</D:status>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

...and assuming the LOCK (creation) method definition would define a 
matching precondition that would become:

    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 423 Locked</D:status>
         <D:responsedescription>
           <D:error>
             <D:no-lock-conflict>
               <D:href>locktoken:...</D:href>
             </D:no-lock-conflict>
           </D:error>
         </D:responsedescription>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

Note that this really nothing new; it would just follow from existing 
DAV:error marshalling once we simply *name* that precondition.

Also note that this only avoids a round trip to the child resource to 
lookup the conflicting lock. I guess only few clients would ever want to 
know...

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:30:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03806
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:30:46 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 641AAA10FE; Wed, 30 Jun 2004 14:30:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 818E0A10FE
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:30:46 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1Bfjr2-00024I-9D
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 14:30:44 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UIUd2p026023 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 11:30:39 -0700
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i5UIUbGf025946 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 11:30:38 -0700
Received: (qmail 27635 invoked by uid 65534); 30 Jun 2004 18:30:26 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243) by mail.gmx.net (mp005) with SMTP; 30 Jun 2004 20:30:26 +0200
Message-ID: <40E306BB.6080601@gmx.de>
Date: Wed, 30 Jun 2004 20:30:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/40E306BB.6080601@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8661
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630183047.641AAA10FE@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:30:47 -0400 (EDT)


Lisa Dusseault wrote:

> 
> Here's proposed text to use if we end up allowing UNLOCK against any 
> resource covered by the lock token, as is currently the case in most 
> implementations:
> 
>    The UNLOCK method identifies a lock to remove with the lock token in
>    the Lock-Token request header.  The Request-URI MUST identify a
>    resource within the scope of the lock.

Right now I'm saying:

	 The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the resource identified by the 
Request-URI, and all other resources included in the lock. Note that the 
UNLOCK request may be submitted to any resource locked by that lock 
(even those that are locked indirectly).

..but I guess this is equivalent.

> Then later in the error code information for UNLOCK:
> 
>    400 (Bad Request) - No lock token was provided, or request was
>    made to a Request-URI that was not within the scope of the lock.

For the case where the lock-token header *is* present I defined:

"5.2.1 DAV:lock-token-matches precondition

The lock identified by the "Lock-Token" request header exists, and the 
resource identified by the Request-URI indeed is directly locked by the 
specified lock."

so you'd get a 403 with DAV:error in this case. The more preconditions 
we precisely identify, the less new clients will have to rely on 
specific 4xx codes...


Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Jun 30 14:38:24 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04503
	for <webdav-archive@lists.ietf.org>; Wed, 30 Jun 2004 14:38:24 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C5B1CA130B; Wed, 30 Jun 2004 14:38:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D0E9DA1336
	for <w3c-dist-auth@listhub.w3.org>; Wed, 30 Jun 2004 14:38:22 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.32)
	id 1BfjyQ-00039W-H6
	for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 14:38:22 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i5UIcLOl030075 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Wed, 30 Jun 2004 11:38:21 -0700
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i5UIcJxb030019 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Wed, 30 Jun 2004 11:38:20 -0700
Received: (qmail 20214 invoked by uid 65534); 30 Jun 2004 18:38:07 -0000
Received: from pD9535EF3.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.243) by mail.gmx.net (mp006) with SMTP; 30 Jun 2004 20:38:07 +0200
Message-ID: <40E30882.2040603@gmx.de>
Date: Wed, 30 Jun 2004 20:37:54 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Call for consensus on UNLOCK Request-URI being lock root
X-Archived-At: http://www.w3.org/mid/40E30882.2040603@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8662
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040630183825.C5B1CA130B@frink.w3.org>
Resent-Date: Wed, 30 Jun 2004 14:38:25 -0400 (EDT)


Lisa Dusseault wrote:

> Yes, I read these today, but it was my interpretation that this testing  
> applied to the UNLOCK request.  What about LOCK request to refresh a  
> lock?  Does that also work on resources other than the lock root?  I  
> think servers would probably implement them the same way, but I was  
> curious whether you'd tested it explicitly.

Sorry. Related to this is 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0191.html>, 
but that is about URLs in tagged "If" headers (where I found that 
servers do not seem to care).

Right now I'm saying...

"4.2.3.1 DAV:locks-refreshed postcondition

Timers associated with the those locks submitted in the "If" request 
header whose lock root is the resource identified by the Request-URI 
MUST be reset to their original value (or alternatively to the new value 
given in the "Timeout" request header)."

..basically because it seems nobody asked that question before. 
Assuming we'd find out that servers do not care for LOCK/refresh either, 
would we want to relax the spec text?

Best regards, Julian


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